Risk Management at the Source - Part 2 - Monitoring and Controlling

Initiating and Planning provided you with many opportunities to foresee risks and mitigate them early on. If you have not read the post, make sure you do because in Monitoring and Controlling your life will be much easier if you were able to follow some advice listed there. Initiating and Planning is the best project phase for mitigating risks.

If life was tough and you couldn't address the risks at the beginning of the project, there is still a chance you could do it while monitoring and controlling. The techniques used in the monitoring and controlling phase are also useful for the situation when you take on a project after it had begun and had been initiated by somebody else, possibly less skilled then you. The project might already be in trouble if the risks where not address early on, so your main challenge might be to find time for preventive actions while firefighting the current problems. The obvious advice for this situation (and listed in every Time Management book printed) is to work on a Urgency-Importance framework; that is to handle first Urgent and Important issues, then Important but not necessary Urgent issues. It sounds simple, but it takes a cool head and a bird's eye overview on the project to resist pressure to act on the Urgent issues - which is why Project Management requires some maturity.

That being said, here is the promised list of techniques:

  • Include key risks in Project Progress Report and Steering Committee presentations, including expected action plan, deadline and responsible. This might come to you as a no-brainer, however I have seen many Project Managers not exposing risks because they don't want to "upset" the customer. Others, to the contrary, like to give such a list to the customer in order to lower expectations but fail to provide a solution and action plan with them, which makes the customer and the team shrug while no constructive action is taken. Do this also to make sure client and team take risk management seriously and understand Risk Log is not an academic exercise.
  • Circulate Project Memos with regard to risks if in-between reports. This will ensure risks get all the attention and implication from involved parties.
  • Include contingency for highly probable risks in the estimated costs of the projects. This will mitigate debooking revenue due to risks materialized and fluctuations in the revenue forecast.
  • Monitor actions of non team-members staff involved in Risk Mitigation as you do for your project team. That includes monitoring deadlines for project sponsor, client staff, sales staff risk-related activities. Risks are often related to entities outside your project team. Monitoring these entities will mitigate the risk of stalling in important decisions, and that influential people don't timely use their power to help your project.
  • Depending on your delivery methodology, you can use various documents to mitigate risks. For example, use the Testing Strategy to clearly split roles and responsibility between you and your customer. This will ensure the customer not performing their tasks thus delaying the project.
  • Use the Testing Strategy to define testing system information; release procedure, bug tracking procedure, acceptance criteria for application (e.g. “no critical bug, no more then 4 medium bugs and plan of action for all bugs”), definition of bug and new feature request in the testing strategy. Pre-approve the document (gain approval before testing begins). This will mitigate the risks that testing is delayed because of misunderstandings between the development and testing team, unrealistic expectation that the application performs perfectly, discussions over bugs vs new functionalities, unrealistic expectancies that new features will be considered bugs. And in the end mitigate an important risk of all projects - scope creep.
  • Use the User Acceptance Testing strategy to avoid the common pitfall of transforming UAT in an analysis workshop gathering new functionalities requests. You can do that by planning and pre-approving a set of goals, scope and assumptions in the UAT Strategy.
  • If you need to perform data migration, create and use the Data Migration Strategy document to mitigate specific risks related to data migration and pre-approve the document. Include data migration sources in the conversion strategy; this will make it difficult for the customer to communicate later there are other source systems;
  • Include data correction and coherence assumptions in the conversion strategy; this will ensure all parties are committed to giving clean data for conversion;
  • Include conversion procedure, including manual and semi-automatic procedure in the conversion strategy; this will mitigate the risk of unrealistic expectations that all data will be imported automatically;
  • Include migrated data tests and acceptance criteria in the conversion strategy (e.g. quantitative through counting in the database; qualitative through samples, visual inspection, formulas). This will mitigate unrealistic expectations that all migrated data can be tested for correctness.
  • Use the Training Strategy to propose a several layers of training that include readiness assessment, re-training sessions and workshops with end-users after go-live. For most projects, one initial training is not enough and end-users end up rejecting the system.
  • Perform initial orientation for own and customer team and have the materials ready to perform orientation whenever a new member arrives. This will mitigate Project Team not knowing where the project is heading, new members disrupting the direction of the project, or staff (including customer's) not understanding their role in the project.
  • Use Post-production Strategy to assign level 0 and level 1 support to key users, with clear responsibilities for the customer. This will avoid trivial issues or operating errors to get to the implementation team, saving your team's time for the real important issues;
  • Include a bug tracking system working procedure in the post-production strategy that states who should check for duplicates and trivial issues before they are assigned to the implementation team; also to avoid bugs arriving on different channels to the implementation team.
Happy Risk Management! and soon to come is part 3 - Closing.


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.