The Project Plan will often be developed incrementally. The business requirement may well have some time and budgetary and performance constraints that strongly influence the plan. There will be the overall project plan, which will identify the high level tasks, and how this will be satisfied; there will also be a task and resource plan which will be used to schedule tasks. The Project plan will be incrementally improved and expanded and will be subject to document control.
The Essentials
A good project plan details how the successful outcomes of a project are to be achieved, it should have a work breakdown, but the work breakdown should not drive the plan. A good plan is driven by milestones and a good milestone delivers an output that can be introduced to the next stage of a project. A good plan is flexible and has contingencies and provisions for risk management. A good plan is driven by good work estimates. The project planning task for definition should start with scoping and finish with a review. An estimate should be prepared and it should be recognized that an initial estimate is not a project plan.
Define Scope
Scope is the driving force for requirements, estimation and risk management and is the bridge between the desired outcomes and the steps that must be taken to achieve the outcome. This is the first level of refinement after project initiation and should be discussed in a collaborative fashion with stakeholders. The initiation document has a description of what the project is to achieve, and the scope document will describe how the project will do this. This may be an iterative process where various business functions are considered as to whether they are in scope or not.
Risk Management
It is the Project Managers responsibility to manage risks and the Project Manager should only except risks that are within the scope of the project. Risks are like requirements and can become the subject of scope creep. For a project risk management is the process of turning uncertainty into risk and then implementing a treatment plan for that risk. This is another area where a standard can be applied, there are some standard risks associated with IT projects. This is not an area that can be addressed once, risk management is an ongoing process to ensure that project viability is maintained. Formal methodologies may well incorporate project gates that are used to control risk, these are not a substitute for risk management which will apply the treatment required to steer a project through the gates of the project plan.
Work Breakdown
Work breakdown must take the scope and define a set of tasks that will achieve the outcomes required by the scope. This is the where the project will be filled out with the types of skills required and the tasks may be classified into type, size, difficulty and frequency of use. Where there are repetitive and structured tasks these should be identified to aid the estimation process. Any metrics that can be defined at this stage will be useful, number of screens, tables, fields. As part of the design aspect, work breakdown may be the first place where common requirements are identified.
Normally work breakdown will be at a lower level than initial estimation. Estimation will be a for a component, whereas the tasks of the work breakdown will encompass all of the activities required to produce a ‘finished’ component.
Estimation
Work estimates for IT projects is often at a high-level of granularity, changes to work practice can led to a lower level of granularity in the estimates. The first work break down should provide the information required for estimation. The estimates derived from the this method have been validated against more traditional methods and past experience. The key features of this method are the complexity metric for each task, the explicit complexity curve, which accounts for the uplift in effort required for more complex tasks, the constant used to establish the curve and the scaling factor which will turn the formula value into a work estimate.
This method combines two established methods of estimation, the ‘like’ method of comparing similar functions and the metric method of using function attributes.
The Formula
WorkEstimate = Int(ScaleFactor * ((100 – (Reuse * 100)) / 100 * (OPE * (Log(OPE) / Log(OPEBase)))))
Typical values:
ScaleFactor = 2, OPEBase = 5 And OPE is the Point Equivalent
The formula uses the points and the reuse and a logarithmic uplift factor to produce an estimate. The uplift weights more complex tasks. Key features are the ability to turn ‘OPE’s into person days with an uplift on more complex tasks, and the inclusion of ‘reuse’ to assist in estimating changes and enhancements.
An OPE is an ‘Object Process Equivalent’, it is not the software metric Function Point, but is a conceptually related metric representing a raw unadjusted function or object point equivalent designed to replace simple/medium/complex with finer granularity. There is no reason why this formula should not work with Function Points and this would provide a method of providing an additional working estimate. A simple model would be data entry: selection screen + view screen + update screen+ one data object + one updated table = 5 points.
The ‘OPE Base’ parameter is used to benchmark our known estimation point and the ‘Scale Factor’ to convert the whole thing to person days. The ‘Scale Factor’ is a multiplier sometimes called the software development effort. This can been estimated from previous developments
Reuse: This metrics is used to reduce the effort based on reuse of existing code or the fact that a certain percentage of the code remains unchanged.
An advantage of this method is that the actual effort can be registered against the plan and factors updated to produce revised estimates. The formula can be embedded in a spreadsheet for ease of use and may even be defined as a function. Establishing a base factor is fairly simple as this will normally be close to the average of the chosen metric for the project. The scale factor can be estimated and then revised as the project progresses.
Planning Review
At his stage costing has been reduced to another stage of granularity and work effort is defined. The project plan can be reviewed by the stakeholders in order to establish realistic user expectation. If variations are required they should be incorporated into the project plan, scoped and costed.
Then planning review is the final stage of project definition and should be considered a gate on the project; however at the same time there is not need to pause a project for review unless there are genuine doubts as to project viability.