Tag Archives: project management

The Risks of Risk Management

What could be a more effective risk management practice than wearing a seat belt when driving? Surely that sort of improvement benefits everyone? Actually, economists have shown that it’s not that simple and there are lessons for project managers from this lesson too.

If you engage in risk management, as all project managers do, then be aware of the work of the Chicago economist Sam Peltzman.

What Peltzman identified is that behavior can change substantially in response to risk management policies. For example in the case of seat belts, people tend to drive faster and have more collisions when they use seat belts because of the sense of security it gives them. This is not to say that seat belts are ineffective, it seems that traffic safety overall (especially in terms of road deaths) has improved as a result of them, but not as much as you would have expected, because of this behavioral offset.

And more omniously, though drivers are safer from seat belts, cyclists and pedestrians are more at risk with seat belts because drivers tend to drive faster and those outside the car don’t have any offsetting protection.

Similar studies have shown the same phenomena in NASCAR racing, when safety improves drivers then notch up the risks they are willing to take, offsetting some of the benefit.

photo credit: Roger Barker

So the question for the project manager is are your risk management policies changing behavior? This is not to say you shouldn’t bother with risk management, just as with seat belts the overall benefit is likely to be positive, but pay attention to how behavior is changing as a result of the changes you implement. Are people less cautious knowing there is a more robust monitoring process in place for their projects? Are team members less focused on escalating problems knowing that someone else is watching out for them?

The lessons from other areas such these unintended consequences may be more important than you may initially suspect.

The Winner’s Curse And How To Solve It

The winner’s curse comes out of economic theory, but is very relevant to any project manager outsourcing work to vendors.

Essentially if you are bidding out work where:

  1. The costs are uncertain
  2. You are going to pick the lowest bidder

Then there’s a good chance the vendor you pick won’t make any money out of the contract. This is because if the cost of the work is uncertain, all vendors are essentially guessing at the cost, and that’s fine. The problem is that in picking the cheapest vendor you are choosing the one who’s guessed lowest. However, based on the wisdom of crowds the most likely actual cost of the work is the average of all the bids you’ve received, but you’re not paying the average, you’re paying the lowest and the problem there is that the vendor is likely to lose money (the difference between the average of all bids and their bid),

Now, on the face of it that might sound like a good thing, but in practice, if you look at the delays that results on the Wembley Stadium project and Scottish Parliament project look can see that having a vendor who’s not making money working for you can cause problems for the overall project. It’s important to note that this outcome is a result of the structure of the bidding process, and is not because anyone is necessarily trying to rig the bidding.

So, how can this be solved, here are a few ideas (and thanks to the audience at a presentation I gave in Vancouver last year for helping out with these)

1. Declare in advance you will pick the second lowest bidder. This removes the incentive to come as the lowest and win the bid.

2. Ask for a detailed proposal, not just a price. Read the detailed proposals first, pick the best, then look at the price and see if your budget can cover it. If not, either move to the next best proposal, or ask for more funding.

5 Things Project Managers Can Learn From Netflix

Netflix, the US movie subscription service posted this deck on Slideshare, which describes its creative approach to culture, people, process and incentives.

1. Inspire with context setting, rather than managing details

“If you want to build a ship, don’t drum up the people to gather the wood, divide the work and give orders. Instead, teach them to yearn for the endless sea.”

Antoine De St-Exupery

2. Culture is not rules, but behaviors

Enron had an impressive list of values, but evidently didn’t practice them. Culture is not about what behavior gets talked about, but gets rewarded.

3. The best can be 2-10x as productive as the rest

In processes, the best people can be 2x as productive, in creative roles, the best can be 10x as good as the average person. Work hard to recruit and keep the best people on your projects, because they are disproportionately effective contributors.

4. Hard work doesn’t matter

It’s about results, working long hours isn’t relevant as long as results are achieved.

5. Too much process is counter-productive, encourage freedom.

Process will tend to frustrate high performers and drive them out. Maintaining process will often take more time/effort in creative industries than the cost of fixing a mistake. The goal therefore is rapid recovery, not perfect process. For example, spending under a fixed budget each quarter (high degree of freedom) is a better process than fixed approval for every $5k of expenditure (high degree of process).

Netflix also has no vacation policy, employees chose how to manage their vacation in a way that sense for them as long as they get their goals accomplished.

It’s an interesting model, they admit it’s not suited for nuclear power plants or open heart surgery where a checklist might be a better approach, but for a creative project, Netflix offers some interesting ideas to consider.

Fixing Mistakes Early

Nice chart based on Barry Boehm’s book on Software Economics, shows us the value of fixing problems early in projects, the costs of fixing problems at least doubles at each stage of the process, and become even larger when the results are in operation. The data is based on software projects. This is intuitive, but it’s worth remembering just how much the costs can rise.

The Best Or The Cheapest

Michael Porter describes strategies that successful businesses should pursue. Cost leadership is one example – being the cheapest. Differentiation is another -building something that is sufficiently different, and hard to copy, that people will pay for more it.

Like most solid reasoning, Porter’s approach sounds fairly obvious – implementation is the challenge. With that in mind two recent posts in HBR and TechCrunch highlight what these approaches look like.

Differentiation

  • 1111 Lincoln Road – is a parking garage with such striking architecture that people want to get married there.
  • The Henry Ford Hospital – is a hospital so well laid out that it feels like a hotel.

Cost Leadership

Will your next project driving to one of these outcomes? It’s easy to end up with average cost and limited differentiation, it’s much harder to be extreme on one or the other, but extremities are where the real value lies.

1111 Lincoln Road Parking Garage, Joe Vare via Flickr

Henry Ford Hospital via Flickr

Henry Ford Hospital via Flickr

The Raspberry Pi, A $25 PC

Sharing Bad News On Project Success

A study in the Journal of Applied Psychology showed much lower willingness to share negative information on a project as it got closer to completion. The study was done on undergraduate students with reference to a fictional project. If the project was only 10% complete then at least 6 out of 10 people would share negative information on the project. However at 90% completion fewer than 2 out of 10 people were willing to share bad news on the project.

Implications

  1. Supports the idea that many people are not comfortable sharing bad news.
  2. If people are going to share bad news, they will be more likely to do it earlier in a project, than when it’s closer to completion.

Actions You Can Take In Light Of This

  • Do everything you can to encourage sharing of all information, not just the positive. This may take more time and prompting, but it will improve project success.
  • Knowing that as projects progress, people will be reluctant to share bad news, probe on potential problems and risks early in the life of the project, and then set up ways to monitor them.

Project Management at the BBC

Continuing the theme of UK based projects such as Wembley and Scottish Parliament, the BBC is a state funded provider of television and radio in the UK. The UK’s National Audit Office reviewed 3 recent construction projects by the BBC, 2 of which exceed cost and budget and 1 came in below budget the full report is here.

The key findings are as follows:

  • The projects did not identify benefits clearly from the outset, making it hard to assess success objectively
  • The importance of financial contingencies – the reason the one project (Salford Quays) came under budget was because it had financial contingencies at just over 10% of the initial budget. The projects which went over budget had much smaller contingencies.
  • Change management, all projects had material changes during their lifetime, an average of 41 per project, which generally lead increased costs and in some cases could have been avoided through more thorough planning efforts.
  • There is a need to better assess skills required to execute the project relative to the organization’s existing capabilities.

A Holistic Look At The Triple Constraint

I’ve previously argued that the triple constraint is more a myth than a useful project management tool.

Roger Atkinson’s academic paper takes a different approach, the argument is the triple constraint (referred to in the paper as the Iron Triangle) is only a subset of project management criteria, and a better approach is to combine 3 additional sets of metrics to capture project management success holistically, one of the metrics Atkinson proposes is IT specific, but the others capture stakeholder benefits and organizational benefits.

It makes sense, time and budget can be the easiest things to measure but aren’t necessarily the most important. See the full article here.

Project Failure – Scottish Parliament

source: Asif Musthafa (via Flickr)

The Scottish Parliament overran initial costs by a factor of ten and was delayed by 3 years.  It is clear that similar to the Sydney Opera House the design was not finalized before construction and estimates were not backed by a credible cost estimation process. For example, here are the 5 finalists chosen from a shortlist of 12 in May 1998. Only one of these finalists adheres to the budget, every other proposal fails to meet the brief in terms of both cost and size. It is absurd to specific minimal criteria for a brief and then fail to shortlist finalists based on those criteria. When a project starts with this level of disregard for process, it is unlikely to ever get back on course.

Source: House of Commons Briefing (for reference EMBT/RMJM was selected)

From there, the project continues to unravel, for example the architect then added 4,000 square meters (+14%) to his design area. It is perhaps not surprising that the project manager resigned just over a year into the project because there was clear tension between the sponsors’ desire to have the Parliament ready as soon as possible and the architects’ desire for a “gestation period” to really flesh out his design together with a need to be engaged in all decision making. The lead project sponsor (Donald Dewar) and architect (Enric Miralles) sadly both died during the construction period, which further complicated the project.

Detailed reports on the project can be found in the Hollyrood Enquiry and Parliamentary Briefing and this article from Max Wideman.

Quality

It is worth noting that the Scottish Parliament has won many national and international architectural awards. This is similar to many delayed projects in that they fail specularly on time and budget constraints, but the quality of what is delivered can ultimately be extremely high, even if the apparent process in creating it was not.

Conclusions

The process of selecting and managing the new Scottish Parliament had no regard for credible estimates from the outset. As a result it is unsurprising that the final result bore no relation to the initial estimates. It also appears that the sponsors of the project wanted quality above all, and in that context it is not surprising that cost and time gave way to that objective.

Managing Risk – Part 3

photo: Paul Belson (via Flickr)

One of the reasons risk management goes wrong is a psychological phenomenon called anchoring. Anchoring means that once an idea is out there (such as estimate of when a project will end) it has a lot of power and influence, even if it’s not intended to.  Lots of academic research documents this across various settings and context and it’s pretty robust. Once an ‘anchor’ is set, even unintentionally, it is notoriously hard to move it.

What does this mean for risk management? Well it means that once a project plan is out there, the initial estimate will be changed more slowly that it should because of these psychological factors. If the project is was initially meant to cost $3M and then a revised estimate comes in at $4M, the estimate is more likely to move to $3.5M than all the way to $4M, because of the impact of the initial estimate, even though it’s now out of date.

Good risk management should ensure that only the latest information is factored into any estimate, effectively starting from a ‘blank slate’ each time. However, even though this sounds obvious, the impact of anchoring does mean that it’s hard to do in practice.