Promote a Risk Management Culture

Project management is a game of risk management. After all, project managers constitute overhead for most every project; if there were no risk involved, there would be no need for project mangers. All would go well, everyone would work completely in harmony, and we could “pack it in” and go home! Fortunately for our profession, and unfortunately for the business world, this is not reality. Risk is a major part of what we have to manage, and risk management needs to permeate the approach we take in handling our projects.

Holding a discussion with the project team and stakeholders to surface potential risks and their mitigation plans is an excellent start. But what to do about those team members and stakeholders that “selectively forget” the risks involved? On Mindavation projects, we use the tool to tie each risk we derive not only to a task in the project schedule, but also to a requirement and module we have to produce. In this fashion we can quickly ascertain where the riskiest modules and/or requirements of our project lie. This can open up and reinforce the need to dialog with our stakeholders, bolster their involvement in addressing risks, as well as properly prioritize their requirements from both a potential benefit and possible impact approach.

Lastly, it can keep both the stakeholders and the project team mindful of items to examine when performing testing – both interim quality assurance testing and final user testing. Assessing a module or series of modules against a given set of business objectives (established as performance criteria) might only be a subset of the testing required. Assessing a business function against a list of potential risks might also be prudent. Our tool’s tie between the risks involved, the technical module and the requirement itself reinforces this need.

Project Team Focus

The tool also serves as a great consolidated checklist for managing the project team and helping ensure they are focused on the quality of the product(s) they produce. The tool can be built when only the requirements are known – and reinforces the need for a test plan to be started early in the project. This tool provides a means of recording test items in a concise manner, ensuring that all modules and stakeholder requirements have a test against them. In addition, the spreadsheet tool provides a means to ensure that modules or other project components do not get introduced to the project if they aren’t directly related to a project requirement. This provides a defense against a common issue that can surface with technical projects - the introduction of technical elements that don’t directly address stakeholder requirements.

Noting the results of the testing on the spreadsheet also gives the project manager a quick “sanity check” as to where the greatest number of quality issues are surfacing – again from a business, rather than a technical standpoint. Most good testing plans will be designed around technical components and naturally provide a technical module focus for analyzing results. This spreadsheet will alert the project manager to any trend that exists from a business standpoint, indicating potential complexity issues, or a lack of appropriate training/focus of the project team or their end-user counterparts.

continue>>

<<back