Published here August, 2009.

Introduction | Book Structure
What We Liked | Downside | Summary

Downside

We laud the idea of starting the project with a Project Initiation Document (PID) to establish a Business Case, per Step 1 in Figure 2 presented earlier, and then the subsequent "Project Approval by Phase" in Step 5. We also applaud the idea of establishing selection criteria and comparing risk and reward in making Project Selection, in Step 4, where "reward" implies determining the expected benefits. However, this model obviously contemplates that there are other competing projects and that means that project portfolio management is involved. If that is true, then there are several implications.

Firstly, the purpose of the Business Case is framed around the six classic logical questions:[9]

  • What benefit and cost the project brings to the business
  • Why the project is important and should be funded
  • Where the project needs to be implemented
  • When the project can be implemented
  • Who is required to implement the project
  • How the project can be implemented with success

However, we suggest that there are other considerations that need to be presented in the Business Case such as:

  • Just exactly what is the problem to be solved, or the opportunity proposition?
  • What will the project deliverables look like, and what will be their resulting impact?
  • Do we have evidence of stakeholder or business unit commitment to the consequent change in working?
  • To whom will be assigned responsibility for providing feedback on the actual benefits achieved?

This last bullet begs the question of who ought to provide the Benefit Tracking feedback? And this in turn requires looking at the typical organizational structure, a point that the author may have overlooked. In our view, any organization of some size consists of three main management groupings, namely: Executive management, Operations management and, if it exists, Project management.

Since the deployment of the products from projects are passed into the hands of Operations, it follows that those in the best position to conduct "Benefit Tracking" are a part of Operations, and not a part of Project Management. It also means that the commitment of the stakeholder or business unit to the project includes acceptance of the resulting product through a suitable transfer of care, custody and control. And further, it means a commitment to proper deployment of the product and some form of feedback of the actual benefits attained.

We believe that it is the responsibility of Executive management to ensure that these commitments are made and are solid, before including the project in the Project Selection process in the first place. The Project Management Institute's definition of "project" is simply: "A temporary endeavor undertaken to create a unique product, service, or result" and the project manager is "The person assigned to achieve these objectives". [10] Therefore, where benefits are concerned, the "Ongoing Performance Tracking" shown as the last graphic arrow in Figure 1, is not the "Project Performance" shown as the last graphic arrow in Figure 2, but product performance.

Once deployed, product performance is the responsibility of Operations management and is not the responsibility of a project manager. Indeed, this is underscored by the author's statement in the final chapter:

"In essence, the process for achieving project business objectives starts at the initial planning stages for the project and carries through to the final project implementation, after which it is incorporated in the ongoing operations of the business."[11]

One cannot help but imagine the grief that would ensue if a cadre of project managers descended on Operations and attempted to ascertain the actual benefits realized by the products of their projects. This invasion would be construed as a serious functional interference in operational management work. That may well explain why so few "project managers go back after implementing their project and measure the results as stated in the original business case [by asserting] that they are asked to move on to the next project and never look back."[12] Project managers are simply not given that responsibility - and rightly so.

However, none of that should detract from the central theme. That is, the idea that there is considerable benefit in project managers and leaders making a serious effort to view their projects from the perspective of ultimate benefit rather than simply "On time, on budget".

What We Liked  What We Liked

9. Ibid, p10
10. A Guide to the Project Management Body of Knowledge (PMBOK® Guide - Fourth Edition), Glossary, Project Management Institute, 2008, p434 & 436.
Editor's Note: While we think these definitions do have shortcomings, nevertheless they are widely accepted in the IT industry.
11. Berman, Jeff, Maximizing Project Value, p161
12. Ibid, pp67-68
 
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page