Is planning waste?

Following on from yesterday’s post Is the Planning Game dis-respectful, I had a conversation with Dan North @tastapod . He started by saying detailed planning isn’t just waste, it’s wrong. By which he meant if you do a detailed plan up-front, by the time you come to do the work things will have changed you will no longer be doing the same tasks/stories you put into the effort into estimating.

Of course you shouldn’t break a whole 9-month project down into detailed day-by-day tasks.  As Dan says, that would take a long time and have little value.  It would give a very precise number, but it would have no more accuracy for the overall project than a higher-level estimate. You should only go into detail for the work you’re about to do and delay commitment on anything else.

[For the difference between precision and accuracy, I always remember a line from the otherwise excellent Ladybird book on Australia: “The road from Alice Springs to Darwin is approximately 1000 miles (1609.3 kilometers) long.” I love the fact they even put in the decimal point.]

And then Liz Keogh pointed me at Dan’s blog on The perils of Estimation. Read it now.

Read it? Okay, I’ll continue.

What are we actually trying to achieve? In Dan’s words, “The business … asked us a) how much will it cost to solve the problem, and b) how confident are we about that number?

In our company, we sell audio solutions which include custom silicon chips, DSP algorithms, drivers, development boards, demonstration platforms, evaluation & development tools – there are a lot of components which have to come together to make a solution. Given it costs $1/2M and 6+ weeks to “compile” (i.e. fabricate) a chip, they have a huge phase gate before shipping the design to manufacture, and fabrication slots have to be booked several weeks in advance. So we’re asked a third question: “c) when can you integrate with the hardware?”

We are still a very Analytic organisation . We haven’t yet worked out how to successfully convert Agile principles to IC design (although I have been discussing it with them for several years), and we certainly can’t do Continuous Deployment. In fact, we have only recently recognised that software is a critical part of the solution, and we’re still working out how to integrate it. So, while I have been given some freedom in my own team, and we are reviewing the development process, in the mean time I still have to fit into a reporting structure designed for chips, and I have to communicate with people in an Analytic mindset who use Analytic terminology.

I am working on a project as part of a solution built on major new functionality in forthcoming chips. We are having to expand the team temporarily to do this, which is a significant investment, and we are playing the budgeting game for 2013 at the moment. I need to give an estimate of how much investment we will need to be able to support this functionality or there will be no money in the budget for the work, and hence no solution (at least not in time for the market).

I intend to deliver the work incrementally, probably in 4-6 week increments internally depending on when there is a useful increase in functionality for colleagues to start using. But once the money runs out, work stops. And there are some key milestones which it will be very costly to miss (e.g. a major sales fair in January needs at least a demo version, and we need full support for the key features by the time the chips ship in May).

Traditionally in our company, projects are funded for the estimated life/cost of the project with a business case review if anything looks like it will exceed a certain tolerance in a key parameter, and also at major milestones such as fabrication. I have a new team, half of colleagues who have been working on this product through various releases for the last 2 years, and half of contractors from Velocity Partners based on the other side of the Atlantic. I have been very impressed with them in the short time we have worked together so far, but they are still an unknown quantity. At the moment the best I can say about this project is that it will take 4-8 months with about 70% certainty to support the key features in the solution, assuming Velocity are as good as they appear to be.

So I have managed to persuade the company that we will work with Velocity for 4 weeks to scope out the work, address key technical risks, gain an appreciation of how we work, and increase our knowledge to narrow the range and increase the confidence in the estimate. Then we will provide a list of high-level features and estimated timeframe so that other teams can start planning their integration. At this point, I will probably be asked for a detailed feature list, because that’s the company mindset, but I will try to keep it at a high major-feature level which will probably work out around 4-6 week increments

And then I will need to get formal business approval for the whole project in order to get the PO approved for Velocity. And give precise dates for particular releases. That’s how the company currently works.

Still not sure how to play that one…

So…is planning waste? There may be more effective ways of working in more Synergistic organisations who practice Continuous Deployment and have independent projects with a steady flow of value. But while I work with my colleagues on a more agile process, we still have to deliver, and we have to fit into the current reporting model. And this is a very high-profile project, so very visible where we haven’t been particularly visible before, so we have a lot of pressure and not much credit yet. And the management team are used to waterfall projects (and used to them being late :-). So they want to know how they are going to track progress on it.

As we deliver value, we will earn trust, and with it flexibility. Over time I will also explore varying our development methods with my colleagues. But for now I have to work within today’s system, so I need a high-level plan. It’s not waste. I just need to make sure it’s not wasteful either, by not going into too much detail.

Advertisement