Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: risk

How do I estimate based on risk?

Risk Management - Image from bigthink

Risk Management – Image from bigthink

I have previously contemplated the challenges of keeping to scope and budget and keeping customers happy. If a customer adds new requirements on to a project, it is an easy discussion to have around additional time and cost, or a reduction in scope elsewhere. Grey areas in scope aside, you can show a definite impact on the project because of an omission that needs to be rectified. Where I see challenges are in trying to prevent slow bleeds.

One approach is to state assumptions that all dependencies will be met and manage exceptions by change requests. From experience I find that is a hard way to manage. How long does it take to do a task? The answer is always depends. You may be doing a task very similar to that you have done elsewhere. However, you cannot assume it will take the same amount of effort or elapsed time. The environment where you are deploying, number of other suppliers involved and in-house expertise of your customer all play significant roles. Experience tells us that we must take into account these factors as risks when we estimate project cost and duration.

My area of expertise is in delivery of IT projects. However, I believe the principle is the same in all fields of work. In an IT context, even in simplest projects you will have a customer taking on the task of solving a business problem through a project. The supplier will be engaged to deliver the project to a scope. Usually interactions are required with subject matter experts in the business, the IT service provider for the customer (could be in-house or another supplier), possibly procurement … to note a few. There are risks that we must associate with each of the players and estimate the project accordingly. While it is difficult to create a good risk profile for a new customer, we should be able to build a reasonable picture for customers we deal with regularly.

Think of a scenario where one of the other suppliers delay delivering a component that is a pre-requisite for your delivery. It may only have been delivered a day or two late. However, you have created an optimum resourcing based on something being delivered on the agreed date. In reality, you cannot re-assign those resources unless you have significant notice of the delay. Even if you know well ahead of time, in many occasions it is impractical to re-allocate those resources to another project, due to the short available window. By the time they are up to speed with the other project, it will be time for them to start working on the original assignment. Effectively the supplier through no fault of their own ends up absorbing the cost.

Sometimes the lost time is less than days, maybe a few hours every week due to lax turnarounds to required information or pre-requisite delivery. However, at the end of a project it does end up being a significant impact. You cannot really go back with a change request every time something is delayed by an hour. This will give a new meaning to death by change request. And you can be guaranteed a breakdown in communication with your customer. How so do we then ensure projects do not suffer this fate?

PRINCE2 Risk Probability Impact Grid

PRINCE2 Risk Probability Impact Grid

The only way around this dilemma is to expect some level of these risks materialising. PRINCE2 suggests using a probability impact grid to evaluate risks. While PRINCE2 is predominantly useful for the end customer to run the project, there is no reason the suppliers cannot use similar techniques to analyse risk. It is worth analysing what your particular scale for impact or probability is to get a good feel for impact. When you are constructing your estimates and plans, have these built in.

The key message here is to initiate a change request only when the risk that you have tolerance for in your plan is exceeded. Many IT projects fail to take this into account and bleed. One can legitimately ask why doing a PERT estimate should not take these risks into account for the pessimistic scenario. The key to remember on that is when you get your technical staff to estimate the pessimistic scenario, they are taking into account pessimism from a technical point of view, whether that be an unknown pattern of software development, familiarising with new API etc. They are not taking into account human or communication risks.

In my observation, construction projects are better at taking risk budget into account than IT ones. This is possibly because a half finished construction project is an obvious reminder of a failed project. Failure of an IT project is usually a less visible eye sore. That has probably made those in IT projects lazier than we should be.

How good are we at lessons learned?

We as human beings have the incomprehensible ability to make the same mistakes over and again. You have to take a glance at history to see the same pattern repeat itself – a nation is enlightened, makes rapid progress, gets intolerant and starts to impose itself, loses its hold and goes back to the pack. Chinese, Persians, Romans, Greeks, Ottomans and Arabs – all had a go. In recent times Great Britain and the United States. It is therefore not surprising that we do the same with projects.

Lessons Learned

One of the PRINCE2 principles is to learn from previous lessons. Good in theory. How well is it done? Not very well in my view. Lessons learned is something that is left to the end of the project in my experience. On any sizeable project, the project team should be implementing lessons learned as they go. Lessons learned is not only for not repeating the mistakes of one project in another, it is also to ensure mistakes of one task in the project is not repeated in another.

The difficulty of recording lessons learned is very similar to that of benefits realisation in a project. By the time people have some ability to look into that, the project is completed, and attention has shifted to the next project, or towards embedding the products of the project into the organisation. Keeping focus to ensure this is captured takes a lot of discipline. Standard practices are also required for capturing lessons and reviewing those at the initiation stage of any projects. Otherwise, the lessons are not worth the paper (or disk space) they are captured on!

What things should you capture as part of lessons learned? The first and foremost thing you must capture is your estimated effort versus actual time spent. Estimation is an inexact science. Projects by nature are risky and whatever methodology you use to estimate, it is a matter of continually refining those. The bare numbers are not sufficient. You must analyse what led to those numbers. You may have estimated high, but because of scope creep you may have come on budget. Was that success or failure?

A second thing I recommend is the identification or risks. Were there issues which were not identified as risks at the outset? If not, what led to those issues? How could they be identified better in future? Where issues were identified as risks at the outset, review the risk responses. Were they appropriate? Were the likelihood, impact and proximity identified correctly? If not, try and analyse how it could be done better.

I would also look to see if the project methodology was tailored to suit the project and the organisation. Many organisations think using a methodology like PRINCE2 will ensure success. Without the appropriate tailoring, methodologies are doomed to failure. It is not the methodology that brings success, it is the people that understand the principles and ask the right questions that make the difference.

These are by no means an exclusive list. In many ways you should look to evaluate each of the six tolerances that the organisation affords a project manager – time, cost, scope, risk, quality and benefits. The three above are the most common causes of repeat mistakes from my experience.

Image Credit: Ryan Renfrew

Understanding the change appetite in organizations

Projects are temporary activities that allow the organization to implement a business change. The word change is the operative word. A Project Manager is responsible for delivering the outputs that will enable the desired business change to take place – within the tolerances afforded to him in the areas of – timeline, cost, scope, quality, risk and benefits. Are all organizations equal in their ability to accept change? How does it impact project management?

Not all changes are equal. Consider a change related to upgrading a software used by an organization, to changes in business process, to slashing staff numbers to fit into a new operating model. These are all changes with various degrees of disruption. Higher the disruption, more attention needs to be paid to the change appetite. The Project Manager will not always be able to work within the change appetite in the organization. It is therefore legitimate to ask whether there is benefit in trying to understand the change appetite.

The reason to focus on the change appetite is to identify and quantify your project risks and having some guidance on what appropriate risk actions are. For small changes you may want to accept the risk and move ahead. For more disruptive changes – in the example of slashing staff numbers – you need to consider not only the actions that the project will need to undertake to achieve the objective, but also disbenefits associated with those – uncertainty, resulting productivity loss, departure of staff you had intended to keep etc.

More disruptive the change, the likelihood it is done less often and more chances of people losing nerve in the midst of the project. You need to ensure higher commitment from management as a result. If the project is about developing a new product to be first in market, ensure you have the right level of buy in internally. It is easy to get derailed as many in the organization may not have the same appetite for not only the change – but also the risk, cost or benefit. As you progress you need to ensure you measure viability using a constant yardstick.

As you undertake the project many in the organization will respond … why do we need this, or we’ve always done it this way and it has worked, why change … and many such questions. Remember there is also an opportunity cost to doing nothing. Ideally vision for the future state comes from the leadership in the organization. You will find top-down communication approaches will not always work as well as management assume. This is where understanding the change appetite can play into your hands. Arm your project team with the vision of what you are delivering. Lines of communication cannot be controlled. If the project team has the same vision, they are able to generate a level of understanding within the organization through their daily interaction with the business at large.

You will need to manage your project executive / sponsor effectively. Sponsors usually come from the business background and are usually less aware of projects and change management. Many are happy to step up with the additional responsibility and are capable of taking the organization on the journey. Equal number if not more are not able to do that. Encourage those to up skill in the role of sponsoring the projects if you think that is necessary. While you want maximum clout from your sponsor, be wary of picking someone who does not have enough time to do justice to the role. Pick the CEO at your peril 🙂

Change = Resistance = Risk. By understanding the risk appetite of the organization you are able to quantify risks and action plans, which gives you a higher chance of success.

Image Credit: Matt Davies (Journal News)

How long does software development really take?

I was reading some stats the other day … 85% of all software development projects fail to come in on budget or on time! That is a staggering and sobering statistic. In what other profession would there be such a low hit rate? How is it that so many bright people get it so wrong so often?

Software development is inherently a more risky proposition than many other projects. The reason a client is after bespoke development is because no such products exist in the market that adequately answers their problem. Some clients are better at expressing their requirements than others. In some cases they simply don’t know what they need. They just know that they need something. Read more of this post

%d bloggers like this: