Project plans in software projects....

Some key concepts to get out of the way first ...

Project: Has an objective, a clear start date and a specific end date. If these are missing, a different term may be more suitable (undertaking or a venture come to mind).

Now to the plan and a few of my issues with current generation project management tools.

A plan has the following core components:

1. A break-down of the work that needs to be completed (best guess anyway -- can be determined reasonably well for the short-term, but gets harder as we move into the future)
2. Resources that will undertake the work (Can be allocated with some confidence at the 2-4 weeks scale)
3. The order in which work will take place -- a schedule of sorts with a time-line

What will get done, Who will do it and How/When will they go about should be apparent in proper plan.

------

Now to the real interesting part - each of these components from a 'problem framing' perspective require very very different thinking models.

1. Work breakdown is a 'decomposition problem'. We need to consider the level of detail/abstraction. But it is generally a good idea to have work expressed and communicated as a set of outcomes (much easier to know if you have actually completed the task this way)

2. Allocation resources is well .... an 'optimization problem'. We have a fixed pool of resources with certain skills and knowledge. We need to allocate these for the most optimal outcome. A first pass of this can be done without taking into consideration the time-line (though it is tempting). Again a good practice, because you are not preemptively thinking ahead too much.

3. Scheduling yet another 'optimization problem', only now you have to take all aspects into the equation. The overall strategy, actual work as decomposed, people and time/cost.

Planning is a complex problem solving activity, with some distinct problem types each of which require a slightly different hat and frame of thinking.

----

So far so good. Now for the mess-up by the tool vendors. Almost all traditional project management tools provide a user-interface model that requires the user to think about all the of above activities pretty much at the same time. So, we create a task, allocate resources and set start/end dates and include dependencies. Good planners do innately understand the above process and tend not to get too carried away by the tools focus, but when we teach project planning -- these is a need for a tool that essentially forces a certain structure (or) at least allows the user to choose a 'reference frame' which hides all non relevant information.

Some of the work done by David Allen in GTD (Getting Things Done) essentially take this perspective where they get people to focus on tasks from a context.

I do not want to directly blame the tool vendors for producing the current generation of planning tools, just a request to see some additional features that allow the user to 'hide' information. I also strongly believe that this would most certainly improve the quality and effectiveness of the plans generated via this process, even if it takes a little longer due to the iterative nature of the process described above.

-- rv