In the first two posts in this thread we looked at two classes of project uncertainties—‘macro’ uncertainties, whose impacts are felt at the project level, and ‘micro’ uncertainties, whose impact is discernible at the level of individual Work Packages. Given the PMI project management lifecycle, these uncertainties become concrete and must be dealt with at two different points. ‘Macro’ uncertainties must be dealt with, or at least must begin to be dealt with, with during the Initiation process group. In fact, many of these uncertainties must be identified and management of them started before Initiation even begins. ‘Micro’ uncertainties can only be identified and materialized fully as activities in Planning are occurring.
‘Macro’ uncertainties are likely to be common across all projects of a similar type (i.e., systems development projects, as opposed to construction projects) although not all of the uncertainties will be equally applicable from project to project. Their relevance will be determined by the individual circumstances of each project, the organization undertaking it and the business and regulatory environment in which it participates.
‘Micro’ uncertainties will fall into common categories but may otherwise be quite different from project to project, depending upon many more detailed and individual characteristics of the project, the organizations undertaking it, the staffing of it and the technology employed to implement it.
Nonetheless, the Manage Risk process requires first that relevant uncertainties (risks) are identified and catalogued. A comprehensive and relevant inventory is a prerequisite to performing Manage Risk properly.
A FRAMEWORK FOR DEVELOPING AN INVENTORY
One of the best ways to ensure comprehensiveness is to define a framework applicable to every project and then drive down through its hierarchy to specifics that apply to a specific case.
Here is a lifecycle-driven framework that may be useful. Within each lifecycle process group is a high-level work product that is the intended result. Below that in the hierarchy are subject areas which must be managed properly in order to complete the project successfully. Uncertainties relative to the ability to do that represent risks that must be evaluated and mitigated.
PMI process group: Initiation; General Work Product: Project Definition
- Project Description
- Well-articulated with respect to requirements, goals, expectations, etc.
- Requirements prioritized and any to be omitted or deferred explicitly identified.
- Organization
- Appropriate level of support for project
- Appropriate willingness and ability to participate and collaborate
- Risk appetite and preferences, both general and project-specific, articulated and documented to the degree required to achieve consensus with sponsor and major stakeholders
- Existing processes, procedures and assets identified and those required for the project specified and agreed to
- Proposed project organization—project, matrix, functional, etc. and staffing articulated and agreed to
- Organization experience/expertise/standards with respect to business processes, technology, project methodology identified
- Stakeholder identification and management
- A complete and comprehensive roster of stakeholders with appropriate qualification with respect to interest level, influence and attitude toward the project must be compiled and reviewed with the sponsor
- Identification of communication preferences and requirements for each stakeholder must be documented
- Strategic or competitive position
- Organization’s position in marketplace in which Product will compete articulated and implications on project parameters identified
- Project criticality and urgency to the organization articulated; Potential impact of failure articulated qualitatively and quantitatively
- Regulatory Environment
- Existing or evolving regulations that could have major impact on the functions or criticality of the project are identified
- Project Constraints
- The Scope, Time and Cost constraints should be as well articulated and as definitive as possible
- The degree to which the organization is willing to be flexible should be assessed
- Project Feasibility
- Ex ante feasibility should be assessed and significant concerns addressed
- Project Success Criteria
- These must be defined and agreed to by relevant stakeholders
- Items outside the control of the project team must be acknowledged and agreed to by the relevant parties
- Financial
- Funding status and potential availability issues should be identified
- Technology
- Organization’s technology standards, preferences, experience and expertise and relevant resources should be identified
- External Sourcing/Procurement
- Build/buy preference or standards should be identified and taken into consideration
- Existing procurement support and processes should be identified
- Preferred vendors for sourcing products or services should be identified
- Internal Resources
- An inventory of available resources and their experience and expertise should be compiled. A list of the preferred resources should be compiled, as well.
PMI Process Group: Planning; Work Products: Product Definition and Implementation Management Plans, including detailed plans for each of the knowledge areas
- Detailed Product requirements
- Must include both functional and non-functional requirements
- Should tie back to strategic goals and success criteria and be modulated by stated constraints and preferences
- Should be tied back to stakeholders that identified them
- Should be validated with sponsor, stakeholders
- Solution Architecture and Design, Technology Selection
- Appropriate to meet the requirements of the Product
- Fit with organization experience, expertise and infrastructure
- Staged delivery planned for, if required
- Balance between current and future needs
- Technology
- Appropriateness for intended purpose, Limitation on uncertainties with respect to capabilities or methods of use
- WBS and Work Package Design
- Appropriate decomposition—WPs are focused so that they can be executed by resources with a cohesive set of capabilities
- Careful management of task interdependencies
- Appropriate layout of parallel and sequential linkages with some opportunities to catch up by accelerating execution of WPs or executing them in parallel (‘Crashing’ or ‘Fast Tracking’, respectively, in PMI terms)
- Resource leveling applied
- Task Estimation
- Accuracy, accounts for learning curve as experience builds
- Overall schedule
- Flexible design to allow for responses to variances
- Comprehensive inclusion of non-construction tasks, such as user acceptance testing
- Staffing
- Knowledge of resource experience and expertise
- Assignments match resources with appropriate WPs
- Allowance for competing tasks (potentially, including non-project tasks)
- QA Processes
- Either separate WPs or integrated into construction WPs
- Allowance for rework when necessary
- Procurement
- Lead times are adequate to perform procurement properly
- Clarity and comprehensiveness of requirements for what will be purchased
- Use of appropriate contract type or purchase basis
- HR and Team Management
- Integration of internal and contracted team members
- Consistency with HR management of other or previous projects
- Coordination of collaboration, communications and meetings
PMI Process Groups: Execution, Monitoring & Control, Work Products: Solution Construction, Risk Management, QC/QA, Progress reporting management
- Work Package-level success
- On time
- On budget
- Complete functionality
- Meets quality standards
- QC and QA processes are executed as planned and results documented
- Re-work accomplished within time and cost contingency margins
- Identified risks (uncertainties) monitored at the project and WP levels
- Risk responses executed as and when required
- Project remains within time and cost contingency margins
- Appropriate methods of progress measurement employed (Earned Value method preferred) to monitor project and regular reporting provided as agreed
PMI Process Group: Completion, Work Products: Accepted Product and Updated Project Archive
- Product acceptance by sponsor, stakeholders
- Success criteria met
- All required project documentation, including lessons learned and team member reviews, are filed in the project archive
AN APPROACH TO ARTICULATING UNCERTAINTIES
So, given the above (admittedly lengthy) list, what should you do with it?
The list identifies a great number of widely divergent things that have to be done properly or that have to go as expected in order to bring a project to a successful conclusion. They range from articulating and getting relevant parties to agree on what constitutes a successful conclusion to ensuring that the architecture of the product to be built is appropriate. How you define an uncertainty and what you prepare to monitor in order to manage it can contribute significantly to your success.
For example, completing a Work Package over budget may seem like a risk. It has a probability of occurrence and an impact, measurable in time and costs. However, it is a result and, while it is something that you can monitor, it is not something that you can manage. The things that you can manage at the Work Package level include such factors as the quantity and quality of resources assigned, the validity of the work and time estimates on which the schedule was based, appropriateness of the tools that that will be employed, management of staff productivity, resolution of bottlenecks and so on.
The way to make use of the list, then, is to ask the question “What if this success criterion is not met?” for each subject on the list. In some cases the answer will be “not much,” in which case the uncertainty relating to the subject can be left off the list for the project at hand. Otherwise, the subject should be added to the Risk Register and go through the process of assessment, response planning and monitoring and management throughout the project.
For example: What if the organization that has indicated by word and deed that it is risk-averse wants to take on a risky (uncertain) project? This is clearly a risk worthy of assessment and response. Highlighting and resolving the contradiction before going very far through the Plan process group can avert major disagreements and project plan modifications during execution. Or: what if the programmers that will be assigned to the development do not have experience with the software to be employed? This is also clearly a risk that should be addressed. There may be multiple options to mitigating either the risk or the impact but none of them will be evaluated if the uncertainty is not identified first.
WHAT’S NEXT?
The final installment of this series will present a repository strategy for maintaining an archive of uncertainties that can be used as a starting point for future projects.