Progressive elaboration – a key attribute of project risk management

Risk exists as a natural byproduct of the uncertainties that are present in all projects.  The purpose of project risk management is to manage these uncertainties so as to reduce potential project & business impacts of threats and to be better positioned to exploit opportunities.

A novice project team faces the following classic paradox – while the ability to cost effectively manage risk is greatest at the start of a project, the magnitude of certainty about the project is quite limited.  So although an attempt is made to identify all appropriate risks, this lack of certainty will likely result in key risks being missed or red herrings being identified.  Qualitative assessment of these risks is done to prioritize and focus on a small set of risks and quantitative assessment is done to evaluate the cumulative impacts of the target set of risks on the project – both are important processes, but their basis is only a partial understanding of the project’s true uncertainty.  This is why it is important that the project manager or an appropriate risk management facilitator monitors effort expended on these activities to ensure that they are “right sized” relative to the current level of project knowledge.

This dilemma is the main reason for applying a progressive elaboration approach to project risk management.

As new information about a project surfaces and early assumptions are validated or refuted, it is important that the project team repeats risk identification & assessment activities (albeit with less effort being expended as compared to the initial iteration).  The timing for this process should be both scheduled regularly (e.g. at every second project team meeting) and also tied to specific events (e.g. assessment of a change request).  Another method of avoiding obsolescence of risk data is to identify risk triggers as well as underlying assumptions – confirmation or elimination of these prerequisites can provide valuable input into the re-evaluation process.

Just as a project schedule must be maintained through a project’s lifetime to provide a realistic model of activity delivery, a risk register requires the same level of refinement otherwise it will be as ineffective as a blindfolded Tarot card reader!

Time tracking – what’s in it for me?

“It was the best of times, it was the worst of times” – it would be hard to find a more apt quotation to describe the merits and challenges that accompany the roll-out of a time tracking initiative in an organization that has never tracked actuals before.

I provided some tips in a much earlier article to reduce the likelihood of experiencing an open revolt with such an initiative, but didn’t answer the one question that is in the minds of all affected staff: “What’s in it for me?”.  As I’ve previously written in this blog, if you can’t provide a person with a clear understanding of how a proposed change will benefit them, you increase the likelihood of resistance.

In the case of time tracking, this resistance may be subtle – you might get a complete time sheet, but the individual might have filled it out with minimal effort and dumped all of their hours into the most generic bucket possible.  Worse still, if functional managers are not reviewing the hours entered by their staff for completeness and accuracy, there is no way to identify such resistance.  Senior management in turn might use the time actuals for project staging or resource capacity planning purposes – both will be heavily impacted by poor input data.

Given these risks, it’s worth the effort to identify and communicate tangible benefits to the two pivotal roles in the time tracking process – the tracker and the reviewer.

For the tracker, a benefit is that good quality actuals should help to eliminate the complaint “My boss does not know how busy I am or what I am working on”.  Another benefit is that if the time data is used to justify reduction in the number of in-flight activities or to better address the 80/20 operational utilization issue, this should translate into less multitasking and better focus on higher value activities for a resource.

For the reviewers, the benefits of ensuring complete and accurate data for their teams are that they can provide better resource availability estimates for operational and project work (which in turn should reduce the incidence of resource contention issues) and they will also have quantitative evidence to justify the need for either more resources or for more disciplined project prioritization.  As with most services, if a consumer has no idea of capacity, the expectation is that availability is unlimited and they are more likely to submit “stream of consciousness” requests.  Once project requestors and sponsors have a better understanding of capacity limits, the climate is likely to be more favorable for prioritization discussions.

Providing meaningful value propositions is no guarantee that a time tracking initiative will succeed if senior management does not act appropriately based on the captured time data, but that’s a topic for a different article!

 

The project charter – one test of the commitment level of your sponsor!

The classic difference between theory and practice is admirably illustrated by some of the principles reflected in the Guide to the PMBOK when we compare them with the organizational project management reality that we are often faced with.

A good example of this gap relates to the Project Charter.

The PMBOK guide correctly identifies this document as the key trigger that formalizes the existence of a project and that vests a project manager with the authority to apply resources towards the achievement of the project’s vision.  The PMBOK guide further clarifies that while the sponsor is responsible for issuing the charter, they might delegate the actual effort of developing it to the assigned project manager.  The charter achieves almost the same level of importance as a “foundation” document for a religion.

If only it were that straightforward – in many organizations, resources might be busy delivering scope and budget might be expended before a charter document is approved and issued (if it ever is!).  The complaint I heard from one practitioner this week was why should the PMBOK be so far removed from the way projects are managed in “the real world” – in the context of learning about how to manage projects, it seems academic to be memorizing theory.

On the surface, this seems like a valid argument – if the majority of organizations that a typical PM is exposed to are at a very low maturity level, what is the point in going through the frustration of learning best practices that can never be applied.  My take on it is that the PMBOK guide provides a good vision of how project management should be practiced and each organization (and practitioner) could strive to improve their planning and execution capabilities using guidance from it or similar sources of knowledge.  If the extent of our vision is a stone’s throw away, that’s as far as we will progress – once we visualize a goal that is much more challenging, we experience true growth.

This segue brings me back to the point of this article – committed project sponsorship has often been identified as a project critical success factor.  If you cannot get your project sponsor to engage sufficiently to issue or at worst to review and approve a charter during the honeymoon stage of the project life cycle, what luck do you expect to have when escalating a project issue or significant project decision to them?