Planning the planning

In my last post I postulated 18 points of inevitable steps in software development. Now I want to explain some of them. Let’s start on the top

First and – in my eyes – the one most important point is to organize the project evaluation itself. This might sound trivial but is most likely to get forgotten in the whole process. The reasons for that are diverse but one can classify them in two categories: other-directed projects and self-directed projects. An example for the first category are customer-ordered-projects whereas the latter could be normal product development e.g. implementation of a new major feature. In the first case, planning the planning is often omitted as a customer offers his own ideas on how things work. In the second case almost the same is done by some higher-ranking management person. Why first listen to those who should do the work when you already have a phantasy of what will happen? Never confront illusions with reality seems to be the devise here.

Everyone involved with project planning knows this situation: The idea of what the result of the project might look like has just been vaguely, informal described and now you are asked “Tell me, how long would it take?”. And now you are asked to compete with an absurd small period of time without any ressource-planning being made. And no matter what you answer – you suck! The worst thing you might do is to give an answer which can me interpreted somehow as if it is possible. But usually you should have enough knowledge in this situation to give at least an time-table what to do until you could answer this question and how long it might take. This is 1. because you got this position somehow and 2. hopefully for a good reason.

I’ve heard and seen a couple of cases where the give timeframe until the project can seriously be evaluated was far beyond the absurd assumption made previously. In this case you can either

  1. try by ignoring that you do not have the slightest idea of what the result will look like
  2. you are convincing that the time is necessary and either worth or the project is doomed or
  3. quit the job

Most project managers decide for the first option. As a consequence software development is most often somewhat of gambling where you can only bet whether the current project is doomed or keeps being dissatisfying. Please note, that the latter options is the more favorable one. Sad enough.

Leave a Reply