If it does not cover the front-end (a) is it fit-for-purpose (b) do we need an enlarged discipline or body of knowledge to cover what we need to know about managing the overall project? (Since managing the front-end is key (i) in building-in value (ii)in building-in [or out] future problems.)
Morris, Peter. Reconstructing Project Management Reprised: A Knowledge Perspective. Project Management Journal, Vol. 44, No. 5, October 2013, p13.
In my previous post, I noted that I have started a series of posts commenting on nine questions that Peter Morris asked in his October article in Project Management Journal. This post takes up the second question, above, which is a continuation of the previous post: what is the “scope” of project management?
Some executives are tossing around ideas for boosting revenue. They float this idea. They float that idea. At some point, somebody says, “That sounds good. Let’s do a quick reality check to see if we should commit budget for it.” If it doesn’t pan out – if it’s dropped without going through planning, execution and commission – was it ever a project? If not, then when does something become a project? When does this activity transition from on-going operational strategic leadership to a temporary endeavor?
If it does become a project, the vision, exploration and creation were surely part of the project, as was conceptualization, strategy, and the operational activities of enterprise leadership that normally precede “Let’s get a PM assigned.” But are these exploratory and creative activities part of what we would call the project before the fact? If they are, should a project management professional be engaged at these early stages?
How many project ideas have you known to originate from speculation about spending: “If we do this project, we’ll be so much better off because our expenses will be $xxx.” No, the project driver for discretionary projects is revenue and the factor that chills the enthusiasm is spending. So it is that Morris talks about the front-end activities – the pre-project activities – that are not considered project management and are the responsibility of executive leadership, whereas the PM is responsible for controlling spending.
Yet, how can you separate the Yang of expenses from the Yin of revenue? It wouldn’t be a project if it weren’t for the expected benefits. But Brent Flyvbjerg lists a host of reasons why technological (longest, tallest, fastest), political (monuments and attention), economic (making money off the project) and aesthetic (design and iconism) sublimes can lead project originators to exaggerate the benefits and underestimate costs and difficulties (“What you should know about Megaprojects and Why: An overview,” Project Management Journal, April/May 2014, vol 45 #2, 6-19).
Further, as Peter Taylor explained in the December 17, 2013 webinar (PMI and INPDCoP membership required) “The Journey of Expectation Management” for the PMI Innovation and New Product Development Community of Practice, expectations (and constraints) for projects are often set and locked in before the project manager is engaged. Yet, as Taylor goes on to say, it is the PM who is held responsible for project failure (often true even when the product is a resounding success: the PM for the Ford Taurus project was reprimanded for going over budget; the architect of the iconic, and 1,400% cost overrun, Sydney Opera House was so publicly humiliated that he never led another development of consequence).
Think about a bridge design where an artist and a financier draw up a bridge concept, go through the business case approval, then only bring in the engineer to monitor and control the construction. Would you want to cross that bridge? When we come down to it, isn’t that exactly what we have with projects? Engineering is a professional discipline and has licensing, legal precedent and authority for being engaged in civil projects. Is that what it would take to get PMs engaged at the start? Is that what it would take to eliminate Chaos from projects?
© 2014 Chuck Morton. All Rights Reserved.