« How to Meet Expectations
Facts - Project Failure »

The World, but surely at least the Project Lifecycle, revolve around Risk Management!

May 31, 2007 | Author: PM Hut | Filed under: Project Lifecycle Phases, Risk Management

The World, but surely at least the Project Lifecycle, revolve around Risk Management!
By Adrian Abramovici

So, since we all agree (?) beyond reasonable doubt (?) that Risk Management, or the finer granularity of Threat Mitigation and Opportunity Exploitation are what Business is all about, let me venture another thought: the Project Lifecycle should be based on Risk Management principles.

Even the most inveterate “seat of the pants” Project Managers do by now grudgingly accept the value in some form of progress reviews, or gates, for a project – just so that everyone is convinced that the project actually is at the stage where it claims to be on the schedule. But these same “seat of the pants drivers” will usually add a few caveats: no cost impact (i.e. “I’ll give no support – pay me” ); no new deliverables (i.e. “what, you want me to actually create some deliverables that PROVE my claims?”); no schedule impact (i.e. “let’s do it over lunch”); and the standard “What do you mean independent reviewers? These guys have their own agendas” (i.e. “they might disagree with mine!”).

Let us review WHY do we have these “gates”, or “reviews”?

In most engineering projects, a “gate” is called for after a meaningful, important piece of work has been completed. At that stage, an internal, or better yet, independent review of the outputs of this phase is to be conducted to provide an appraisal of the progress, quantitative and qualitative that the project has made in meeting its requirements. Most “gates” are also used to decide whether, based on the progress and the compliance to the applicable requirements, the project can proceed into the next phase.

Major gates (Milestone Reviews) are usually set at significant decision points in the Project, and usually involve (or even require approval of) the Stakeholder or Customer, and might have payment release pending on the outcome. On many projects, minor gates are spread throughout the project (peer reviews, code reviews, test readiness reviews, etc.), and are being used to ensure the quality of the work and the readiness for the next task.

Many project managers take the short-sighted view that “gates” and reviews are wasteful and useless exercises and therefore should be minimized (guess I’ve tipped my hand here, didn’t I?). Well, they can be, but only if that is what you make them to be. If gates are treated properly, with good review and feedback from knowledgeable outsiders, and with the proper focus, then they can be of immense value. See Chapter 12 for more on that… sort of.

Getting back to our gates – we have one to ensure the project has reached the point on its schedule it claims to be at, while remaining compliant to its original requirements. The gate then becomes a review of the veracity of that claim – (1) quantitative progress, (2) compliance to requirements, and (3) qualitative.

In a perfect world, we then KNOW what should have been achieved leading up to that gate, and so we review (1) whether the stuff has been done, (2) whether the quality of the work products presented to support the first two claims is adequate and inspiring confidence, and (3) whether the results show the emerging widget still meets the requirements to the level expected for the phase – also called “compliance”,. If we are from a smart project organization, we add one additional question: (4) Does the emerging widget still FIT within the original allocated budget and schedule?
Still in a perfect world, if the answer to the first 4 questions is YES, we declare victory and move on. If the answer is NO, we redo (or finally do) whatever needs doing, knock on the gate, and try again, ‘till we pass.

Of course, reality is just slightly different – there are schedule pressures, the items “failed” might be … not so major, the Customer and Stakeholders push to “keep going” and catch up with the missing stuff later… And in most cases, that is what we do – we chug along, and either recover, or not, and hit the next milestone, where the accumulated problems are just too much to overlook, and we get the accusing glare of the boss with the standard “you always have time to do it again, but never to do right!” ….

So what was missing out of this picture?

Risk Management of the “incomplete pass”, integrated into the overall Project Risk Management approach, that’s what! The fifth question that must be asked therefore is: (5) What is the Risk status of the project?

Say we “pass” the first gate with some issues – those issues are Risks! They must be mitigated in an organized fashion to allow the work that was to be done after the gate to be performed with confidence. In other words, a Risk Response must be drawn up (even if it only means completing some tasks, or documents, or tests, or fixing them up to pass the quality requirements). Then these tasks must be put on the schedule, staffed, costed. Then, and only then, can we go back and attempt (again) to answer the infamous FOURTH question: (4) Does the emerging widget still FIT within the original allocated budget and schedule? All previous answers are null and void!

Now, if we have a complex system, made up of multiple subsystems, we usually tend to review the subsystems separately, and then the system status. Imagine if and each of the subsystems “pass” their respective gates with “minor issues”, deemed to be acceptable for the respective subsystems. However, shouldn’t we be looking at how all those “minor” issues stack up at the system level (i.e. Project level) and see if the total is still “minor”?

Take the example of a hardware subsystem in which a certain board design is late, but in the overall scheme of things, the board is but a small part of the overall thing, so it is deemed to be acceptable to postpone the design and build to a later stage, after some major issues elsewhere (or maybe on another project pulling priority) are addressed.

But what if the piece of software designed to run on that board is a new, risky bit, and needs extensive testing, which means they absolutely must have their board so as to run their tests as early as possible? Obviously, the drivers for the two teams are different, and the project manager must select the best approach to meeting the overall project priorities.

The overall gating process for a project must therefore always include a review of the Risk the totality of the “incomplete passes” at all the levels (below the system one) is adding to the overall project risk. This risk must then be compared to the acceptable Project Risk Threshold (remember, that thing that just might get your project cancelled?), and the various risks responses recommended at the lower levels must be reviewed and optimized of the best interest of the Project as a whole.

Let us look at the example of a Critical Design Review (CDR) for a theoretical system. By the CDR, all requirements should have been complete (waaay back when…), preliminary design should be done (also way back..) and the detailed design should be ready to be handed over to manufacturing (for the hardheads) or detailed coding (for the softheads out there). Other things must be in various stages of readiness, such as having your test procedures and test equipment defined and built (or not), as defined in the Project Plan and on the project schedule.

Once the subsystem gates are completed, an overall System Risk Chart can be updated to display the results of the subsystem risks identified, and thus visually display the overall accumulated risk on the project.
What would you decide in this highly hypothetical example?

If we review closely the five main questions a project gate should be based upon, we should by now see the risk assessment value of each:

(1)Has the stuff (on the schedule) been done?
In other words, what is the risk that the work required up to this point is incomplete and must be re-done, which would increase the unplanned workload in the next phase?

(2)Is the quality of the work products presented to support the first two claims adequate and inspiring confidence?
Is there a significant risk of errors in the work just accomplished, and how will that influence the project compliance to requirements, and will it require unplanned and costly re-work in the next phase?

(3)Do the results show the emerging widget still meets the requirements?
Is the evolving product compliant to the requirements the Customer or Sponsor is paying for? If not, what is the risk that the project will be forced to dramatically change course (at an obvious cost and schedule hit) in the next phase to recover compliance, vs. the chance the Customer or Sponsor will reconsider and accept the capabilities we offer?

(4)What is the Risk status of the project?
Not much justification required here, we are talking Risk. Just remember that we are talking about the sum total risk existing on the project before we hit the gate, plus anything that the gating exercise uncovered for us and added to the pot.

(5)Does the emerging widget still FIT within the original allocated budget and schedule?
Risk = Cost and Schedule. If the emerging cost and schedule of the project, due to developments on the project and factoring all the risk mitigation activities (and contingencies, if some risks are “beyond mitigation”) is out of the ballpark, well, this is the time to find out!

The Project Gate, regardless whether minor or major, is therefore all about Risk, and it must be incorporated into the overall Project Risk Management process.

Adrian Abramovici is, after more than 25 years of aerospace project management, an executive in the rail transportation industry based in Toronto, Canada. He is writing about his experiences and views on Project Management, Risk Management and the day-to-day frustrations and successes of leadership at http://themasochisticpm.spaces.live.com

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Thursday, May 31st, 2007 and is filed under Project Lifecycle Phases, Risk Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories