Activity: Acquire Staff
Purpose
| |
| Role: Project Manager | |
| Frequency: As required, typically at least once per phase, then revisited as needed. | |
| Steps
| |
| Input Artifacts:
| Resulting Artifacts:
|
| Tool Mentors: | |
| Workflow Details: |
Staff the Project
The Project Manager will have determined the staffing needs for the iteration in Activity: Define Project Organization and Staffing, and will look to the Human Resources function of the organization to provide staff with the needed domain, skills and experience profiles. Most organizations do not have the luxury of keeping a large pool of staff on stand-by for projects, and project starts do not always neatly synchronize with the termination of previous projects. Frequently then, except for a few staff engaged on the project from the outset, many will need to be hired. This may be a lengthy process, so the prudent Project Manager will always be looking ahead, and initiating the acquisition of staff for future iterations as well as the current one. It may be possible to cover shortfalls by working overtime or by the use of contract rather than permanent staff. Both these solutions have disadvantages, and any systematic and persistent shortfall in staff levels is a serious risk to schedule.
Map Staff Skills to Roles
A role defines the behavior and responsibilities of an individual, or a set of individuals working together, in the business. The behavior of each role is defined as a set of activities. The responsibilities of each role are usually defined relative to certain artifacts, such as documents, for example. Examples of roles are designer, software architect, and reviewer. Through the associated set of activities, the role also implicitly defines a competence.
Note that roles are not individuals; instead, they describe how individuals should behave in the business, and what responsibilities these individuals have.
The project typically has at its disposal a number of resources, individuals which have specific competencies. For example, Joe, Marie, Paul, Sylvia are individuals with different, although overlapping competencies. Using the roles defined in the process, map resources available to the project onto roles they can play.
The association of individual to role is dynamic over time, driven by the phase in the project lifecycle and the work to be performed.
- An individual might act as several different roles in the same day: For example, Sylvia might be a Reviewer in the morning, and a Use-Case Designer in the afternoon.
- An individual might act as several roles simultaneously: For example, Jane could be both the Software Architect and the Designer of a certain class, and also the Package Owner of the package that contains this class.
- Several people can act as the same role to perform a certain activity together, acting as a team: For example, Paul and Mary could be both Use-Case Designers of the same use case.
Try to allocate responsibilities so that there is as little hand-off of artifacts from one resource to another: have the same person or team design and implement a subsystem, so that they do not have to re-learn work already done by others.
When the same team designs as well as implements, there is a smooth transition from design to implementation. In addition, it makes for better designers: by learning what works and what does not, they gain a better sense of good design and incorporate it into future work. Like a sculptor, the good designer must understand the medium of expression, which for software is the implementation environment.
Form Teams
The shape of the project organization and the required staffing levels for the iteration have been decided by the Project Manager in Activity: Define Project Organization and Staffing. With the knowledge of actual resource availability, it remains to fine-tune this structure and assign staff to it. The Project Manager should reexamine any team of more than seven staff to see if there is some architecturally sensible way in which it may be split, say along subsystem lines.
Teams should consist of a minimum of two people and a maximum of about seven; teams with more than seven people usually naturally split themselves into sub-teams, so it's best to do it for them to make life simpler.
In assigning staff to teams, the Project Manager should be sensitive to the overall experience and familiarity level of the team, and try to create teams with a mix of 'new blood' and staff who have been with the project for some time. At the beginning of a project, the Project Manager will have to rely on blending experienced staff with more junior staff.
Train Project Staff
In many cases, an inventory of the competencies of the resources available to the project will reveal gaps in the assignment of team members to roles (assuming that the normal course of trying to recruit additional team members or hire external contractors has already been tried). In this case, skills will need to be developed. Appropriate training and mentoring must be obtained for these people, in advance of but in close proximity to the time when they will need the skills. Training not put to practice immediately rapidly decays. Often, the combination of formal training followed by a mentor-led workshop to 'jump-start' an activity is particularly effective at putting the new skills to work.
