27-Nov-2006 - Planning
As I could see, I got some comments to my Sorry Folks post. The comments led me to write something about planning and its importance.
You can not start a project without planning it. This is a premise for all kinds of project, from a construction engineering project to software development. I don't have to state here the importance of it since you all work with projects and are aware of what might go wrong when planning isn't revised, well done or not done at all.
This post isn't about planning software projects that are beginning but planning new features or changes to an existing project.
In my Shop (to follow what you're used to call it), new developments are decided between Commercial and Development teams. If major changes are implied QA and Direction get involved. Let me illustrate how planning used to be done with a little story that shows what you shouldn't do in a software project.
Direction and Development decided to deliver a functionality that was supposed to be ready in the end of August. This functionality was really complex, never sold to any client and was never delivered to the QA team. According to the developer itself, it wasn't tested for a while but should be OK. QA and the programmer were responsible to plan the project.
From the programmer point of view this was a delicate functionality, very complex and critical to the client. From the QA, this was really hard to test because database and interface should highly protect data. From direction point of view the problem was solved a long ago so they could deliver it the next day. The deadline was decided by Direction and Commercial department. One month to test and rework if needed.
The major problem was, the programmer would be out for 2 weeks, the technical support expert would be in only for 2 days, Development Manager would also be out for 2 weeks and QA (didn't have vacation at all) had only one member who needed support in the issue. In 2 days the technical support expert created the necessary and highly complex resources and the planning meeting took place. QA blindly tested for 2 weeks and the Development Manager wasn't helpful. When the programmer returned, a lot of huge problems were detected and in a week he helped test completion. There was one week left: effort to retest was of one week non-stop (night hours having major database changes running), the application needed to be corrected (I remember this was a very complex functionality) and the deadline was at the end of the week.
It would be impossible. However I detected that the client wouldn’t use the functionality in the end of August (31), they needed to do something huge that day and so they would only use this functionality a month later, for instance three days before the end of September. I got to put commercial team contacting the client, informing them that in order to not loose services they actually needed the function almost one month later (it was true), so we had the delay we needed.
I helped the programmer to understand and redesign the functionality and detected that a part of the functionality needed the intervention of dev manager. So we put the first part of the functionality working, tested it well. And then, since the second part would be used only if the client had troubles and had a work around, we decided to document everything.
The functionality worked fine and the second part wasn’t needed by the client.
Several things should have been done in this sub-project:
- Since the programmer didn’t work with the functionality for a long time and wasn’t sold to any client, an evaluation of the state of the art was really needed before planning;
- Since team elements were on vacation, the planning should consider when human resources should be simultaneously present in exactly what time;
- The delivery date shouldn’t be agreed before the two previous points were sorted out.
This example shows that when planning it is important to consider the team availability for the project, the complexity of the tasks, the time to develop, the time to test and time to correct problems (certainly if the complexity is low it’s shorter than when you have a very risky function).
If managers allow people to plan before they give deadlines, mistakes will be avoided, work will flow on time from one team to the next and if they might have to rework it will be minor changes…
Planning has to be done knowing what each one has to do in the project and other projects. When considering a big new project we might use crossed Gant graphics however in minor features or corrections, this task is much easier.
I have to remind that if planning doesn’t consider what might go wrong people are always delivering low quality work, are stressed out, teams work late… And that is a source of mistakes too! Developers, programmers, technical staff are people, that need to feel good with themselves and have proper time to rest in order to produce higher quality work in less time! I’m completely against working on weekends and after 8 pm, people need to have a life, rest their minds from their tasks in order to return fresh for the next day of work.
What do we do when we realise we can’t deliver everything? Our programmers always inform changes the moment they detect them. When deadlines can’t be changed and they realise they won’t do everything on time instead of delivering whatsoever, unsure if it works, they analyse what’s critical for the client, which are the most important features, and leave the minor things to the end. These priorities are identified and people are informed immediately. When QA team receives the features and the D day is close (major delay in the reception of the product) also has to prioritise tests. We only include in our versions what is working and when there isn’t time to test it isn’t included at all. We prefer to deliver high quality products, with value for the client, maybe leaving one minor thing for the next version rather than ruining clients business…
| 
