What if the project management body of knowledge wasn't what you thought it was?
I spent many years in my 20s thumbing through the oil stained pages of my Haynes car repair manual. It told me everything I need to know about replacing the steering column, the shock absorbers, fitting a new radiator and starter motor. The manual contained in a body of knowledge in the form of how to information about the car. Of course I could have had my own ideas about how the steering column functioned and fitted with the rest of the car. I could have relied on my instinct, added my own bits and pieces and hoped for the best. But no doubt the consequences would have been bad for me and other road users. Thankfully for the safety of us all, making a car function safely is not a matter of opinion or belief.
So in my 40s Im faced with a temperamental project rather than a temperamental car. The only official how to manuals I have at my disposal is the collection of works knows as the project management body of knowledge (BOK). Various project management institutes and associations publish their own versions of it. They all say pretty much the same thing in perhaps slightly different ways. However, there is a fundamental difference between the books that contain car repair knowledge and those that contain project management knowledge. I wonder if you've noticed.
The information in the Haynes manual is about the thing in itself the car. Alongside the technical drawings of clutch plate assembly there is a picture of the real thing. The information on the page is knowledge about the car. This is very different to the contents of all the BOKs. The BOKs have no information about the project I am immersed in. In fact, they have no information about any project I know. They seem to contain page after page of how I could conceptualise various aspects of a project. Theres information in there on how to think of a project in terms of a lifecycles. Theres information on how to conceptualise the management of risk or quality. There are ideas on the interplay of the concepts of time, cost, and quality, and how they should be considered. And so on. All of the BOKs contain ideas, concepts, and processes. These are things that can be found in the minds of a group of people called project managers. There is no information in the BOKs about the thing in itself the project. This would be like opening up the Haynes manual and finding loads of concepts and ideas that car mechanics use to think about fixing cars. Not really something very useful.
My view is twofold: Firstly, we should view the current PM BOKs for what they are, just pages of concepts that project managers use (or say they use) to manage their projects. Secondly, we need begin to create a new PM BOK that actually tells us something objective about the various types of work people face every day. What do you say?
Jon Whitty is a Senior Lecturer in Project Management at the University of Southern Queensland, Australia. On the 28th of November 2012 he will be in the UK and will be leading an interactive discussion that invites participants to challenge preconceptions about project management knowledge. For more information please click here.
13 comments
Log in to post a comment, or create an account if you don't have one already.
I was not aware much of project management. Its not commonly teaches in every university. You have briefly write on it. It would help me in my new assignment related to professional essay writing service. Project management plays an important role when are dealing with big corporations. Thanks
Thanks all for your great comments. Some unfortunately have got a bit too caught up in the whole car manual analogy. At no point did I propose that there should be a how to manual for projects. The analogy was to try to highlight that the PM BOK contain conceptsand thats it! They are not even concepts that practitioners actually use, because they are so generic (they need to be to appeal to a wide audience) that any useful detail is lost. Furthermore, and what should worry us the most, is where is the evidence for any of them? Ah we say, they are derived from best practice. But what does that mean? Largely this means that some organisation delivered a project to spec, and then told a story about how it did it and highlighted what were the factors that led to its success. Well this is not scientific at all! There is no testable evidence here, and certainly no way of showing any causal relationships as there are so many variables and confounding factors. That list of top 10 project success factors that gets passed around is, well, just a list of factors that sounds, in our culture, just about right.How about this for a bumper sticker: The PM BOKs - No Evidence, Just Popular Opinion.And Im not happy with that as a body of knowledge. Are you?Make sure you come to the We really need to talk about knowledge event at Reading on the 28th Nov.
I tend to agree that the BOK is a very conceptual approach to PM, this fits easily with how some work but not all, I find it quite hard going, but consider, I follow best practice in my project development. We already have the information you suggest, lessons learned from other similar projects, this is not in one place nor is it often formally developed but this information in my view provides a best practice approach to identifying solutions in PM. Bearing in mind projects by definition are unique the BOK provides a workable approach, however in reality, very few are truly unique. Projects can be broken to types, good practice solutions that have worked and an explanation of what went wrong with others is a strong case for another type of BOK. But we cannot be to prescriptive, or we risk losing one of the true benefits of change, vision. We all know project managers who need support and we know those that get on and develop good and some times amazing solutions with their teams, and still stay within scope and cost to provide inspiring solutions.A book of solutions may reduce PM to a Haynes manual approach where all projects and their outcomes are the same. We need to risk failing occasionally to grow and understand our needs better.I say whilst the BOK is not perfect it offers more opportunity for the amazing. Why not rename it to FOK Framework of Knowledge, as it really is just a framework for PM.
I am new to PM and to APM, but what I find useful about the BOK is that it provides a set of basic principles in a modular and expandable structure. It also comes across as not necessarily something that I would refer to on a daily basis for a specific project, but more like a checklist of concepts and ideas that I may wish to 'cherry pick' for any given project according to the requirements of the project and use them in defining the business case or terms of reference. It certainly would have been a very helpful document for me about 3 years ago when we first started to administer a 3yr programme of about 14 projects. But we were not aware of it at the time.The analogy of car maintenance was also used on me when I was deciding which pathway to PM certification I wanted to take (like I said I am new to this). From what I was told, Prince2 was more akin to "Perform oil service every 20,000 miles", whereas the APM explains why, and what could happen if you don't. I personally prefer to learn about the principles and then to use those principles - and my judgement - to make decisions. After all, you can't blame the BOK if things go wrong.
Hi Peter,New members receive a copy of the latest edition of the Body of Knowledge when they join. Exisiting members also have exclusive access to the full 6th edition content via the "Body of Knowledge+" site at knowledge.apm.org.uk.Members get a 10% discount on all APM Publications at http://www.apm.org.uk/publications.Hope this helps,Owain
Agreed, Jon.All the more reason why it is totally baffling and thoroughly disappointing that the APM considers the Bok as a revenue stream. Sell it to non-Members by all means but Members should not be milked as a captive market - aren't we all supposed to be on the same side?Then, to improve the value of Membership, by all means adopt a policy of continuous improvement with useful amendments. That might encourage substantial contributions which everyone can share.Who's going to support changes if it means further expense for the next edition?
Hi Jon, if it were possible to establish a Haynes-type manual for projects then I'm not sure it would be an environment that I would enjoy working in so much. The unique and transient nature of a project - and being delivered by people, who will always be different - means that it should be next to impossible to develop a 'project manage by numbers' solution. That said however, this year the People SIG have made a significant effort to develop toolbox 'assets' that can be applied to projects. Bringing together members of the APM community from a range of experiences and sectors, a series of development workshops have sought to produce tips, tools and guidance. http://www.apm.org.uk/content/assets The topics of Communication, Culture and Leadership & Coaching have been explored, with assets designed to be applicable in any project environment; providing exercises, models and further reading, perhaps the flip-side to the APM BoKs introduction to topics and over-arching concepts
Yes, I remember buying a Haynes Manual for each car that I owned - the now-forgotten Renault 6, the Fiat Panda, many others. It was the first thing I bought with each "new" car.The Project Management equivalent is the project template, in MS Project, Zoho projects or iBE.net, or some other project management software. The disadvantage - the project template was probably written by an amateur; the advantage - you can probably get one template from a Utility company, and another from a public consultation, and mash them together and you have a template suitable to let a utility company do a public consultation on the route of their new pipeline.In effect, the "Haynes Manuals" are there all around us, with new ones being written all the time. We don't know the quality (they aren't certified like the Haynes manuals), but they are available.Having said that, I too was disappointed with the BoK. If my own experience is anything to go by, the process was clear and commendable, and the authors spent months crafting each chapter to make sure that all interests were represented, and that the description was clear and concise. However it seems to me that all of this excellent work is not reflected in the final publication. The process stated that authors would see the proposed final edition before publication, and have a chance to reject changes. The process wasn't followed. The changes in my case dispensed with all balance, and removed further reading from some of the grand-daddies of the subject (including a FAPM) to replace them with two books by the same author (whose latest book had already been in the reading list, so there was no reason to include an earlier book).
Hi Julian Is this an appropriate analogy? Yes I think it is. And it seems to me that youve answered your own question in your bottom line statement: Manuals are important, but so are the engineers. Yes engineers are important, vitally important, but as Jon points out (and you too), their knowledge is based or grounded on the thing in itself. Engineers dont make stuff up as they see fit they dont invent their own laws of mechanics. WE DO! We make stuff upyou, me, my GM makes stuff up and acts upon it as if its some truth. We use our ideas about whats going on as if they are tangible facts and they arent.This simple little analogy has, I have to say, rocked my whole thinking about project management. Dont get caught up in the car analogy as youll miss what i think is the subtle point. The argument as I see it is that our BOK is full of ideas and opinions on how to do things and what is important. These ideas and opinions are not grounded in the behaviour or features of the things in themselves (the nature of the work and the people who perform it), they are grounded in our cultural values and over simplified concepts of the world. My take away is that our PM BOK should be better than that.
Hi, Jon.This is an interesting idea - one that points to the value of different kinds of reference works. The repair manuals you talked about are great if you happen to have the car that the manual talks about. When I go to http://www.haynes.com to look for 'the book of knowledge on car repair' or even 'the book of knowledge on steering column repair' I can't find it. What I find are thousands of books of instructions for dealing with thousands of different cars.To put it another way, each of these manuals is a collection of processes for achieving some specific result under specific circumstances. The majority of the relevant variables are known - the make, model, and year of the car, the repair you're attempting, and so on. If you have the "VW Beetle & Karmann Ghia Haynes Repair Manual for 1954 thru 1979" it won't be very helpful as you work on your Audi A4 Sedan (2008). Sure, you might glean some general principles of repairing a car, but you're going to struggle.The thing you desire - the "...new PM BOK that actually tells us something objective about the various types of work people face every day," - is akin to a manual. In software development this is called an SDLC or methodology. Other disciplines that build things (engineering, science, etc.) use other terms to refer to the same idea: a clear set of steps that can be followed the same way each time (with minimal variance) to achieve the same result.Let's do a thought experiment.Assume that a manual exists that defines the step-by-step process for implementing a new capability in a business. We'll need to be specific about the 'make' of the business, the 'model' of the capability. I think the market the business is in may be the analog to the year of the vehicle.For this discussion, I'll pick an online retailer of health-and-beauty products, that wants the capacity to accept payments in a currency they don't accept today. The sponsor of the project rifles through the online library of manuals, finds the appropriate one, and downloads it.Since a manual contains a set of repeatable processes, anyone with some basic understanding of the tools and parts related to the process should be able to make an attempt at managing the change. You couldn't pull in just anyone, toss them the manual, and say "Do this," of course. The person would need an understanding of the terminology, some ability to practice with the tools, and a willingness to get their hands dirty.In other words, we have replaced the Project Management profession with a manual and some basic education.Something isn't right here. We would need a vast array of manuals, but that's not a problem - there are many thousands of types of cars, and we have manuals for all of them. In the modern world a few million manuals would't be insurmountable (100s of business types, in 100s of markets, with 1000s of capabilities).But who wrote the manuals?You'd need someone with a clear and robust understanding of concepts that are used to manage projects. (I had to alter your statement because the role of PM has been replaced by a series of books.) Each manual could not have been compiled by the amateur we described above, just as the Haynes manuals couldn't have been written by the person who needed the manual in the first place.In the case of car repair, the information in the manuals comes from professional engineers and mechanics: people who have spent years developing the capacity to use a set of concepts to affect change. For engineers, these concepts are found in a vast body of knowledge that includes topics like "physics" and "biomechanics". For mechanics, the body of knowledge may be less formal, but definitely includes principles of automotive operation, diagnostic tests, and so on.In the case of projects, we are always dealing with a complex system of interwoven, interacting components. Unlike a process, which can be repeated to get the same result, you can't run the same project twice.Bottom line: Manuals are important, but so are the engineers.
Thanks Jon,Interesting proposition! With enough intellectual consideration, this has potential to result in a new project management paradigm. It seems that employers do want project managers to use many tools. Project management position descriptions typically include other non-specific skill sets, particularly product knowledge and experience within an industry sector. The fixation on embracing particular bodies of knowledge for undertaking project work must result in inferior project management quality. Abraham Maslow provides some philosophical insight into this one tool fixation. I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.What do you have in mind regarding the various types of work people face every day? Are you looking beyond the nine project management knowledge areas? What will this mean for the future of generalist project managers?Following with interestMichael Howard
The best lighting for smart people. Visit our site and ensure the adequacy of price . Informative and interesting which essayshave.com we share with you so i think so it is very useful and knowledgeable. I would like to thank you for the efforts. I am tiring the same best work from me in the future as well. I'll use this information to provide research paper help.
Thanks for posting this. Your blog is so interesting and very informative.Thanks sharing. Definitely a great piece of work. Thanks for your work. McdonaldsGutscheine.net