If you have used most popular project management software tools (Microsoft Project, etc.) you notice they encourage two things:

  • Schedule (time-line),
  • Tasks (and milestones) scheduled on a time-line.

One major issue with time-line based project planning is that the project plan is usually out of date by the end of the first week. Nothing ever goes according to plan so you either spend lot of time changing the plan, or just use the time line as a rough guide; not ideal.

Another common approach is to list all the things that need to get done (tasks or to do's) in a big list and then pull items off that list until everything is done. This is sometimes called a project backlog.

Are projects really about completing a predefined list of tasks or to do lists? Maybe.

But at the heart of most projects is not the time-line or list of tasks; it is what the project is meant to accomplish… the project outcome or results.

We get paid for creating results and achieving outcomes; not being busy checking off tasks and to do lists. High performers also focus on the most important outcomes at any given time, generating maximum value as they go.

So the better approach is to start from the overall project outcome (or result). This is the thing that if accomplished, you would know the project was successful. There are many paths to most project outcomes.

Then you start defining intermediate outcomes (results) that you can accomplish that will move you closer to the end game. Again these are results focused and not activity focused.

Unless you have already done something very similar in the past, a lot of up front project planning is pretty much guess work. This is fine. It is as good a starting point as any; as long as you accept that they are just guesses.

Some important considerations are:

  • The best way to consistently get results is to actually start moving and build momentum,
  • You don't need to know the entire path, just the start, the destination and the next most important step.

The agile software development community often uses user stories to define these intermediate results from a customer perspective. Developers then work on the highest value user stories (as defined by the customer) first. Project teams are encouraged to deliver business value early in the project and within each iteration.

This same basic approach works for any type of project.

The key is really learning to define outcomes (and results and stories) in a manner that captures the true business value; in a way that we feel inspired by.

Most business writing and almost all technical writing used for business is dry and emotionless. I think that long ago we decided as a group that writing from this perspective made us sound more professional. Sadly, this hasn't made our documents more professional; it has made them entirely forgettable; sucking the life out of us and ensuring no one ever reads them.

If you are writing a project outome imagine how the end recipient would describe the result if they were totally wow'ed; as if you delivered an awesome result. Capture that feeling somehow; tell a story.

I think you are much more likely to achieve awesome results and wow your customers if you describe your outcomes in this way.

What is the next "most important" outcome/result you can tackle?

Once you answer that question, each outcome is then further refined into a path and action items/tasks. The goal is to determine the optimal approach to deliver the outcome as close to execution as possible. Why? Because this is when you are most likely to know the most about the work at hand.

Tasks don't go away. To do items don't go away. The work still needs to get done.

What you are really doing is tying all the busy work back to business value so you can decide what is the most important thing to work on next; rather than just ticking of items in a list.

Getting results in business and life is not about getting all the work done. It is about doing the right work at the right time. You will NEVER get it all done and if you do there is always more. It also allows you to sleep better when you can't get it all done; at least you know the most important things were taken care of.

That is why I am now a proponent of managing projects by outcome… especially when the outcome can be awesome.