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.

Table 3-2: B2B Project Milestone Plan


Delivery week


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


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.

Table 3-3: B2B Project Resource Requirements

WBS Category



Requirements analysis



System design and architecture



Technical and network design




5 full-time internal
2 consultants


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.

start sidebar
Project Leadership Lesson: Planning—Project Details

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.

end sidebar

Project Leadership
Project Leadership
ISBN: 0071388672
EAN: 2147483647
Year: 2005
Pages: 106

Similar book on Amazon

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