Plans are nothing; planning is everything[1]

[1] Dwight D. Eisenhower


We already know that a lot of IT projects fail, and they have been high failing rate for a long time.  I recently had a discussion with my colleague who worked at Initrode, and albeit the company was successful and a major player in the world market, he was perplexed about how his manager handled the team. It seemed that his managers core task was to estimate the time for each tasks and then track it and adjust it if the task took a different time, and that act of adjusting was which perplexed my colleague the most:

Why would you do something, if you knew you would have to change it later?

Plans are Nothing

Schedule for getting back on schedule is a little behind schedule

Indeed, by that definition in continuously changing and intangible environment like computer science and type of plan is pointless. We learned that estimating is difficult and requires a lot of knowledge and feedback to improve the quality of our estimates, however there is inherent danger in estimating cost and task in IT, because the domain of computer science keep changing continuously, which invalidates our knowledge of the problem.

One significant example is TAOCP, which keeps getting updated instead of publishing new volumes. Although this example might be superfluous in the context of developing and managing large scale software, it is a perfect example, how a technical dept can arise from the advance of the environment, not caused by the decisions during development.

If I know I will change it later, why do it now?

Planning is Everything

Putting deadlines aside, if we were to divide development methodologies based on amount of the whole plan needed in advance we would get the two following extreme cases (form lectures):

  • figure out how to do it the best way, then do it
  • just do it, and figure out if it is right later

The first choice aims to indicate any possible “future” technical dept and tries to overpay it in advance, hoping that once the dept arises it will be enough. The second acknowledges the dept and delays paying it while hoping that, once the dept arises, the resources available will be enough.

I will not argue which side of the spectrum is better as it mostly depends on the project in question and it a topic for a whole another blog post. I just wanted to make a simple observation:

Just as doing is important for a startup, planning is important for established projects.

And by planning I do not mean plans (hint above). I would like to call it “the ability to change plans based on current situation”, but then I would be describing a principle of Agile methodology; the truth is planning is a more fundamental action that that.

Proper planning increases the knowledge of the current state of the project and improves the estimates about the projects; proper planning is somehow orthogonal to all software methodologies — all of them require it, they just make different assumptions about their estimates and evaluate them in different order.

Therefore now matter what methodology you use and what you do, go back to your plan,  re-evaluate it and make sure it properly reflects the state of your project. Possibly as often as you can, even if it is just adjusting  the tasks times for your team.