Risk Management at the Source - Part 1: Initiating and Planning

Have you ever came across one of those Risk Management courses that endlessly talk about probabilities, impact, mitigation strategies and the process of assessing risks and putting them in a risk log? Although not a brainer, this approach on Risk Management transforms it in a academic exercise, which explains why in many projects RM is performed only when an audit is around the corner and you need some paperwork to prove you're doing an outstanding Project Management job.

When in fact, even without this paperwork, you are doing an outstanding Project Management job. Because most of our Project Management activities are about managing risks, maybe not as explicitly as if they were listed in a Risk Log. After acquiring some Project Management experience, most of us PMs learn some risks are more likely to happen then other, are able to foresee future problems from current symptoms, and conduct our PM activities mostly around mitigating and minimizing those risks.

So why not recognize this phenomena and create a new approach on Risk Management? A Risk Management that is in the center of Project Management activities, that is real, practical and common sense. Just like Quality at the Source is about embedding Quality at every step of the production, Risk Management is embedded in all project management activities. With this new approach, we want to see a Risk Management perspective on every activity a Project Manager does rather then having an isolated process called Risk Management. Just as in the project lifecycle, we propose:

  1. an Initiating and Planning phase with a Risk Management perspective
  2. a Monitoring and Controlling phase with a Risk Management perspective
  3. a Closing risks phase with a Risk Management perspective
(simplification as compared to the PMI project lifecycle is intentional).

I have listed below some techniques for embedding Risk Management in the Initiating and Planning activities. More posts will follow for Monitoring and Controlling and Closing. Again we talk IT (but most of our projects today touch IT so it became a familiar domain for most of us):

  • Delivery Method: If you include in your method tasks such as early prototyping, iterations and workshops with the client, you are already planning for mitigating risks such as heavy re-work in the late phases of the project or users not accepting your solution;
  • Constraints and Assumptions in the offer/contract/Project Management Plan.  Constraints and assumptions should refer to limits of what you can do and under which circumstances. These contain the knowledge of the past, of things you know can go wrong or misunderstandings that explode the budget. Have this list updated at the end of each project and don't name it "Lessons learnt" or in any other fancy terms; just a bullet list with assumptions and constraints to be added in the next proposal. List them on components, so you can easily extract what applies on the next project (e.g. hardware, communication, custom development, application implementation, data migration, Business Intelligence, training);
  • Kick-off presentation. Include in your kick-off presentation to the client a summary of the scope of work, including out-of-scope. This will address the risk of scope creep as the audience will be told early on what is and what is not in the scope of work.
  • Communication: Instead of presenting your list of risks to the client, throw a "Risk Assessment Workshop" together with your client. If you hear their concerns, it would be easier for your concerns to be heard.
  • Project Management Method: Include an Acceptance Methodology in the offer/contract/Project Management Plan that contains chapters for each deliverable type (e.g. different methodology for documents, application, data migration, training, hardware, networking services, etc). This of course will save you time and energy in the future if people have different expectancies regarding what acceptance is;
  • Include default acceptance that will allow you to handle non-responsive clients and move the project forward;
  • Plan for acceptance criteria that are not absolute in the case of software application. Software will never be bug-free and often it is more valuable to go-live with known issues rather then wait for the application to be perfect. You can phrase it like this: "The application will be considered accepted and ready for go-live if, following the UAT, there are no Severity 1 bugs, 4 or less Severity 2 bugs and there is an agreed plan, with deadlines, for solving all open bugs. ". Then list what Severity 1, 2 and 3 means. With this simple phrase you've just mitigated delays and negative cashflow risks;
  • Training and communication. Perform orientation and create an orientation communication package for the team, own and customer. This will address the Project Team not knowing where the project is heading or customer staff not understanding their role in the project;
  • Scope Management. Include a Change Control method in the offer/contract/Project Management Plan. We've discussed here that Change Control is not for rejecting change; still the absence of the mechanism invites to scope creep;
  • Project Governance. Establish the Project Governance structure, with layers and rules for reporting or escalating, explaining how risks will be brought up and escalated. This will address the risk of slow decision making, the risk of lack of resources and the risk of hurting the feelings of the people being escalated if they know from the beginning this mechanism with clear rules is in place (never underestimate the cost of hurt feelings :) );
  • Communication again, Staff Management. Explain to everyone in the team that you expect them to communicate any perceived risks and issues, including "Project Management risks and issues" such as scope creep. This ensures your team feels empowered to communicate and to give you hints you might miss;
  • Staff Management, Work Management. Create a staff plan for resources required from your client and hand it to them before the project starts. Include it in the offer/contract/Project Management Plan. This will address unrealistic expectations and lack of resources from the customer.
 I would be happy to hear from you whether Risk Management sounds less abstract now and more like common sense. Posts on Monitoring and Controlling and Closing will follow.