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.

No comments: