Ed Kless

View Original

Results Oriented Project Management

The traditional project term hierarchy as defined by the Project Management Institute is this:

(Program)
    Project
        Phase
            Activity
                (Task)

They are defined thusly:

  • (Program) – a group of related projects
  • Project – a temporary endeavor undertaken to create a unique product, service or result
  • Phase – a collection of logically related project activities, usually culminating in the completion of a major deliverable
  • Activity – an element of work performed during a project which has an expected duration and assigned responsible person
  • (Task) – an element of work performed in the completion of an activity which has an estimated level of effort and assigned responsible resource

The use of parentheses in the above indicates that programs and tasks are optional in project management. The remaining three (project, phase, and activity), however, are required elements of any properly constructed project.

In my work with Sage implementation partners over the past nine years, I have become more and more convinced that this structure is lacking in heavily knowledge-based projects such as software implementation. Furthermore, I think it pertains to all fields of knowledge work, such as: an accountant conducting an audit or a completing a tax return; a lawyer trying a case or processing a matter; and even a architect designing a building.

To correct this, I have been tossing an idea around in my head for over a year now and I think it is ready to be presented and criticisms levied. I call it results-based project management.

In short, it replaces the above mentioned hierarchy of terms with this one:

(Program)
    Project
        Objective
            Result

The definitions of program and project remain the same, but in place of phases, I substitute objective and in place of activity, result. Here are my definitions:

  • Objective – a collection of logically related results summed to explain  exactly what outcomes (not goals) of project will be
  • Result – a discrete element of output that has an assigned responsible party and an estimated completion date

A result can optionally have a resource assigned if it differs from the responsible party and an estimated amount of effort. Please note that the estimation of effort is for resource planning purposes only and it not intended to be used in conjunction with a timekeeping system.

Please note the shift from words used to describe actions (activity and task) to words that descript outputs (objective and results). This can be thought of as a shift from efforts (verbs) to tangible results (nouns). This is in keeping with the reality that customers by results not efforts and certainly not hours.

Reversing the flow of the hierarchy leads to an easy-to-understand definition for project completion. The sum of a group of related results can be thought of as an objective. The sum of all the objectives can be thought of as the project. It is when all results have be completed and all objectives have been met that the project is considered completed.

The challenge is, of course, defining all the results. This is what scope is all about and that is the subject of another post.

That is the idea in brief. I await your critiques.

N.B. – Two other definitions are helpful in understanding this post.

  • Responsible party – the person who is responsible for making sure the work is completed by the estimated completion date.
  • Resource – the person who does the actual work.

Often times these two are the same person, but that is not always the case.