"This isn't a project plan, it's wallpaper for the Tardis you're going to need to meet these ^&*&%*& timescales."
"Why is it a programmer has these success stories on how he constructed in his free time the most incredible foo-compiler within 2 days? Without bugs? Why is it that the same programmer cannot finish a simple dialog for a payroll system within the agreed period? A period he himself indicated (which by the way he largely exaggerated)? If it isn't going to happen any way, why does a project manager bother planning programmers?"
Ok, the previous paragraph is meant in a provocative manner. But being a software project manager these questions cross your mind. And off course, there's another view on the subject, that of the programmer…
"Why do I have the following discussion over and over with the project manager: 'I told you it would take 3 weeks - why did you cut it to 2 weeks, just because it met the quarter reporting deadline'. Why do I have to tell you that your $%^&^ plan bears so little relation to the Babylonian calendar that the rest of the world uses that you must be a ^%%&* Maya."
I know why I need a planning. It is a useful tool to communicate the tasks, time scales and dependencies within a project. It's a way to indicate the agreements with several parties on when what is ready. But why should programmers be bothered with a planning? What are the effects on them handing over a Gantt chart? Is it the right way to communicate any way? What does a programmer want from a planning?
So, I posted on an internet discussion forum this simple question: "Can you tell me why you (as a programmer) need a planning?" This section reflects some of the answers and, of course, strongly my personal view on the matter.
Planning vs. schedule
I will use the term planning and schedule interchangeably in this section. Actually a planning can be a larger document with backgrounds, etceteras, and a schedule (tasks, person, time). However, large documents are never read, and everyone just goes straight for the schedule. So, in most cases just the schedule is provided. That's why we can use the terms, for the sake of this section, for the same item.
Agreement
When I order some furniture in Holland, the guys who will deliver the stuff at my home will send me a letter indicating which day they will come to my doorstep. The day for them starts at 8am and ends at 10pm. So, I take a day off and wait. Sit and wait.
Sit and wait is not my favorite waste of time. Especially on the job (I'm a fanatic, what can I say). For the projects I run, I will have some kind of planning, so I know when I can get my stuff to bring to the next guy. This next guy is also glad that I can tell him exactly when he gets the stuff he needs to do his thing. All in all, from my planning I can tell a lot of stories.
My storyboard in this respect might be a Gantt chart. I can send this chart to a fellow project manager, and he will immediately now what I mean. I use the chart also to put in how long and when a certain programmer performs a specific task. I do this to put our mutual agreement in writing. "How long will it take and when will it be ready?" "Well, it takes 1 week and I start on Monday." The Gantt will be used to let the programmer know I agree on what we agreed and let the rest of the world in on out little secret.
So, that's why I, a software project manager, send the programmer the planning in the first place. Why do I need a written agreement, and can't I be satisfied with just a telephone call? I wasn't even aware of the question, let alone the answer… But someone posted on an internet discussion forum a fairly good answer…
You need a schedule for the programmer, otherwise he will never do the job you ask of him. Remember the first paragraph with the foo-compiler and the payroll system? This specific programmer would rather be writing a compiler then creating a non-challenging dull dialog for the payroll system. So, if you let him schedule his own stuff (or no planning at all), he will probably do the things he really likes first, internetting, chatting or taking the kids to the zoo.
If you would approach this pessimistically, issuing a schedule is the only way to provide the project manager with some power; non-delivery of a product is something that can be proven easily, and is therefor a perfect form of surveillance on the programmer. And this form of monitoring is needed, otherwise the programmer just slacks off.
I'm not completely happy with this form of reasoning, it's to darn pessimistic. But, if we are looking for a short statement on reality, this one is fairly close to it. I want to communicate to the programmer our agreement. This is still the case. I'm only wondering if providing a Gantt chart is such a smart move. I'm curious how I will respond if he answers me with something in UML or Bachus/Naur form.
What this thing called 'planning'?
The software project manager walks into the room. Very proud, handing over his new, fresh Gantt chart. It's shiny. The programmer looks at it. Holds it up, against the light… The project manager wonders what the programmer is thinking.
"How do I read this? What is this?" The more experienced programmer goes straight to the second thought: "What happened to my numbers? I told him it would take 3 months, why did he slash it to 1?" Actually, this may not be a surprise if you think of the planning as a written agreement. The programmer first looks if it might have changed, by one party. The one who writes the document, has the power to change the text. And sadly, the 'text' of a schedule is very limited; there is no explanation on why things are what they are, why the estimate was changed. Decreasing someone's estimates of his own tasks, is a bad suggestion in the first place.
The handing over of the planning is the first form of feedback from the project manager on what he actually did with the estimates the programmer provided him earlier. If they're the same, the manager gained some credibility, if not, he's lost forever.
Focus on the past, not the future
But, this large chart, does it provide some use for the programmer, besides just the line with his own tasks? Yes it does… it can provide insight in the quality of preparations for his task. The tasks after him or not of much interest, but the past, what happened before is key.
Having the right preparations is essential. Without them "… the result is that when I have to do some work, I loose a lot of time getting the preparations done (that have been 'forgotten' to take place), talking to people that I need the results NOW, doing things myself because the right person has other priorities, etc. And the result of this is that other people come to me wanting results NOW for work I didn't know I had to do…", as one programmer puts it.
So what?
I hoped that I could say "we can throw the planning out of the Tardis, we don't need this thing". Sadly, we do. It's a way to communicate an agreement. However, if this way should be plotted on A1 with only a Gantt chart? I don't think so. I hate these charts anyway.
Leave a Reply