Project Failure – Edinburgh Tram Project

Edinburgh Castle

The Edinburgh Tram Project exceeded budget by 52% and is the subject of an enquiry.  The issues with the project appeared to occur for two major reasons.

Optimism Bias

The project was born out of the political desire for Edinburgh to have a light rail system. However, reviewing past project it is quite normal for these sort of projects to come in over budget and extremely rare for them to come in under budget. Furthermore, increases over budget can be very large, often up to 80% over budget, whereas any cost savings are likely to be 10% or less. Seen in this light, the cost overruns on the Edinburgh Tram Project were not that unusual.

One way to avoid optimism bias is to first perform and estimate and then look at cost overruns on similar projects. For example, if you estimate a cost at 10 million, but past similar projects have seen cost overruns of 50%, then a better estimate for your project might be 15 million. This is becoming more normal practise in well-managed construction projects, but still, there’s a temptation to skew the set of other projects that you look at for comparison. This can reduce the uplift to costs, but may create a less accurate picture of how things will turn out.

Poor Governance

It appears that the management of project communications may have been poor. Stakeholders did not receive timely and accurate information and different agencies had different levels of commitment to the project. These frictions hurt the project. Once it was off course, then that information was not broadly shared, which then made problems hard to correct. In addition, different stakeholders working at different purposes did not help the project. It appears Edinburgh politicians were strongly in favour of the project, whereas national politicians were not.

Conclusion

In the grand scheme of things, the cost overruns of the Edinburgh Tram Project should not be viewed as a disaster, the outcome is similar to many other trophy projects run by governments and some cost overruns are likely with these projects based on history. However, problems in communication and lack of stakeholder alignment were an obvious issue that should have been relatively easy to correct.

Book Review – 18 Minutes

The world already has no shortage time management books, but 18 Minutes from HBR columnist Peter Bregman offers a concise and personalized account of becoming more productive. The book makes a strong connection between being productive and achieving the things that you want to achieve. Sometimes, time management books don’t make that important connection and you end up learning how to rifle through email efficiently, but not ending up achieving what you want to get done for the day, the month or the year. The personalized examples that the author works in also lend the book a credible human angle. The book is also pretty quick read (4-6 hours or so), so you’ll likely find some useful tips without it taking to much of your time. For me, the key insights were the reminder on how inefficient multitasking is, and how it’s equivalent to being drunk or on drugs so if you devote yourself to a single task at a time, you may feel slower but do a lot better at whatever you’re trying to accomplish and get it done faster with higher quality. Secondly, the importance of not being reactive to just what’s in your inbox but making sure you get out of email and think about what’s important for the day or for the year. It can be hard to make time for this, but it’s critically important to make that connection.

The title comes from the amount of time Peter’s process will take each day if you follow it, though to me, the book worked better as a list of interesting ideas, than a single plan to adhere to, and I think that’s ultimately the author’s thinking too.

True Requirements

Perhaps no task is more complex in project management than requirements gathering. The main challenges are with stakeholders asking for things they don’t need, and failing to ask for things that they do require. Prototyping or competitive benchmarking can both help with this problem. However, in many cases neither option is available. Prototyping and works for projects where the production cost is low but if costs are higher prototyping may not be feasible. Competitive benchmarking is only possible if the competitors are present, for example if you are addressing a unique market or one that’s not particularly congested. So you are left with the problems that stakeholders may be  asking for they don’t need.

The 100 points method

“100 points” validation is a useful exercise, because it forces the stakeholders and to make exactly the same as those of that you have to make. This is how it works. Having collected all the requirements from stakeholders, we then ask them to allocate 100 points across all of the requirements. If, for example, one requirement is absolutely critical above all others then they might ‘spend’ 100 points on that alone. If there are five requirements of equal value then they might ‘spend’ 20 points across all five. The only constraints are that the points must sum to 100, and no score for any requirement can be less than 0. In this way you’re able and to get stakeholders to supply quantitative information on what they need to see from a project.

Unspoken requirements create a more formidable challenge. Speaking to a large number of stakeholders can reduce the risk of omission. Secondly, ethnographic observation, which involves watching people going about the tasks that the project will help address. This can help you spots areas that are important but may not be explicitly asked for in requirements for example if you might see a process which takes 30 minutes of people’s time each day and you know with the project you can help reduce the time spent on that. However it’s so commonplace in the thinking of the stakeholders that it is omitted from the project requirements. This just scratches the surface of a very thorny topic, but 100 point exercise and ethnographic observation can be useful tools for determining your next set of requirements.

The Perfect Game

Last month I was at a baseball game on a hot August afternoon. The pitcher was doing pretty well, but there had only been 22 perfect games in the history of American baseball (which is a little under 400,000 games). So, being statistically minded, the odds of any baseball game being perfect game were about 1 in 20,000. According to a dubious probability site, this is about the same probability as being murdered or becoming a professional athlete and 4x less likely than getting a hole in one at golf, now to be fair this isn’t a completely valid comparison since most people who watch baseball see more than one game, increasing the chance of seeing a perfect game. Nonetheless, as much as a perfect game looked on the cards, I could not get out of my head the complete statistical improbability of it happening.

Nonetheless, it did happen, 27 batters up, 27 down, the 23rd perfect game in baseball and the first in Mariners history.

Aside from being an electric experience, it was a good reminder that though statistics can give you a guide to what may happen after the event the odds are always 100% or 0%. 

Read Better

We have all been taught to read and, a fairly involved process that culminates in the teenage years if not sooner. However, we then remain stuck with those reading habits . It’s worth taking time to think about what “advanced reading” looks like. This post offers a few pointers on ways that might make your reading more effective. Reading does not have to involve going through an entire book cover to cover, although this is how we do it with fiction as we learn to read. With non-fiction it can be more efficient to dip into and out of a book based on the areas of greatest relevance to us. This is why, of course, all books have a content page. It’s unlikely that entire book in and all of its chapters are going to be exactly what we would want to read. However within any book there probably are some chapters really going to be relevant for us. So starting with the table of contents and picking out maybe two or three chapters out of the 10 or 15 in the book is likely to be in a more useful way to go about reading than just reading every book cover to cover. Ultimately that means you can read more material that is relevant to you across a number of books rather than feeling obligated to read each book entirely, and as a result you can either spend less time reading, or cover more books

Listen Better

Most people (including me on this blog) tend to talk about communications from the point of view of the person delivering a message or taking the active role. This 8 minute video is interesting, because it flips the perspective to that of the listener. And listeners don’t do a very good job, hearing 60% of what is said and retaining just 25%. This video provides ideas for ways to listen better and be conscious of the filters that we implicitly use to determine what we hear.

How Fast Can You Fail?

It seems counter-intuitive to want to fail fast, but if you stop to think about it, it’s  far preferable to failing slowly. Killing a bad project early is superior to letting it run and not meet requirements. The faster you fail the sooner you can test another idea, and that may be the one that leads to success, and we know that psychological traps such as anchoring means that you’re likely to keep pushing a bad idea for too long, even if it’s not working out.

What this means:

• Seek feedback early (ideally critical feedback from a potential customer)
• Follow the path that will get you something testable as soon as possible (Frank Gehry builds models out of paper first)
• Determine what your criteria for success are (otherwise you might be tempted to bend the goals if you aren’t hitting your targets)

It seems counter-intuitive to make failure the goal, but getting through a large number of ideas quickly is a better way to find a good idea than plugging along with something that doesn’t work. The overall result will be more successes, faster.

Three myths of project management

“It ain’t what you don’t know that gets you into trouble. It’s
what you know for sure that just ain’t so.” Mark Twain

Here are three ‘truths’ of project management that need to be examined more carefully:

1. The triple constraint is a rule to live by.

No, the triple constraint has limitations and it breaks down at certain times. Adding more people can slow a project down because of training and network effects. Cutting scope isn’t linear, it’s binary, at some point scope is cut so much that the project can never succeed.

2. A delayed project is a bad project.

It’s critical not the miss the bigger picture, admittedly harder to measure than cost and budget but just as important, Wembley Stadium, The Scottish Parliament and Sydney Opera House were all late and over budget, but architecturally valuable. Most unimaginative structures get completed on time, but are they really more successful? Of course, the gold standard is a project such as the Guggenheim Bilbao that came in on time and received architectural awards.

3. For good estimates you need experts.

No, reference class forecasting is the answer. Using historical data is much better than using experts. Of course, if historical data isn’t available, then using experts can be a second best approach.

Planes, Trains and Projects – The Lateness Problem

Projects often come in later than expected. It depends on who you ask and how you measure, but 68% is a reasonable guess for the proportion of late projects.

The cost of having a schedule

Arguably though, projects put themselves in an inherently tough position, they have a schedule and that’s precisely what makes extreme lateness possible. Without a schedule there’s no way to be late, since there’s nothing to measure against. Think of a colleague at work who never sets a deadline, but never gets anything done. They’re never late, but only because they don’t have any system in place to measure it. I’m not trying to defend lateness, but the point is projects have accountability because of schedules and deadlines, that’s a good thing.

Comparison With Planes and Trains

Airlines in the US are late about 20% of the time, and trains are late 10-70% of the time depending on the route. Now, bear in mind these are processes not projects, they repeat many times whereas projects, almost by definition have never been done before. And yet repeated activities still suffer significant delays.

What This Means

Maybe we shouldn’t be so harsh on projects. It’s great that we have exacting standards, but bear in mind that:

• Projects are actually measurable, it would be easier to avoid deadlines altogether and eliminate measurement of lateness.
• Even processes experience delays, and they have the benefit of learning through repetition whereas projects don’t.

Something to think about the next time you shoot for 100% on time completion. Even though that feels like a reasonable expectation, maybe it isn’t. On the other hand there’s a lot of value in aggressive goals.

The false choice between process and agility

Now Starbucks print warnings on their straws. “Not recommended for use in hot beverages.”

Relentless rules, caveats and documentation are not likely to feed agile processes and innovation.

Agility trumps process. But there a third element that determines both – scale.

Heavy process is seldom chosen, it’s a by-product of scale. You can be agile the first time, the tenth time, but the hundredth time, the thousanth? Whether it’s coffee shops, construction projects or customers the logic is inescapable and the weight of process bears down on you.

You don’t chose process, but you do want to achieve scale, and process is the baggage that comes with repetition.

Netflix embrace agility, but will they still be able to do so when they are the main player in entertainment rather than the upstart competitor?