« We will remember them | Main | Surviving In The Freelance Economy »
Monday
Nov182013

Identifying Risks via Assumptions

It was some years ago, early in my project management career, and I was in the early stages leading a particularly challenging client engagement for a consulting firm.

I went to the partner, my boss, and told him we simply couldn't deliver the project the client had asked us to deliver due to information we had not previously been aware of. The project was to implement a supposedly already built system - but it turned out it was nowhere near ready, and was probably never going to be due to a fundamental flaw in how it had been designed.

While he understood why I was saying this he refused my request to pull out of the engagement. His view was that it was simply too late to go to the customer with such a high level analysis. Initially I was very frustrated by this response - why insist on continuing with a project that was going to fail? But my boss took me beyond that.

He challenged me, "if you make enough assumptions, do you think we would deliver the project for the client?"

I said I believed we could, but I that I didn't think the assumptions we would need to make were viable. Some, if not many, of them will fail - or, possibly already had (e.g. that the system was ready).

He said, "that is fine, for now, let's work out what the assumptions are and take them to the client. The client will then easily agree with why the project either has to be abandoned, or dramatically re-shaped".

So, we stood around a whiteboard and listed all of the assumptions we would have to make for the project to have a chance of success. It was a long list!

We then went through each and rated them as either having already failed (the assumption was no longer true, if it ever was) and for those that were still true (the assumption was still valid) work out the likelihood that each would continue to be valid for long enough to deliver the project, and what we could do to increase the likelihood of that being the case.

My boss then said to me, "there you are, there's your risk management plan".

Initially I didn't understand, but he then clarified it for me - each assumption was simply a risk stated another way.

It also happened to be his agenda for discussing with the client why the project either had to be abandoned or dramatically re-shaped.

We were so well prepared for that conversation that the client agreed fully with us, and agreed to re-shape the project based on de-scoping those parts of the system that were never going to be ready, adding some completion activity to the project to finalise those parts of the system that were close to ready, and re-doing the implementation plan to only cover those parts that were already ready or were close. We had a new scope, a new timeline and a new budget - all of which were achievable.

The client was happy because finally they had an achievable path forward, after many years (yes, years) of trying to implement this system themselves.

We were also happy because we now had a project we could deliver - which we did. On time, on budget and to scope.

By way of example, a classic project assumption is to "assume that the people required to deliver the project are available for their scheduled project tasks". Re-stating that as a risk turns it into "there is a risk that project resources are not available to perform their scheduled project tasks". The classic mitigation for such a risk is to communicate with sufficient notice when people will need to perform their scheduled project tasks so they can block out their diaries accordingly and schedule their other work for other times. Another mitigation is to have the project fund backfill staff to release the project team members to the project. Often you do both.

References (3)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>