Before I get to the gist of the message, I want to define the vocabulary used.
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 where many project management tools struggle a bit.
A plan has the following core components:
- A break-down of the work that needs to be completed (often can be determined reasonably well for the short-term, but gets harder as we move into the future)
- Resources that will undertake the work (Can be allocated with some confidence at the 2-4 weeks scale, but harder beyond that)
- The order in which work will take place — a schedule of sorts with a time-line
A simpler way is -- What do we want to 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 different thinking models, and different skills to solve the problem as well.
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 rather than prescribed granular tasks. Outcomes makes it easier to check if you have actually completed the task and give the worker a lot more automony on how to execute.
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. Allocating resources without using the time constaints seems odd initially, but it is a proven good practice because you are not preemptively thinking ahead too much.
Scheduling yet another ‘optimization problem’, only now you have to take all aspects into the equation, especially time -- specifically: the overall strategy, actual work, 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. The traditional project management tools (as in those that follow and mimic the M$ Project paradigm) 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 this learning is gained over time. However by understanding that a different frame of reference is needed, the planners can overcome the way the tools focus our mind.
I am in particular impressed by David Allen's methods in GTD (Getting Things Done) as he tends to take this perspective where they get people to focus on tasks from a specific context.
-- R. Vasa