OVERSEE DETAILED PLAN DEVELOPMENT
|
Uma reiterated to the team in a memo that they would use a lessonslearned process at every stage of the project. Uma wanted the team to brainstorm lessons learned from the planning stage of similar projects.
Sanjay realized that among the first tasks was choosing the hardware and software. Gary, as the CIO, needed to make these decisions. He also needed to select and hire consultants. However, this could not be accomplished until the schedule was developed.
Uma wanted the team to develop a risk plan detailing all the risks that were discussed in the initiation stage. This risk plan would include an assessment of the probability of each risk event happening, the consequences if it did happen, and contingency plans where needed. Some of the team members argued that they had already discussed the risk at the initiation stage and that was enough information for them to move forward with preparation of the work breakdown structure (WBS). She reminded the team that a WBS is a detailed listing of all the project work. They could include a contingency plan later in their schedule.
Uma sensed that the team was getting restless and wanted to get on with the project. She made it clear that she understood that some of the team members felt that they were not using time wisely, but she felt that time spent on risk planning was crucial. A mistake at this point could create a major problem later.
When the project charter was developed, the team had to develop time estimates for the major phases of the project. Now, as the team got ready to create the WBS, they decided the first step was to work on a major milestone plan and identify the deliverables at every milestone that would be shared with stakeholders for their approval. The milestone plan is shown in Table 3-2.
 |
| Milestone | Delivery week | Deliverable |
|---|---|---|
| | ||
| Project planning and initiation | Week 2 | Project charter, project scope definition, work breakdown structure, project budget plan, communications plan |
| | ||
| Requirements analysis, system design specification and architecture | Week 5 | Systems requirements document, use case document, functional specifications, technical architecture design document |
| | ||
| Technical design and network design | Week 7 | Technical design specification document, network design document |
| | ||
| Development and configuration | Week 15 | Order processing system ready for integration testing, documentation of configuration, customized user manuals, training materials |
| | ||
| System acceptance testing | Week 18 | Test plans used for testing, results of regression testing |
| | ||
| Training | Week 19 | Training manuals |
| | ||
| Transition and transition support | Week 21 | Transition document detailing roles and responsibilities in the day-to-day maintenance of the system |
|
Having completed the major milestones, the core team began constructing the WBS. As they developed the WBS, they assigned resource requirements to every item. Estimated hours of resource requirements are summarized in Table 3-3.
|
| WBS Category | Resource | Hours |
|---|---|---|
| | ||
| Requirements analysis | Consultant | 80 |
| | ||
| System design and architecture | Consultant | 60 |
| | ||
| Technical and network design | Consultant | 80 |
| | ||
| Development | 5 full-time internal | 2000 |
|
Chris wanted more time allocated for design and Paul wanted more time allocated for quality assurance (QA). Uma then asked each of the team members to have a meeting with their subject matter experts (SMEs) separately to complete the WBS detail for their subteam's work. She also wanted them to show all dependencies and to input this into a schedule using Microsoft Project. Then Uma took their individual schedules, merged all of them into a schedule for the entire project, and presented it to the whole team, including the SMEs. After much discussion and various requests, a schedule emerged that everyone felt was reasonable.
Bob and Uma then used the schedule as input for their detailed budget. They broke down costs into the major components of internal resources, subcontractors, consultants, training, travel and administration, and cost of the project office. They assigned costs to major WBS components and decided to track actual costs against their estimates. Then Bob and Uma shared their results with the team.
Project Leadership Considerations
Uma acted responsibly as a project leader in overseeing the detailed plan development. She kept the customer's priorities in mind and worked in a logical order for the most part. Some project leaders would prefer to work through more of the WBS before finalizing the risk plan. Uma worked through the higher levels of the WBS with her core team, then had each core team member develop the details of their respective areas with their SMEs, and finally integrated the entire plan with anyone on the complete team making recommendations where there were conflicts. By using this method, Uma achieved efficiency in the work process and a more empowered workforce.
Once the WBS and risk plans were complete it was time to determine who should perform each identified task, what the durations and predecessors should be for each task, and how all this information should be combined into a workable schedule. Project leaders need to facilitate this activity, but do not have to perform it all personally. Technical leads, schedulers, and others should be able to perform much of this work. Nonetheless, project leaders need to understand what questions to ask, when to offer help, when to take over, and when to back off.
A final component of detailed project planning is the project budget. Top leadership in an organization sees a budget as a tool to assist in prioritizing organizational goals. Through the budget, top leaders allocate resources to selected projects, with more resources going to higher priority projects, and no (or few) resources going to low priority projects. Thus, as projects serve as means of accomplishing the goals of an organization, budgeting serves as the means of prioritizing those goals.
Project leaders can develop their detailed budget only if they have an understanding of the project WBS and schedule. Once these are understood, it is possible to determine the cost. If the expected cost is significantly different from the spending authority granted in the project charter, a serious discussion needs to take place. This could involve using a different approach, changing the project's scope or schedule, or canceling the project.
It was surprising and problematical that the detailed budget was shared with the whole team. While ideally teams share all information, it is debatable whether or not detailed budgets of other people's areas should be shared with the project team.
As project leaders oversee the development of the detailed project plans rather than get caught up in the details themselves, they need to:
-
Understand who gives good advice on the project plan and who gives poor advice. Some project team members will have a much better understanding of how to plan than others.
-
Ensure that risks continue to be uncovered and addressed. Hiding risks may be tempting to secure project approval, but gaining acceptance of a project with buried risks may be a Phyrric victory.
-
Encourage the project team to pursue innovative approaches where appropriate and to reuse or adapt approaches developed previously as appropriate.
-
Understand that project team members both remember best and commit to those things that they "discover" on their own. Orchestrate the plan development process so that team members can make "discoveries".
-
Realize that by active listening and following, a wise project leader both gains influence with her team and encourages the team to self-manage.
Before this step was complete, it was very important that Uma ensure that everyone fully understood and was comfortable with the details of their own budget so that they could take "ownership" of their part of this project as well as the entire project.
|
A Project Leader Needs to:
Accept that the project team and SMEs will develop large parts of the project plan
Have the courage to challenge planning details
Exercise the wisdom to know when to trust and when to question.
|
|
