How To Recover From A Project Completely Out Of Control
How To Recover From A Project Completely Out Of Control?
Some time ago, I finally had the opportunity to read a book that was on my reading list for a long time: Black Swan by Nassim Nicholas Taleb. The book is about uncertainty and unexpected events.
NNT (as the author calls himself) explains that we live in an extremely complex world where we cannot predict all the events which will happen, and therefore it is silly to try planning or predicting future outcomes.
Throughout the book, he mentions several events that humankind did not dream of that caused terrific outcomes.
Even living in this complex world, we always try to planning everything. We always try to predict the future. But, like NNT shows us, Plans fail because of what is called “tunnelling”: the neglect of sources of uncertainty outside of the plan itself.
We humans believe that we are good at forecasting if we do the same task over and over again; we think the more routine the task, the better we learn to forecast… We just forget there is always something non-routine in our complex world that will destroy our forecasts.
Like NNT explains: most delays and cost overruns appear from unexpected elements that did not enter into the plan—that is, they lay outside the model at hand—such as strikes, electricity shortages, accidents, bad weather, or rumours of Martian invasions.
We cannot project the behaviour of a system if we do not know all possible conditions of that system. Therefore we cannot truly plan; all estimations will be, most likely, completely wrong. Let’s make the bridge now into software development.
Everything that I described before can be applied directly to software development, so why the heck do most of the companies (in my experience) still ask for detailed project plans and estimations? It’s ridiculous even to start when we already know that we will be wrong!
Why do we still have Executive Management asking for milestone plans with detailed lists of features for months (of course they need this information, but there are better ways to do it)? Why do we have people bothering themselves with Gant charts full of detailed information that will be obsolete as soon they finish printing out the Gant chart?
Why do we have management looking into sprint reports, asking why the Delivered stories are not as high in number as the Committed stories? Why do we even have management forcing people to learn “how to get better at estimation”?
All the previous examples can be considered evidence of fantastic waste! We spend days and days trying to achieve what we cannot, so what can we do to avoid all this waste? The solution is simple: DO NOT ESTIMATE and FORECAST.
Woody Zuill is a guy that writes a lot about #NoEstimates; there are many more people doing so, but Woody is one of the ones that I am following quite closely. I am starting to talk about the topic more often myself;
The idea behind this approach is simple: We understand that we cannot do any estimations. Therefore we do not lose time trying. But how can we predict where, exactly, we are going to land? We cannot, but we can provide a time interval wherein the product will be ready. At the same time, we guarantee that we can deliver the highest value to the customer in small intervals of time.
But how can we help our clients to apply these ideas? How can we help clients to recover from projects that are completely out of control and bring them into some state of predictability?
Below I will describe how I am currently helping one of my clients applying these ideas. Feel free to contact me if you need some help.
Just a small background information about the project. This project will soon reach the eight digit budget. It´s not Agile at all, the teams follow the PMBOOK, but that does not matter, the ideas can be applied in the same way.
Every time I pick up a project, the steps that I follow are always the same.
Make the whole Value Stream Visible
To help my clients, we need to understand what is going on in the whole stream. Remember this is a waterfall process, this means that is not enough to just map the development plus testing phase. You need to map it all – business requirements, technical requirements, etc.
To do this I asked for help to different people inside of the organisation; I started with the business analysts. I asked them to map all the different steps of their process into a Kanban wall.
After that, I repeated the process and asked the people that were responsible for transforming the business requirements into technical specifications to map all the process. This process would contain a second kanban board that would be placed after the first one.
I repeated the same process for all different departments until we reached the “LIVE IN PRODUCTION” stage. Of course, I like to fill up walls (I could do it smaller), but we ended up with a 10 meters wall.
The reactions to this exercise were extremely interesting. People were shocked how long the process took. Of course, everyone knew the different phases but having a 10 meters wall telling you how long the process is, forces people to think.
Many told me this exercise was never done; this was the first time that someone took the time to visualise the whole value stream of a project.
Visualise the work
The next step was to make the whole work visual on the wall. Again, an eye opener for many people. It is funny how many still think that power points, excels or project management tools tell you something about a project. For me, nothing is more powerful than having a bunch of post-its on the wall representing the different pieces of work.
I believe many of my client´s employees thought the same; many told me that even without understanding anything about the project (they were external people to the project, visiting the room) they could immediately see problems on the wall, just looking at it.
When you do this kind of exercise, the bottlenecks in your system will become very visible and it´s almost impossible to ignore them, unless you want to ignore them :).
When I joined the project, there was no idea how late the project was. Of course, we all had those Gant charts, and all fancy excels, but we all know those never tell us anything ;). So I needed to help my client to understand where they stood.
There were several steps that I took to bring predictability to the project.
Create Small Pieces Of Work
Organisations are like funnels; there is the top of the pipe and the bottom of the pipe. When you insert sand into a funnel, the sand will go out at a very fast pace.
If you substitute the sand for small stones, the stones will keep flowing but in a much smaller pace. If you put in bigger rocks, the whole funnel gets clogged, and nothing flows. Organisations are the same, if you are dealing with big pieces of work, the organisation will be clogged. You need to break those big pieces into smaller ones.
Limit Work In Progress
Limiting the work in progress helps the organisations to get things done faster. Let me use a very basic example of this concept. If you start to read a book on Monday, and you focus the whole week on that book until you are done, most probably you will read the entire book before Friday.
Now think that every day of the week you start reading a new book, and you will be reading five books at the same time. When will you be ready? You do not know, but most probably when the end of the first week arrives, you did not finish any of the books.
In organisations you have the same issue, people start too many things in parallel and do not finish anything. Make an effort and limit the work in progress as much as you can.
In general terms, throughput is the maximum rate of production or the maximum rate at which something can be processed. In this case, measure how many pieces of work the organisation can process for a specific interval. I usually measure this over a week.
Measure Lead time
The lead time is the latency between the initiation and execution of a process. For example, the lead time between the placement of order and delivery of a new car from a manufacturer may be anywhere from 2 weeks to 6 months. In industry, lead time reduction is an important part of lean manufacturing. In our case you can measure the time it takes from a business requirement is defined until the software is live in production.
In this case, you can measure the time it takes from a business requirement is defined until the software is live in production. Based on my experience, I would not be surprised that would take several months.
Start Forecasting Not Estimating
Having the previous information, you can start bringing visibility to what’s going on. Most probably the lead time will not be the most useful piece of information. At least not in a waterfall project where a piece of work can take months from the beginning until the end.
Instead, use the throughput, measure how many business requirements documents you do per week and do the forecasting for what is still missing. Yes, I know you think that business requirements documentation is not always the same size, does not matter. It will converge to an average, use that.
Repeat the same line of thought to every single part of the system; you will be able to predict pretty well what is your situation. How late you are from the original plan in just a few weeks.
What Can I Do With All This Information
Of course doing everything I mentioned in this article will not improve your release date, but will give you pretty good information where you are and where you will be in few months.
If you are too far away from the original date, start a series of discussions about prioritisation. Of course, you should always focus on the most important features, but experience tells me that very few companies are good in prioritising their work.
Start having a series of discussions with stakeholders about what can be dropped in order to meet the deadline. Executive managers need this kind of information to make business decisions.
Applying the same ideas in the past, I helped one company to cancel a project that costed until that moment 15 million euros.
Do you think that is crazy to cancel a project after spending 15 millions? Well, think twice! With this kind of information, I was able to show to the board of directors that we would need to spend 20 millions more in order to finish the project. The company would not be able to take that hit and they simply cancelled the project.
If you are in this kind of situation, I can work together with you to bring your projects back to life 🙂
We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.Take The Test