In the previous post we looked at some approaches to identifying uncertainties during the Initiation process group. During Initiation, the project is dealt with more as a whole than at the level of the individual activities required to implement it. In the Plan process group, which follows Initiation, the project is decomposed into a Work Breakdown Structure (WBS)—the individual sets of tasks that will produce components of the product that is the goal of the project. The WBS units are called Work Packages and defining them, ordering and connecting them into a network, estimating the time and effort required to complete them, assessing the uncertainties associated with and calculating a contingency allowance for each of them is one of the PM’s most critical set of activities on the project.
‘MACRO’ VS. ‘MICRO’ UNCERTAINTIES
The uncertainties that are identifiable at the end of Initiation are ‘macro,’ i.e., meaningful at the project level but not necessarily ‘micro,’ or meaningful at the Work Package level. Macro uncertainties include such things as:
- Organizational issues that might complicate achieving a clear statement of the project’s definition, goals, constraints or success criteria or impede the progress of the implementation
- Feasibility issues that apply to presumed technical solution enablers or, equally, to organizational or procedural changes required to implement and realize the targeted benefits of the project
- Technology issues, such as the emergence of a disruptive new technology that could impact the competitive stature of the product in the marketplace at or after its completion
- Strategic issues that might substantially alter or obviate the business justification for the project
- Financial issues that could result in a reduced ability to obtain funding for the project
- Regulatory Issues that might result in additional or unplanned-for requirements during the life of the project
- Sourcing issues, such as exposure to cost increases resulting from the instability of a critical vendor
- Resource issues, such as availability of staff or infrastructure for the project
Among all the macro uncertainties that warrant consideration during Initiation, the major concern is the ability to collect, analyze and finalize the detailed project requirements in a timely fashion. Project Scope (the solution requirements) is the main driver for all of the subsequent planning activities, including the project’s schedule and budget and all of the other knowledge areas. It is the first activity in the Planning process group and a response that addresses any downside uncertainty as to whether defining, documenting and obtaining signoff on requirements can be completed in the intended timeframe must be identified before finalizing Initiation.
The activities in the first half of the Plan process group are intended to produce a preliminary WBS and plans for managing schedule, costs, quality, people, communication and procurement; however, getting to that point requires that a number of issues be resolved or decisions made, which include:
- Finalized architectural definition and overall solution design
- Selection of implementation technologies
- Definition of a build plan and decomposition of the build process into reasonably-sized work packages, which may include activities such as resource procurement or user training in addition to software construction
- Ordering and linking of the work packages into a network for analysis
- Identification of the project’s critical path
- Identification of staffing requirements
- Preliminary cost estimates by work package
- Specification of the QA process and its integration with the development process so that required time and potential need for rework can be accounted and planned for
- Development of communication and HR plans
WORK PACKAGES, SUCCESS MEASURES AND ‘MICRO’ UNCERTAINTIES
After the initial WBS, activity list and the quality, communication, procurement and HR plans are complete, ‘micro’ uncertainties can be identified and the Manage Risk process can progress to focusing on those that are specific to the project and its intended end products, staffing and implementation. The PMI Plan process group provides for iterating the steps from the beginning of the process group to this point until an optimum (or near-optimum) schedule and budget for implementing the specified scope are reached. Assessing, creating response plans for and designating reserves for uncertainties at the work package level, figures heavily into the iteration and optimization process.
For the sake of analysis, let us define the success of the project to be determined by the success of the execution of each of the work packages, as determined by:
- On-time completion (Time)
- On-Budget completion (Cost)
- Fully-functional output (Scope )
- No need for rework (Quality)
Note that these criteria map nicely against the Triple Constraint, which we are using to prioritize our Manage Risk efforts. We can use this framework to help identify uncertainties at the work package level and tie them to our priority scheme. Let’s look at common factors that contribute to the occurrence of negative outcomes against our plan:
TIME
Work packages are scheduled to start at a certain point in time, run for a specified duration and complete at a specified point in time. Failing to complete on time, then, can be seen as the result of:
- Starting late, due to a dependency on a predecessor or unavailability of required resources
- Running long, because the work required was mis-estimated, the resources assigned were less productive than expected or the technology employed in the work package did not perform as expected
- Some other exogenous cause
COST
Work packages run over budget when they run long and have a time-related direct cost associated with them, such as a consultant that bills on a per-hour basis. Alternatively, this can result from an unplanned substitution of more expensive resources than was the basis for the plan estimate or an increase in the scope of the work package.
A work package involving procurement may run over budget when the procurement is not completed at the planned price.
SCOPE
Scope shortfalls are often the result of conscious decisions to trade functionality for time or cost goals; however, the need to make the tradeoff is likely to have been caused by a factor that has previously contributed to either a time or cost overrun, as listed above. Therefore, the root cause of Scope deficits are more likely to trace back to a negative outcome of a time or cost uncertainty.
QUALITY
A quality shortfall may relate to either a scope shortfall, failure to meet the defined acceptance criteria for the work package’s product or the user refusing to accept the work package’s product on other grounds, such as usability issues. Regardless of the cause, a quality failure will most often lead to rework with an attendant probability of cost and time overruns.
‘MICRO’ UNCERTAINTIES
In looking back over the list of factors that can contribute to Work Package-level negative outcomes, above, there are several recurring ones that are prime candidates for evaluation as ‘micro’ uncertainties:
- Accuracy of the estimates that contribute to the project scope, time or cost baselines
- Degree of flexibility built into the project plan to allow for fallbacks that minimize impacts
- Coordination of interdependent work packages and other activities; being able to identify cases in which slippage in one work package will impact numerous others
- Changes in scope and the PM team’s ability to either prevent or accommodate them
- Staff experience, expertise and productivity; overall team performance
- Performance of the specific technologies to be employed in implementing the solution
- Procurement success
- Availability of resources—people, infrastructure, funding, etc.—in the quantity, quality and at the time expected
- Project team dysfunction that could require remedial action
- Performance of non-team members on tasks that impact on work packages, such as reviewing and approving outputs or work products
UNCERTAINTIES INVENTORY
The two lists presented in this post constitute a robust framework for constructing an inventory for a systems development project. The ‘macro’ list contains issues that should be given consideration during Initiation and consists mainly of issues common to all IT development projects. In many cases, merely articulating the concerns with a project’s sponsors and leading stakeholders is sufficient to ensure adequate organizational representation and participation. In other cases, it may be necessary to explicitly negotiate the organization’s involvement in the project in order to mitigate the many negative impacts that might otherwise result. The ‘micro’ list can only be elaborated after a number of decisions have been made with respect to how the project will be conducted and implemented.
N.B., while identifying and qualifying uncertainties is a necessary step in the Manage Risk process, it is merely the first one. Once relevant uncertainties are identified, then they must be prioritized, analyzed, eliminated or mitigated to the degree possible (and cost-justified) and responses to be executed in the event of their occurrence defined. This is a subject beyond the scope of this post.
WHAT’S NEXT?
The next post in this series will present a framework that can provide a head start to the process of identifying uncertainties comprehensively and an approach to evaluating candidates for inclusion in your project’s risk register.