Tales of a consultant in decision support and data management (2) - Saying 'I don't know'

It is hard to admit that you don't know something - this is human nature. But a lot of the time, the pressures mount up. 

CFO: "Ronald, we need the product to be done asap, when do you think it can be ready?"
Me: "well, I can tell you when we will finish, but I will not know exactly what will be done" (I don't know)
CFO: "Huh? Aren't you the expert? We pay you for being the expert, so spit it out"

Now - ask yourself - what kind of consultant are you? Will you eventually cave in to the pressure and call out a number? Or do you dig your heels and persist in 'I don't know'. If you call out a number; please be reminded that the software graveyard is strewn with the carcasses of partially completed projects that were three to five times larger than anyone dreamed¹.

There is a subtle difference between speed and progress. You can drive with 200 miles per hour, but without a map, your progress will be zero. In other words, you need some kind of 'map'/plan and some kind of thoughtful analysis of the problem you wish to solve.

But even so, a plan is just what it is; 'a plan'. THE PROJECT WILL NEVER GO ACCORDING TO PLAN. Why; because most plans I come across envision some kind of fixed end-result. This end-result is often described by means of requirements. Even if we were to embark on a monumental requirements gathering process where we interview all people involved and write down all quality attributes, we would still not have a complete requirements specification that covers the quality demands of our business users (simply because they themselves do not fully comprehend them²). But  apart from that; such an elaborate process simply isn’t attainable.

If the finish line is not precisely known, the number of miles to the finish line is not known either. So - writing down in your 'plan' that the project will take '42' weeks to finish, is just another way of caving in to the pressure of calling a number. Don't do it.....resist....Do not comply.

 

 

If the finish line is not known, why not say 'give me xx amount of time and I will know precisely when I will finish, but I don't know exactly what I will deliver'. Or as Mike Cohn wrote it: 'When we acknowledge that the result is both somewhat unknown as well as unknowable in advance, planning becomes a process of setting and revising goals that lead to a longer term objective'³.

 

So - shouldn't we make a plan? Of course you should make a plan and a thoughful analysis of the problem you want to solve, but refrain from 'painting the finish line'. 

¹ Humprey - Managing the Software Proces - 1990
² Which is especially true for data products where the future use of the data is - by definition - not fully known
³ M.Cohn - Agile estimating and Planning - 2006