Reconstructing Project Management (2 of 9)

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.

Reconstructing Project Management (1 of probably 9)

Does project management cover the management of the project front-end, the definitional, development stages, or is it concerned essentially only with execution delivery?  What should it be responsible for?  How far does it stretch into concept definition at one end and operations at the other?

Morris, Peter.  Reconstructing Project Management Reprised: A Knowledge Perspective.  Project Management Journal, Vol. 44, No. 5, October 2013, p13.

With this post I embark on what I hope will be a series of nine posts, which diverge considerably from how I have historically presented content on this blog.  My focus has been on PM Best Practices and, as a practicing PM, my posts – at least from my perspective – have been intended as practical guides for the functioning PM in the trenches.  For the next couple of months, however, I’m going to wander into the (cue theme from The Twilight Zone) wilderness of PM Existentialism.

Peter Morris authored Reconstructing Project Management (2013) and was invited by PMJ to encapsulate the book for its readers.  If permitted (I’ve asked the publishers of PMJ for permission, which is still pending, to quote from the article for this series), I plan to take nine questions that Morris highlights in the article (Figure 3 Current issues in project management as a discipline, p13) and add my commentary and color, hopefully without getting too lost.

However, I don’t want to give the impression that Morris’ article is these nine questions (which, by the way, are also on page 111 in the book) or, even, that they are the central theme.  In the article’s eighteen pages, Morris condenses, presumably, the topics, points, arguments and themes of two-thirds of his book.  I’m pulling these nine questions, then, completely out of context and I encourage you to read the article (and the book) to understand his thesis.  When I read these nine questions, though, they spoke to me so deeply that I felt compelled to explore them beyond the (here I avoid the use of “mere” or “just”, maybe “unadorned” works) concrete expression that Morris has given us.  Further, I believe there is a tenuous link to my series on Governance.

By tossing these questions, like grenades, on the floor without further expanding on them, Morris challenges us to face the assumptions and core values that define our profession.

Practically a post’s worth of preamble, so let’s get to it…

Enterprise leadership holds their quarterly off-site to review strategy.  They return and the business line VP needs to replace the legacy, proprietary application with a cloud-based SaaS application that is the market leader.  She assigns a director responsibility for accomplishing this, who engages a manager to lead the day-to-day tactical project delivery effort.  The manager, following the company’s methodology, prepares a business case, a charter, a staffing plan and a time and cost schedule.  These are approved by the Director and the project kicks off.

Who is the project manager for this project?

There is so much depth and complexity in Morris’ first question (above).  When I took the PMP certification exam, the model project manager we were told to visualize was the construction PM for whom a sponsor provided money in exchange for a commitment to scope and time.  At that time I worked for a large IT consulting and project management company with aspirations of offering clients responsibility to deliver their projects – high value contracting based on responsibility for deliverables, not time and materials.

Fast forward to the world of today:  that company is limping along as a has-been, ne’er-heard-of-‘em firm and the PM community is bifurcated between reality and wants.  As a profession, we want responsibility for the projects, but in an enterprise reality where, instead, we are just responsible for delivery for someone else.

Executives, managers, and operations leadership make the strategic decisions about what projects to run and have ownership of the operational project decisions (funding, scope, who will be on the team and whether to pull the plug when things go akilter).  They don’t want the mundane tactical responsibilities (and risks) of project delivery, but at the same time there are three market factors that prevent the elevation of professional project leaders into that sphere.  First, those operational leaders, having gotten where they are, are not going to trust someone else with the responsibility (and esteem) for success with their vision.  Second, without projects, their jobs are just, let’s face it, boring.  Projects are the spice to the same daily gruel they otherwise consume (and that consumes them).  They live vicariously through our efforts.

The third condition that reinforces the status quo is that, if other project managers are anything like me, we love delivering projects and don’t want those boring, mundane operational responsibilities.  We are too happy doing what we’re doing to want to trade this for the better world where projects are run by project professionals, but at the cost that we are tied down to quarterly budget cycles, annual personnel reviews (which, btw, should be annual budget cycles and quarterly personnel reviews), product support and maintenance, and enforcing all the petty practices and policies of the very model of a modern major enterprise.

So we take the bones we’re fed, we deliver the project to scope, time and cost (or, in a more mature organization, to process), celebrate the successful delivery, hand it over to them to support, and happily walk away to pre-storm with our next project team.

© 2014 Chuck Morton.  All Rights Reserved.