The PACE methodology consists of the planning, activating, controlling and ending phases. Planning includes the elements of developing the project formulation documents, such as the concept, scope, charter, and project plan. The activating phase kicks in when you' re actually engaged in formulating the project ' s deliverables. Variance analysis is good to perform because it illustrates to you how close you are to your task estimates. The controlling phase involves things such as teambuilding, risk response control, and scope creep control. The ending phase represents the
closing elements of the project— things like developing lessons learned, providing system documentation, training the help desk and support staff, and UAT. You could make an argument for putting UAT somewhere in late activating— these phases aren' t written in stone, they' re more gray than they are black and white—but usually the UAT lands in ending.
The PACE project management methodology (planning, activating, controlling, and ending phases) collapses a lot of the formalization of the IPECC methodology that PMI uses into fewer documents and steps. PACE is very useful for IT shops, while IPECC would be useful for very large projects—buildings, dams, bridges, airplanes.
A standard WBS should include the tasks, activities, and phases of the project. Each task, activity, or phase would also include the duration, the people working on it, and its cost. You wouldn t include any SOWs in the actual WBS (though they are included alongside the WBS in the project plan). Unless the finance department is a stakeholder, they don't need to sign off on the WBS.
Most IT projects qualify for bottom-up cost estimating. You deconstruct the deliverables to derive the tasks, activities, and phases, then estimate to see what each task will actually cost, in terms of physical or logical resources and time. Once all costs are assembled, you have a pretty good feel for what the project ' s going to actually cost. Sometimes you' l l be given a pot of money and told to make do with it to get your project done. A situation like that would involve top-down cost estimating. The other estimating techniques, while valuable in very large projects, probably don' t need to be utilized in most IT projects.
Vendor agreements should be nailed up and finalized in the
planning phase. At execution time, you re pretty far into the project to be worried about any given vendor.
A business case statement is a high-level, business-oriented overview that talks about the estimated costs of the project, how long it will take to pay back those costs, and what benefits can be derived from going forward with the project. A business case statement should not include IT tech-talk, and instead should be very business-oriented.
By far the largest risk to the project at this stage is scope creep. Customers drop by the cube of one of your developer and drop a hint or two that they' d like to see this and that in the code. The obliging team member, who feels that the customer is his—, well, customer, tries to meet the request. The problem with this scenario is that you' ve already gone all the way through requirements definition and everyone has signed off on the tasks to be done. Something extra is now out of scope, and if enough of these happen, the schedule and budget of your project can go way off kilter.
A milestone is a zero-length task that marks the accomplishment of something significant in the project. Because of that, you need to say how it was that you entered the milestone and where you ' l l go when you exit it.
Performance review method is especially critical in larger projects in which a person' s time will be wrapped up with the project for an extended period. Somebody has to give your team members their review during this time period. Working with the sponsor and stakeholders, you' l l define who will be responsible for that performance review effort and will state this in your scope document.
When performing your cost- and time-estimation efforts,
you ll build in a comfort factor, typically some percentage of the estimate, so that you have some leeway in budget and schedule. In projects that are rigorously managed using IuECC methodology, this factor building effort can become very detailed.
Well-developed preliminary preparation documentation, such as the concept, charter, scope, and project plan, will cause the project to be better simply because so much front end thought was put into the development of the project' s deliverables. The trick is in the planning and documentation of the project, although the other elements mentioned above are important as well.
Risk response control occurs at the controlling stage. In planning, you identify the risks to the project, quantify their potential impact on the scope, and then develop appropriate responses to the risks should they arise. In the controlling phase, if a risk transpires, you pull out the response you developed earlier and proceed to try to quash the risk before it creates damage to the project.
In the event that a project' s resources are exhausted, you have two choices: close the project out at the stage it' s at, or go to the sponsor for more resources. While the sponsor losing interest in the project might stall it, because you' re late in the execution, you would probably want your posture to be that you should complete the project. Key team members leaving the company could impair the project ' s scope, but since you re so late in the executing phase, you may not have much difficulty. Team member in-fighting isn t a good reason to close out a project (or shouldn' t be!).
A deliverable description talks about what the deliverable does, who uses it and it will "look like" (meaning how the screens will appear, etc.) Your concept and charter ' s
Was this article helpful?