The choice of project organizational structure depends on the characteristics of the project, and external constraints, such as existing organizational policy. It is, therefore, difficult to be prescriptive about such structures, because what is effective (or even feasible) will depend very much on circumstance. The issues to be addressed are canvassed in  Guideline: Software Development Plan, which also present a default project structure that may be adapted to a project's particular needs. The default structure also suggests a mapping of (Rational Unified Process) roles to the organization's positions. The shape and size of the project organization will vary across phases, and the Software Development Plan, a living document, will be updated to reflect these changes.

Based on the effort estimates for the project, the desired schedule, the chosen organizational structure and mapping of roles, the Project Manager determines the staffing profile (number of staff over time, and skill set) required for the project. The effort estimate for a project is of course not independent of team size, experience, skills and caliber - in all probability, the Project Manager will have made assumptions about staff capability, etc. when forming the effort estimate. In the COCOMO estimation model (see Task: Plan Phases and Iterations), staff capability and experience are major effort drivers. Therefore, selecting an acceptable total effort (by tuning the various COCOMO effort drivers) and a feasible schedule will determine the staff profile.

In some cases, the Project Manager may know in advance the numbers and skills of staff that will be available.  In these cases, with the staff size and skills set, only the schedule is variable, assuming the project scope stays constant.

The Project Manager must also be aware of the disruption that may be caused by ramping up staff levels too rapidly, and the potentially catastrophic effect on productivity of attempting radical reductions in schedule, by large increases in staff numbers.

Staffing the Inception and Elaboration Phases

During Inception, the focus is on defining and bounding the scope, and developing a business case for the project. Consequently, the team size is quite small: a Project Manager, a Software Architect, and perhaps a developer or two, especially where a proof of concept prototype is needed to clarify the requirements or build support for the product.

During Elaboration, the focus is primarily on the architecture and the architectural prototype. Consequently, design tasks in early elaboration focus on the architectural aspects; little attention is given to the details of the classes and their attributes, which although identified are not architecturally significant. During these iterations, most of the effort comes from your architecture team and a designated prototyping team. The prototyping team is usually put together by the more experienced programmers. At this point you have a very small design team that will focus on generic mechanisms and technologies. The test group will focus on building the test environment and testing the early use cases.

The choice of members of the architecture team should be made carefully: they should not only possess superior analysis and design skills, but also leadership qualities. In order to communicate the architecture to the larger team during the construction phase, a good practice is to distribute the members of the architecture team among the Construction teams. Members of the architecture team also need to cover a broad spectrum of software engineering experience: software design and implementation, performance tuning, database management, network management and configuration management include the major skill sets that must be represented in the architecture team.

Staffing the Construction Phase

The Construction Phase focuses on maintaining the architectural integrity of the system while building increasing functionality into the system. This requires architectural refinement (hence the "baselining" and not "freezing" of the architecture following the Elaboration Phase) and an architecture team that keeps an eye on the designers and their designs.

The architecture team will tend to distribute itself among the development teams, acting as technical leads and coordinating inter-group issues with the other technical leads. The Construction teams themselves must be cross-functional teams with both design and development expertise, as they are responsible for both the design and implementation of their assigned functionality. Typically, a Construction team is responsible for one or more subsystems with well-defined interfaces; changes to these interfaces or the addition of new subsystems causes architectural change and needs to be carefully considered. Within the subsystem, the team is relatively free to design and implement as it sees fit, but cross-team communication is needed to ensure that teams are not building the same implementation mechanisms in parallel.

Typically, Construction teams are usually organized horizontally, along the lines of layering. A team may be responsible for database interfaces, or communication infrastructure, while other teams focus on the application functionality itself. The "upper" layer teams as a result require more expertise in the problem domain and with User Interface design or interfacing with external systems. "Lower" layer teams are more intimate with the implementation technology. The composition of these teams must reflect these different skill demands.

Staffing Testing Tasks

The first question in test is how much formal testing are you required to do? And then, how much of this can you afford to do to meet your quality objectives and still be within reasonable limits from a cost and schedule perspective. It is rare that projects have the budget to do all kind of tests. Typically, projects must select a test level they can afford. Remember, each test specification must be inspected and maintained. It is very bad for project team morale if there are plans to create a lot of test specifications, but cannot implement those plans because you run out of time.

Create a specific test team. At least one person in the test team must come from the requirements capture team. The test team is responsible for

• Black-box testing. Test the use cases from outside the system on the basis of the use case's flow of events (see Artifact: Use Case).
• White-box testing. Test the actual sending of messages in the use case on the basis of the sequence views for the scenarios.
• System test. Stressing the system to reveal its true nature.

Remember that testing is not just to run the tests - it is also to prepare the test environment and to write and inspect the test specifications.

An independent group should test the use cases and the entire system. They should perform the tests and write the test reports as well. The work of testing the use cases should be organized so that there is one individual responsible for testing each use case.

If it is not possible for an independent group to test the use cases, as on a small project, you should at least make sure that the person responsible for a use case in design does not test the use case.

Automated regression testing should be used on medium and large projects. The test team will require some programmers to support this capability. This is even more important during an iterative development, where you do not want to expend a lot of effort re-running the same test suites again and again.

Staffing the Transition Phase

In the Transition Phase, development work is completed. Beta testing is conducted, and a final release is prepared. If a good job has been done in Construction, the project team can begin scaling back in size, reducing the number of developers and testers. The mix of the team will shift in favor of trainers and infrastructure logistics experts who are responsible for deploying the product into the user community.

The software architect, or architecture team, works in a "follow up mode": they help sort out problem reports, prioritize change proposals, and change orders to make sure that problems are not fixed for the sake of expediency in a way that damages the architecture. Design tasks recede during the transition phase, and are limited to correcting problems, or introducing last minute enhancements.