Saturday, October 14, 2006

Painless Scheduling? with Poldina you can!

Scheduling is one of the most common activities that take place within a software company. Each one of us, being a developer, a consultant or a manager, faced it.
Poldina, too, studied the subject deeply and managed to craft a small theory that can be of help.

When the need to manage more than a few people and more than very simple projects rises, the Perfectly Educated Manager bores a number of holes in everyone’s patience and comes out with something like this:

Now we have complex activities broken down to simpler. For each activity duration and and owner are established. Precedence among activities is accurately defined. A number of milestones are set according to contracts.
Now everything can be kept under control and the Perfectly Educated Manager thinks that his job is done.

Cool, but useless, harmful and plainly wrong!

It is useless because each detailed Gantt is doomed to be subverted from basement by actual activities and probably only the final milestone will be respected. Given this probably it was worth only defining the milestones.
It is useless because it does not help the manager’s daily job, i.e. developers do not update the Gantt as tasks are over (the worst is when a group of people assigned to a task must asses the task overall percentage of completion…).

It is harmful because the solid, rigid, implicit task schedule work perfectly as long as they are respected to the minute. Each lead or lag too easily ends up in witch hunt to the faulty person who spoiled the harmony of the schedule. No need to describe the effects on people’s morale.
Maybe the Perfectly Educated Manager resolved not to be so stiff, but the fact itself of seeing each task changed in solid colored bar on the screen or on paper, stiffs his perception of the importance of schedules.
People can work themselves to death to meet an important deadline, and nobody takes lightly the decision to postpone a deadline. People can’t do this every few days to meet all the implicit intermediate milestones.

It is plainly wrong because, as everyone of us knows very well, the tasks do not occupy a solid period of time and precedence may be not so rigid. More, often there’s no time for the iterations required to fine tune a complex system or to cope with specification changes.

Paraphrasing a German leader of the beginning of the 20th century, “Gantts are only a piece of paper.”

So, Poldina had the occasion to carve out a quick guide to project planning and scheduling from her past experience. Let’s start from the egg.

First of all, have clear the goals and the final milestones. Often these are fixed by contracts. Then write down the skill set you’ll likely need. Try to find people who are interchangeable the most. I know that they’re more expensive than a bunch of chicken who are able to do one thing (i.e. one programming tool, one database etc.) but the right people, when glued together, can be incredibly productive and, sometimes, reduce your project’s duration to a point where there’s no need for a true schedule (this could solve the problem in such an elegant way…ah!).
Make sure also that specifications are written in a way that is adequate to your people. Specs will never be foolproof, nor they’ll contain all the information that the people working on the project will need. So they must contain the key information that are required to do the job or to figure it out, and this depends on the history and the culture of your people.

Now let’s face the duty of breaking down a large job in small tasks, this must be done because that’s the way the human brain analyzes problems.
Ok, a task does not occupy a solid period of time (if it is of any complexity of course, cooking hard-boiled eggs definitely do occupy a solid period of time…). The task related workload, in real life, is something like this:

It starts with a nose, usually when the task is informally discussed before a cup of coffee during breaks and lunches or some research is made from a general perspective. Then it rises quickly to a full or almost full occupation, then it slows down with a tail and may have some late bumps. While the bumps may represent late interventions to correct a bug or so, the tail is the most important part of the job. It is the period when the bulk of the effort lays on the back. It is at this point that dots on i’s and dashes on t’s are put and make an adequate job a great job to be proud of.
The area under the curve represents the total amount of work done. The height of the curve for a given point in time represents the person workload in that moment. No need to say that the solid block of time is the worst approximation possible of reality.

Given this, what is the graph that helps you the most to control the project and manage the workforce? In Poldina’s and mine experience is the following.

This graph has people on the y axis and time on the x axis, albeit the orientation is not the usual one. Unlike the Gantt, it focuses on people, who are the critical asset to manage. For each project member, there’s a bar that spans all the time the person is assigned to the project.
In this bar there are darker and lighter areas. Each dark area represents the period when the task almost fills up the time, each light area represents the superimposing of the trailing tail and the beginning nose and there is no fixed milestone between them. The individual tasks are a parameter written beside the line.
Precedence among tasks can still be drawn with an arrow from a light zone to a light zone.

It is clear that everyone can point his finger to a point in his/her bar and tell “I’m about here”. When everyone is done, just connect the dots and draw a line on the current date and, voilà, the project progress assessment is served.
In the perfect situation the two lines superimpose, otherwise all the points right from today mean a lead, all the points left mean a lag.

In this graph, operations like assigning a new task to a person or cutting it mean simply inserting or removing a segment of the line, with everything that shifts accordingly.
In the same way, the task completion level is not out of sight as the tasks are explicitly shown, anyway.
Punctual questions like, “what’s Joe doing now” or “Is this task done” can be easily answered. Individuals may update their situation by themselves simply moving the point of advancement and not entering weird information like “completion percentage”.
It is also useful to the individual member to have the situation available in a glance to manage their dependencies.

While the Perfectly Educated Manager is spitting in my face, I can assure you that this kind of representation has been very useful in the past. So, let me know what do you think about this.

P.S. To tell the truth I’m a Perfectly Educated Manager myself…


Post a Comment

<< Home