How to make Risk & Issue Management Work? PART 2

Posted by Kevin Brady on Tue 5th December 2006 at 01:03 PM, Filed in Project Management,  Risk & Issue Management

How do you introduce risk & issue management into your project?

• Stage 1 Set-up a Project Organisation

- Designate a Project Sponsor

The first thing to do is designate someone as your project sponsor who will ultimately be responsible for the success or failure of the project, and as such will have authority over all the participants involved in the project, whether they are IT or business related professionals.

- Set-up a Project Board

This should consist of the sponsor “God”, a senior user and possibly a representative from a major vendor. This board will have responsibility for project steer, and is the ultimate point at which difficult risks and issues can be escalated for specific “top down” (management driven decisions) resolution and mitigation.

- Set-up regular project team meeting

The main purpose of team meetings should be to track progress against plan, identify new tasks, and finally act as focal point for risk and issue identification, assessment and resolution. In my view team meetings should occur for no other reason.

• Stage 2 Design & distribute risk /issue logs

Please click the following link - For a FREE copy of Clarety’s own ACCESS based Risk & Issue log.. Alternatively, please click the following link – For a FREE copy of Clarety’s WORD version of our Risk & Issue log. In order to get a clearer understanding of what a completed risk and issue log for a real project should look like I strongly suggest the downloading of the EXCEL version which contains real (but sanitised for confidentiality reasons) project risks and issues, together with associated resolution and mitigation progress tracking.

Once the appropriate log has been designed and branded you must place this on your computer network in a shared area where all participants in the project can gain access.

• Stage 3 First Cut Risk /Issue Project Profile

Build your first Bottom-up Project Plan

- Get your project team together in a room with a projector / MS Project & three white boards

Board 1 – Headed Risks & Issues
Board 2 – Headed Prerequisite Constraints
Board 3 – Headed Assumptions

- Define meeting roles

The Project Manager is normally the person who “drives” Microsoft Project.

Assign roles for Risk & Issue logging to one member of your team and the logging of assumptions to another.

- Select which Project Stage to be planned (Blueprint, Build, Test), which is normally the one, you and your team is currently standing in. If the project has just been initiated then it is most likely be the Blueprint Stage (requirements gathering).

- Detail your first “top down” (manager driven estimate) product work breakdown structure. Make sure your project team agrees with this list. It might look something like:-

o Use Case Model
o Architectural Design
o Database Design (schema)
o Technical Design Specifications
o Test Strategy (acceptance criteria and testing approach)
o Deployment Plan
o System Wireframe
o Test Scripting

- Get the team to check that no products are missing and that the work breakdown order looks correct?

- Assign Product Owners to the delivery of each product. This person is responsible for the overall delivery of that designated product irrelevant of the numbers of staff engaged on the products production. The assigned product owner has delegated authority to manage the resource assigned to that products production.

- Start the iterative planning and risk /issue identification process detailed below :-

o Phase 1 Select the product to be planned /estimated.

o Phase 2 Iteratively estimate “bottom-up” (project team driven) the task breakdown structure required to deliver each product on a task-by-task basis, keeping an eye on the dependencies and the resource available so that resource over allocations do not occur.

If the product owner and or allocated build team cannot estimate the task duration and effort required, then one of the following needs to happen :-

• The task needs to be broken down to a lower level of detail
• There is an assumption which needs to be logged and bottomed
• A specific risk /issue needs to be specified.

When a risk /issue has been logged on the white board, the whole project team should be involved in a discussion on how to resolve /mitigate each identified risk & issue. The identified mitigation /resolution steps should then be recorded against each identified risk /issue.

Then on a risk-by-risk, issue-by-issue basis, a risk /issue owner needs to be allocated with the relevant domain knowledge, skill /experience and authority necessary to resolve /mitigate the allocated risk /issue.

Ownership is key to the successful working of this whole process, and it must be stated that all risks /issues will be assessed on a weekly basis in terms of progress towards resolution & mitigation and the associated performance /capabilities of the allocated risk /issue owner. For example, it would be ridicules to allocate a resource shortage issue to a newbie programmer.

It is important to explain to risk /issue owners that when they have diligently exhausted all reasonable and feasible resolution /mitigation possibilities these risk /issues are likely to be escalated up the project organisation if it is judged by the project team that more might be achieve in doing so.

o Phase 3 Meeting Closeout

Enter all the risks /issues into the EXCEL /ACCESS based log placed earlier on the computer network and instruct risk /issue owners that they are to update the progress fields for each risk /issue directly themselves detailing with dates and times a full diarised and trackable summary of the efforts undertaken and their respective results.

In order to encourage owners to use the log, I explain that no risk /issues will be escalated to senior management (including myself) for resolution and perhaps new ownership unless a full description of their efforts and achievements is detailed on the log. How else can I explain the reasons for escalation to the sponsor and the project board without this detailed information?

Finally, mention to the project team that when anyone realises they are going to slip on a weekly project plan target they are to enter directly into the issue log whatever is causing the delay. By default they are to take ownership of the issue and where possible seek resolution so it does not cause slippage again in the future. The recorded issue is then an important reference point should the issue come un-stuck and occur again in the future.

• Stage 3 Weekly Risk /Issue Meetings

Call a weekly team project meeting, which should not last longer than an hour. One of the regular agenda items should be risk /issue monitoring and new risk /issue identification, especially with respect to any previous week’s project plan slippages.

As mentioned earlier this is the point at which decisions are made concerning changes to risk /issue ownership and the Project Manager decides on which risks, and issues will be escalated up to the project board for potential resolution. I normally limit the numbers of risks /issues to be escalated to the project board to a maximum of 10 (so the agenda is not crowded out with risk /issue related matters).

This means that all logged risks /issues have to be prioritised so that escalation decisions can be made quickly and easily. Please note that the free risk logging tools offered by Clarety all include a field so that a priority rating can be set.
Over the years I have implemented the above risk and issue management process on all my projects /programmes of work. The effect on myself and my project /programme team/s has been liberating.

When implemented shouting, screaming, spin management (please see post) , development of blame cultures and dangerous conspiracies of optimism, all cease to exist. In fact, I have always found the running of successful or even failing IT projects /programmes of work actually FUN when I have been able to introduce fit for purpose risk /issue management.

Successful risk & issue management totally depends on individual responsibility, accountability, and ownership!

Please click PART 1 to see see first post in series

This entry has been viewed 4789 times.

READER COMMENTS:

No comments yet.