Planning When to Build


Lead Advocacy Group: Program Management

Solution requirements specify what needs to be built. Solution designs and project plans specify how to build a solution. The next step is defining actionable tasks from this information and sequencing them to start to form a project schedule. To complete the effort, a schedule needs additional data such as how long will it take to complete the tasks, how the tasks relate, and who will be performing them.

Depending on the size of the effort, each subteam forms their own schedule and integrates them together in a master project schedule. Having a master project schedule provides the same benefits as discussed for having a master project plan (e.g., facilitates concurrent scheduling by various subteams). In addition to subteam schedules, it might be warranted to have cross-team schedules that correspond with projects plans (e.g., training plan). Table 8-13 provides a few examples of these plans and identifies which advocacy group leads the scheduling effort.

Table 8-13. Examples of Typical Cross-Team Schedules

Typical Schedules

Lead Advocacy Group

Communications schedule

Product Management

Build schedule

Development

Training schedule

User Experience

Test schedule

Test

Budget schedule

Program Management

Deployment schedule

Release/Operations

Purchasing and facilities schedule

Release/Operations

Pilot schedule

Release/Operations


Assembling schedules involves a few steps that should be followed in order, as depicted in Figure 8-9. The first step is to figure out what needs to be done (i.e., tasks). The second step is to estimate the work necessary to complete each task. The third step is to identify task dependencies (i.e., predecessors). The fourth step is to figure out who is to perform each task. The final step is to identify when to perform each task. This iterative process takes a few passes to get all schedule elements balanced and optimally adhering to project constraints and personnel commitments (e.g., vacation, holidays, and training). Each of these steps is discussed in the next few sections.

Figure 8-9. MSF scheduling process


Step 1: Identify Tasks

Guided by project plans, teams must convert requirements and design elements into actionable tasks. It is expected that these tasks will be at different levels of granularity. The goal is to get a consolidated list of tasks that represents all work necessary to deliver a solution. Within the list, the tasks are then sorted by a number of means (e.g., by feature team and then by role). This sorted list is often referred to as a work-breakdown structure (WBS).

While assembling the WBS, it is helpful for later trade-off analysis to assign an overall priority to each task and potentially identify alternate tasks that represent alternate approaches. Later iterations of the scheduling process will eliminate the less favorable alternatives.

Step 2: Estimate Work to Complete Tasks

With the body of work identified as actionable tasks, the focus changes to estimating how much work is required to complete the tasks. Not to be confused with duration estimating, which is the period of time in which to perform the work (discussed in step 5), the estimated work is a measure of how long it would take one person with the benchmarked skills to complete the task. It is important to understand why the estimates need to be calibrated to some benchmark. If one person estimates the task given his or her own skills but another person with different skills is assigned the task, it is highly unlikely that the estimate is valid. Typically, a team agrees to a benchmarked set of skills when developing the estimates.

Many good approaches can be used to derive estimatestoo many to cover here. Here is a quick summary of some commonly used approaches:

  • Program, Evaluation, and Review Technique (PERT) A mathematically derived estimate based on an optimistic, expected, and pessimistic estimate

  • Delphi An estimate based on expert opinion

  • Parametric An estimate based on actuals from other projects doing similar activities

  • Prototyping An estimate derived from performing a limited portion of the scope to get a sense of how to estimate the remainder of the tasks

These approaches are used in top-down or bottom-up estimating. Commonly, the Product Management and Program Management teams drive a top-down view of the estimates to reflect the various project constraints, whereas team members drive a bottom-up approach. It is healthy to compare and contrast these two opposing approaches because the process often uncovers requirements gaps, readiness gaps, mismatched stakeholder expectations, and unrealistic project constraints.

Having team members estimate their own tasks is an important aspect of team empowerment. That way, the people doing the work make commitments as to when it will be done. The result is a schedule that the team supports because they believe in it. MSF team members are confident that any delays will be reported as soon as they are known, thereby freeing team leads to play a more facilitative role, offering guidance and assistance when it is most critical. The monitoring of progress is distributed across the team and becomes a supportive rather than a policing activity.

Lesson Learned

As a rule of thumb, tasks should be decomposed such that their estimates are greater than four hours, but less than one week. Tasks with estimates of less than four hours are too granular. Tasks with estimates longer than a week should be decomposed into smaller taskseven if it is just splitting a task by adding a review checkpoint or publishing a draft of a deliverable. Ideally, tasks should be a day or two in duration.


Lesson Learned

Rather than confusing a team with project manager jargon such as asking for PERT estimates, just communicate that each team member needs to provide three estimates for every task: reasonable best case (i.e., optimistic), expected, and reasonable worst case (i.e., pessimistic). In addition to being necessary estimates for scheduling, these estimates show the estimator's level of confidence in performing the tasks. Specifically, a small estimate variance between the best-case and worst-case estimates shows the estimator is confident (i.e., minimal uncertainty); a large variance signals low confidence that translates into risk. Low confidence might be a result of many factors (e.g., technical challenges, lack of skills, and clarity of requirements) that should be investigated.


Buffer Time

Classically, on every project, the question comes up about how buffer time should be factored into a project schedule. This is typically an awkward conversation with sponsors because project teams seldom provide adequate justification surrounding the need and application of buffer time. As such, sponsors typically balk at buffering estimates because they view it as unnecessary padding.

To break this pattern, there should be an open and frank discussion surrounding buffer time. Experience shows that no matter how seasoned a team is, unplanned events, risks, and issues that result in nominal impact on a projecttoo incidental to submit for change management consideration but significant enough that a team must plan to absorb them into the scheduleare realized. Buffering adds time into a project to enable a project team to absorb these unexpected issues. Buffer time should not be used to compensate for the time needed to add a feature or change a resource. These changes should continue to be processed through change management.

A project team and sponsors need to reach agreement at how buffer time should be incorporated into a project schedule. Buffer time should not be associated with individual tasks because, inevitably, it will be absorbed as part of the task estimate and, accordingly, the planned work will expand to fill the allotted time (Parkinson's Law)[5] as opposed to being used for unplanned eventsthe intended reason for buffer time. Instead, buffer time should be associated with higher-level task aggregations such as work streams.

Rather than building in the classic 20 percent buffer time around major deliverables and checkpoints, a recommended approach at figuring how much buffer time is needed for a given project is to use the results from the PERT analysis (i.e., difference between the expected and pessimistic estimates). This approach is much more defensible because it is supported with data down to the task level.


[5] C. Northcote Parkinson, Parkinson's Law: The Pursuit of Progress (London: John Murray, 1958).

Step 3: Identify Task Dependencies

A task dependency exists when other tasks must be started or completed before the task in question can start or be completed. For example, the install Microsoft Windows operating system task needs to come before the install Microsoft Exchange Server task. It is important for team members to define their tasks in consideration of what else is needed to perform the tasks (i.e., task dependencies). This is especially important when dependencies cross team boundariesthe other team might not know of the dependency and might overlook it.

Adding dependencies is not as simple as sequencing tasks. It also includes identifying situations where it is prudent to delay tasks (i.e., waiting with no planned activity before starting a task). For instance, after a server build, it is prudent to wait a short time to make sure the server is operating as expected before performing other tasks with that serveroften called a "burn-in" period. These quiet periods do not show up as tasks. Rather, the time is built into the dependencies. For instance, a task of hanging a picture (task 2) on a newly painted wall can start no earlier than two days after completing the painting task (task 1). Needing to wait while the paint dries is not a task. It is a condition placed on the association of the two tasks (i.e., task 2 is dependent on the successful completion of task 1, plus a minimum of an additional 2 days).

Step 4: Identify Who Will Perform the Task

At this point, the team has identified and estimated tasks and has identified cross-task dependencies. The focus changes to evenly distributing the work among the available resources.

A few approaches can be used to assign resources. One approach for the first pass is to assign a role title for each task (e.g., Senior Exchange Engineer 1). Later on, these role placeholders are replaced with team member names. This is helpful if team members are playing multiple roles. Putting role placeholders first enables a team to think about what is needed and helps them avoid getting caught up with specific team member skills and constraints (e.g., availability). Cost might also be a consideration. Putting role titles first is often much easier to change later than is assigning specific team member names (e.g., when project cost constraints necessitate using a less senior resource).

Another approach is to make resource assignments based on small subteams (e.g., commonly called work streams). With this approach, work is assigned to a work stream team, and the work stream lead is empowered to manage the assignments among the subteam handling the work streamproviding team cohesion. This approach of balancing work among work stream teams is much easier than balancing among individual team members.

Lesson Learned

When using tools such as Microsoft Project to help balance work among resources, adjust the time interval in the resource usage report from the daily view to something more practical. A commonly used period to balance is a work week (e.g., 40 hours), as shown in the following figure. Balancing work to a shorter interval than a week does not add more value and is much more work.

  

October

November

Resource Name

Work

16-Oct

23-Oct

30-Oct

6-Nov

13-Nov

Denise Smith

191hrs

40h

35h

38h

40h

38h

Joe Healy

190hrs

38h

39h

34h

40h

39h



Step 5: Determine When Tasks Will Be Performed

Up until now, the scheduling process has not been influenced by project trade-off matrix decisions. As such, task start and finish dates have floated to be what was dictated by the sequencing effort. If the lowest trade-off priority from the Project Trade-off Matrix (discussed in Chapter 7, "MSF Envision Track: Defining a Solution") is schedule, the schedule is what it is, and therefore scheduling is done. However, this is rarely the case. This step focuses on adjusting these dates to fit date-oriented project constraints.

Many approaches to compressing a schedule can be used to make the schedule fit within date-oriented project constraints (commonly called "crashing the schedule"). The best guidance on how to proceed is to reference the priorities specified in the trade-off matrix. If features are a higher priority than resources are, adding resources is the best course of action. Otherwise, removing features is the best course of action.

Another aspect of determining when tasks will be performed is to look at the environmental constraints. For example, organizations often have "black-out" or "freeze" periods where no production changes happen (e.g., accountant organizations often declare a few months prior to tax day a period where no production changes are tolerated).

Lesson Learned

Microsoft Project is a helpful tool in agile-oriented iteration planning. If the project governance approach is to have little up-front planning, here is a resourceless way to approach it. Add work tasks to Project as usual. It is OK to use the Duration field for work estimates, but it is much better to use the Work field to reflect your estimates. Create a set of parent tasks (e.g., Iteration 1). Use milestones to indicate iteration end dates (an iteration start date is the end date of the prior iteration). Calculate your team's work capacity (i.e., amount of work your team can handle during an iteration, such as 6 people * 6.5 hours/day of work * 20 work days/month * 1 month iteration duration = 780 staff hours). As you add tasks to an iteration, the work associated with that iteration parent task starts to increase. It is good to leave a buffer, so maybe add only 600 hours of work per iteration. Rather than using a buffer, I like to use the PERT fields (i.e., high, low, and expected as discussed earlier). Use a planning number between the expected and high estimates for the number of staff hours per iteration (closer to the high). If unplanned tasks need to be added into an iteration, bump lower-priority items to the next iteration.

If you need to assign resources, use the preceding approach, but instead of calculating the team's capacity, calculate each team member's capacity. Fill up team members' buckets of work per iteration just as described here.


Creating a Master Project Schedule (Deliverable)

Lead Advocacy Group: Program Management

In addition to balancing schedule elements on each subteam, the elements need to be integrated and balanced across a project. The cross-project elements and activities are consolidated, integrated, and balanced within a master project schedule.

The master project schedule integrates the various subteam schedules needed to deliver a solution. It typically calls out significant tasks, deliverables, and checkpoints, providing an overview of a project. Figure 8-10 is an example of a project schedule summary with three work streams.

Figure 8-10. Example of a master project schedule summary





MicrosoftR Solutions Framework Essentials. Building Successful Technology Solutions
Microsoft Solutions Framework Essentials: Building Successful Technology Solutions
ISBN: 0735623538
EAN: 2147483647
Year: 2006
Pages: 137

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