Optimising IT delivery with The Lean Startup

Delivering large IT projects is difficult. As this article highlights, a recent McKinsey study revealed that 17% of technology projects budgeted at $15m or higher go so badly wrong they threaten a company’s existence and over 40% of them fail.

The causes of failed IT projects are many and varied. There are many guides on how to set-up projects for success, however, huge risks are often taken committing £multimillion budgets to what are highly uncertain and unique projects. It can be difficult, or actually impossible, to forecast and plan for all of the unknowns that are encountered across architecture, requirements, design and delivery.

The Lean Startup

One solution to this problem is an approach described in ‘The Lean Startup’​, a book written by technology entrepreneur Eric Ries. His approach takes principles from Toyota’s Lean manufacturing and applies them to technology projects. This innovative technique can work equally well for large company  technology projects as for tech startups and has parallels to Fast Track Architecture.

The method can be thought of as “Think Big, Start small, Scale fast”. It favours experimentation over elaborate planning, customer feedback over intuition and iterative design over traditional ‘big design up front’ development.

A few principles are key to this approach:

1. A Minimum Viable Product (MVP)

The project should build the minimum possible scope to prove each iteration of the project. This principle means the project is delivering as fast as possible and not wasting time & resource by building things that potentially won’t be important to users.

2. Build->Measure->Learn

The MVP must be tested in a real situation with end users of the system. This informs the project as to what works, what doesn’t work and what needs to change in the next version of the system. It’s important to set-up accurate measures of the business outcomes the project is aiming to achieve.

3. Pivoting

The project should ‘pivot’ when measurements have proved an approach isn’t working and a new course of action is required. This is more easily achieved with Lean Startup because you’re spending less money and time on an iteration so it’s easier to make a management decision to course correct. This could also be thought of as ‘fail fast, fail cheap’.

The Lean Startup and similar approaches have the potential to have a revolutionary impact on technology delivery within large companies and they are being adopted by many organisations; check out the major programme that GE have initiated here.

Lean Startup will feature again on this blog. It would be great to hear your thoughts on the subject.

Kind regards,
Matt Wood


6 thoughts on “Optimising IT delivery with The Lean Startup

  1. My understanding of Lean, based upon formal training in the subject) is that it is a useful technique when applied to highly repetitive and identical (or nearly identical) processes.

    My experience of IT projects and start- ups are that they are usually unique, or at least there is some significant aspect that makes them stand apart from previous projects/start-ups.

    I’d be interested to know how you propose applying an approach designed for optimising highly repetitive processes to a one off process.

  2. Hi Bernard,

    I held the same views about Lean until I read The Lean Startup. In fact, I avoided reading up on the subject of applying Lean to IT for many years because I didn’t see how it could help. However, Eric Ries has taken the principles described in this article and others such as small batch sizes and successfully applied them to IT delivery.

    On a related subject I’ve found it difficult to clearly articulate the difference between Fast Track and Agile delivery but The Lean Startup really helps. Eric developed it because he was was using Agile delivery and had a number of failed projects. His approach (and the Fast Track approach) should lead to a higher success rate of project delivery. His book is well worth reading.

    Kind regards,

  3. Lean is a methodology that utilises feedback loops. There’s nothing magic about feedback, what is unusual is for people to realise that when decisions are made in an environment of uncertainty that you should regularly revisit those decisions. This is why most sequential processes fail – early decisions are assumed to be correct.

    Many government projects have an RFT in the middle which actually prevents the implementation project from re-assessing early decisions.

    Similarly, many start-ups do not re-evaluate their strategies and decisions in the light of a) new knowledge and b) changing market conditions.

    My only real observation regarding what I’ve seen of The Lean Startup is: why base an approach on Lean, which is based upon feedback, when going straight to control theory would be much more productive.

    FWIW I have postgraduate qualifications in control engineering and have long advocated the use of feedback processes rather than sequential procedures, especially in environments of uncertainty.

  4. Bernard, uncertainty implies a multi-hypothesis space and therefore what you should be looking for are any idea that observe an element of coherency and testing these – see http://www.infoq.com/articles/cynefin-introduction.

    What you advocate, and the mistake that Ries makes is to assume that a linear process is appropriate, with or without feeback loops, will deal with complexity. This is basically the subject of my submission to lean agile Scotland this year.


    • Greg,

      I’d be interested why you think I’m advocating that a linear process will deal with complexity.

      FYI, my PhD was in modelling non-linear dynamic systems and my assumptions when dealing with complexity are that, at least in part, the complexity comes from the non-linear nature of reality. Linear models are simplifications and simplification often makes the subsequent model misleading, if not completely useless.

      I am familiar with cynefin and while it has some interesting things to say about modelling, I don’t find it particularly useful.

      And re “uncertainty implies a multi-hypothesis space”.

      Uncertainty might imply a multi-hypothesis space, but it could also imply a single hypothesis space but with errors in measurement and prediction.

      • Bernard, because you are still advocating control theory which assumes that you are operating in an ordered space, that is the system can be modelled, where as the value of cynefin is it provides some practices that deal with a non-ordered space (it’s about bounded applicability).

        There is a great story in Gharajedaghi’s Systems Thinking, Second Edition: Managing Chaos and Complexity: A Platform for Designing Business Architecture (p. 126) –

        A minister of economy in my native country once asked me to help him assess the impact of a certain decision on three important factors he was concerned with. I told him it would take me a month to develop the proper model. He replied, “The decision is going to be made without you. If you want to have any influence on this one, be in my office with your model at 7:00 a.m. Monday morning. Otherwise, get the hell out of the way.”

        Sometimes you don’t have the time to develop a model! You should also read the appendix of Stacey’s Tools and Techniques of Leadership and Management: Meeting the Challenge of Complexity

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s