What We Liked – Part 3: Reconstructing Project Management
Peter Morris starts out this part of his book by posing the question:[3]
"Is project management a discipline or a domain? If it's a domain, we can sit back and ruminate at our leisure. If it's a discipline, things get tougher: there has to be logic – a discipline – to the way its knowledge and its actions are deployed. And people need to be trained in it and practice it. This is the subject of Part 3: how should the elements of project and program management be re-assembled – reconstructed – so that the discipline adds value, given today's and tomorrow's social and business needs?"
Well, the description seems to answer the original question. Project management is a discipline. No doubt there are some academics that prefer to see it as a "domain" so that they can indeed "sit back and ruminate at [their] leisure". This at a time when what is really needed are foundational studies and testable theories to underpin what is actually done in the course of successful basic project management (note, not including technology management!)
Peter then embarks on quite a long scholastic discussion of the character of our PM Knowledge, in which he gets into "ontology", "epistemology" and "methodology" and even "teleology".[4] Along the way, Peter discovers that if the label "project management" does not cover the whole territory then another term is needed. Such a term as "The Management of Projects" could cover both programs and projects – and project portfolio management for that matter.
"Its unit of analysis is the project. The project is defined, pre-eminently, by its development life-cycle. The Management of Projects is as concerned with managing the front-end as with the down-stream execution."[5]
Obviously, that reference to "development life-cycle" should have read: "project development sequence". Setting that aside, however, Peter chooses to refer to the whole area as "mop/p³m" which stands for: "management of projects/project, program and portfolio management" – a not inconsiderable mouthful. We think that simply establishing an "official" change in the definition of "project management" would have a greater probability of success. Indeed, it is already frequently used in that sense.
Peter also suggests that rather than:[6]
"... projects being defined first and foremost as temporary undertakings ... We have surely to begin with addressing the 'why' and teasing out what are good practices relative to accomplishing projects and programs successfully."
Well, yes, of course, but that is the purpose of a well framed but succinct Project Business Case – to answer the question: Why this project? Project management is a delivery system and if you don't have a satisfactory answer to that question, or indeed have no answer at all, there appears to be little purpose in doing the project in the first place.
In our view, the satisfactory answer to the question: "Why" should be the culmination of Peter's "Front-end phase work". And, yes, since money is necessarily spent on such preparatory work, it is definitely a part of the project investment – and should be recognized by all concerned as such. This would be entirely consistent with our proposed revised definition of Project Management, and provide a more substantive basis for achieving and assessing the success of the project and its resulting product. Unfortunately, current literature and practice, to say nothing of standard accounting practices, do not appear to support this position.
In Summary, Peter observes that:[7]
"We are well past the critique that says that project management professionals need to move beyond the mechanical application of practices and techniques. There is method behind the application of mop/p³m, but there needs additionally to be understanding in some depth of the different disciplines and knowledge domains that are called on in creating and delivering projects and programs effectively. The ensemble needs to be applied in an ordered way: moving from the business case and strategy; through technical and commercial development; building an organization; exercising control; making decisions; and managing people. ... The task of the project manager is to integrate the work of these different specialists to achieve the sponsor's goals."
All of that is perfectly true and we applaud the logic behind the sequence described. But we see two shortcomings: First, there is work involved in the project before the project's business case, in order to arrive at that business case, and that incurs costs that are, or should be, a part of the project. That is to say, Peter's "front-end" starts even earlier than just at the business case presentation and approval and, more importantly, that prior work can also have a serious impact on the successful outcome of the project. For example, what if the concept described in the business case is fundamentally flawed, but proceeds because it is politically popular? Second, there is no mention of the army of technology specialists frequently required for the project and who also have to be managed as a part of that project?
3. Ibid, p232
4. If you don't know what these mean, don't worry – you can always look them up on the Internet.
5. Ibid, p235
6. Ibid, p116
7. Ibid, 247
|
Introduction
