Results Oriented Project Management

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


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:


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.

9 thoughts on “Results Oriented Project Management

  1. Ed, I think this is a very useful insight.

    A result, then would be a deliverable in a scope document. Do you see that as 1:1, result:deliverable?

    My one suggestion, for documentation and planning purposes, is a granularity under Result. Maybe call it “Method” or “Article.” This might be (mostly?) used only internally, but helps generate execution checklists. So, a Result of “customer history migration” would have Methods of specific data templates, verification reports, etc. Or, it might have “Customer Migration Protocol A” which refers to the consultant’s internal document specifying procedures to use.

    But I really do like the concept, and the way it can scale in a Scope Document, and timeline.

  2. Thanks, Jerry. I am glad you find the idea appealing.

    Actually for software implementation, the term deliverables refers to tools that are intrinsic to the project itself. For example, the project plan itself is a deliverable. A schedule of education classes is a deliverable.

    The detailed results are called the functional requirements. Examples include a converted data table of customers, all forms and reports such as an AP check or Commission Report by Territory, any interface with the main system such as an EDI bridge, and any procedural changes.

    At this level you are correct, these would be at a 1:1 relationship; so result:functional requirement.

  3. Pingback:On Agile Project Management

  4. Ed,

    I agree with your concept of emphasizing objectives and results in project planning, but they should be merged with the traditional tasks/activities, not replace them. Of course objectives and results should be defined, but to achieve them you must also define what is to be DONE – i.e., tasks/activities. For example, in David Allen’s GTD methodology, project outcomes are visualized, but only defining the NEXT PHYSICAL ACTION(S) advances the project.

    Jim Caruso

  5. Jim, thanks for you comment.

    Perhaps you are correct that merging the ideas would be best. To be clear, I am not against activity planning, just that most knowledge projects, unlike construction project, do not have a clear or even critical path.

    I wanted to devise a system that allowed knowledge workers to apply their own creativity to the work to be done. I believe doing so will allow for more innovation.

    In other words, I would live it up to the knowledge worker to define the task/activities which would allow them to best active the objectives/results.

  6. I couldn’t agree more, the shift to outcomes versus inputs (activities/tasks) is absolutely critical to avoid wasted investments, especially in software! Fantastic ideas!

    With this model, I’d like to know how you see goals fitting into the picture, can we put them somewhere in the hierarchy? By goals I assume we both mean the potential value of the ultimate expectations (the impetus for the program/project/objectives). I embraced the ideas of agile development’s focus on outcomes, not inputs long ago. I found that customers were happy to shift towards outcomes. But I also found that customers often do a lousy job of connecting outcomes to goals, if at all. And it’s very rare for the goal to come before the desired outcome, something that now blows my mind. I would even go so far to say that scope creep is for the most part caused by misaligned (or absent) goals!

    Lastly, to connect back to your post about agile, I think the big thing in agile is embracing the reality that no matter how much planning we do upfront, there are going to be outcomes we miss, or just aren’t aware of, that are essential to achieving the desired goals. Of course those would be Change Requests. I wish I could quantify in my head how often this happens, unfortunately the scope creep from misaligned goals blurs the lines. Nonetheless, the reality that we will learn even with the most diligent of planning is why I think it’s crucial to ensure there are high margins in software development projects. Perhaps I might go so far to say, if there isn’t a conversation of goals, the margins had better be higher because there will be that much more to learn in the process.

  7. Thanks , I’ve just been looking for information approximately this subject for ages and yours
    is the best I’ve discovered so far. However, what about the bottom
    line? Are you positive in regards to the supply?

Leave a Reply