Develop Project Staffing Agreements


During both the estimation process and the scheduling process, you could be making some major assumptions and, as a result, some major estimation errors.

As we discussed earlier, the people you will have on your team and the experts that you have from your critical stakeholder areas are the main determinant of your project's success.

Oops! Wrong Planet, Wrong Person

Every project manager has experienced the sinking feeling that the person you assumed you were going to have allocated to your project, either as a team member or a stakeholder representative, turns out to be unavailable and you get a substitute.

As shown in Figure 15.8, the work of Weinberg (1971), Jones (1994), Boehm (1989), and Putnam and Myers (1992) has shown that the variance between excellent and poor performers in the project environment is huge. If you assumed a fairly high-skilled person and end up with a person with below-average skills, your estimates for the tasks that person is going to undertake could be off by an order of magnitude!

Figure 15.8. A really bad mistake: A common reality

graphics/15fig08.jpg

Projects as Elephant Graveyards

One of the great tales we all hear as children is the tale of the elephant graveyard where elephants go to die. In the project world, there is another variation on this tale. The process culture simply uses your project as a convenient "graveyard" for business people who have out-lived their usefulness in their own jobs. You need to be very aware of this behavior and part of the purpose of the project staffing agreements is to give you some room to negotiate if your project is becoming an elephant graveyard.

A Typical Skill Model

There are different types of skill models. In addition, some organizations are moving to the concept of competency analysis rather than just skills analysis. Competency analysis or modeling extends the analysis of an individual or a job to three areas:

  • Knowledge: What does the person know?

  • Skills: How is the knowledge converted to skills?

  • Behavior: Is the person's attitude and application of the skills appropriate?

For example, a person may know the theory of systems analysis (e.g., data modeling, cost “benefit analysis, etc.) and he or she can develop reasonable analysis requirements. However, his or her attitude and behavior toward business people and ability to work with other people is not good.

However, for the purpose of project planning the model contained in Figure 15.9 would be sufficient for documenting your key assumptions about your project team and stakeholder experts.

Figure 15.9. Skills matrix

graphics/15fig09.jpg

graphics/extool.gif

If you already have your team members, then you should still use the skill level model in Figure 15.9 for each team member. Of course, you would do this participatively with each one. It may also be useful to get other team members to review each other's skill levels to avoid any bias.

Having determined the appropriate levels of skill that you have assumed when developing your estimates and adjusting your schedules, you should then take the extra step and develop a formal staffing agreement, as shown in Figure 15.10.

Figure 15.10. Project staffing agreement

graphics/15fig10.jpg

The project staffing agreement or contract simply documents your assumptions regarding team skills and assists in documenting any specific timing requirements regarding access to various experts, any costs or fees involved, and, most important, what person or what skills could be used as a "backup" if your requirements cannot be met. You'll recall our partnership agreements; this is just another variation on that concept.

Virtual Team Twist

With a virtual team, you may need to complete a staffing agreement with your virtual team members. This is a little bit of overkill, as the team member effort should be shown in your project's schedule. However, you are still more exposed to virtual team members than traditional team members, so use your common sense here.

The P Files Episode 12: The Fantasy Plan

We were involved in the initial planning of a major project involving the takeover and merger of two significant companies. A corporate project office had been created to report to the CEO and executive team on the status of the project. The merger team, in the company that had taken over the other company, was using the event concept that we developed for eXtreme project management. Until the two organizations signed off on the merger, there was almost no information available to the team about the structure, technology, systems, or products of the acquired company. We had planned all the tasks required prior to the takeover scheduled for about two months in the future. The corporate project office person (stricken with Newtonian neurosis) insisted on a one-year detailed task list. We explained that we couldn't identify the tasks until after the takeover and detailed examination of the real situation in the new company. Frustrated, he said, "Look, I know the plan you will give me for the CEO will be wrong, but at least it proves to him that you are working and thinking."

The P Files Team Comment

What can we say? The project was very successful, as the team adopted the L.A. Law model of planning that we discussed earlier. Each morning, for more than a year, all the project managers (more than 50 of them) met every morning in "the war room" to plan, replan, and to network. The original "plan" that proved we were thinking was never followed.

Case Study ”Develop Schedule

Working with Kim, Joan, Edwina, and the hardware guru from No Object, you develop the schedule shown here:

graphics/15fig11.gif

The major assumption is that Joan is full-time on the project as she has to work with Kim on tasks such as the Web content and quality assurance. What the scheduling process reveals is that you need a quality assurance person for Kim. No Object agrees to provide an external Web guru for 16 hours of quality assurance. The cost will be $1,600.

You and the team are confident that you can deliver Release 1 within six weeks. Remember that the schedule is based on likely case estimates. However, your project is dependent on the acquisition of hardware, which is shown as Event 1 in the schedule.



Radical Project Management
Radical Project Management
ISBN: 0130094862
EAN: 2147483647
Year: 2002
Pages: 136
Authors: Rob Thomsett

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net