Is the PMBOK® Guide a guide to the project management body of knowledge or is it a guide to the body of knowledge needed to manage a project? The traditional view is the PMBOK is special and the knowledge uniquely project focused; but is this true?? Consider these two challenges:
Challenge 1: name ANY process area that is unique to project management. Everyone plans; quality is ubiquitous, cost management and time management are practised by every home keeper, scope is fundamental to supplying anything etc.
Challenge 2: name ANY area of the PMBOK (or any other PM standard) that develops value without human interaction. The most perfect schedule is completely useless – has ABSOLUTELY NO VALUE AT ALL – unless its contents are first communicated to the right people and secondly, those people buy into the idea they need to implement the schedule and work to achieve it.
If we assume PMBOK = project specific body of knowledge the contents are likely to drop to a very few basic processes such as EV, WBS and maybe scheduling (but remember Henry Gantt was involved in manufacturing, not projects…).
I would suggest a reframing is needed PMBOK = the knowledge needed to manage a project successfully! This means allowing a range of useful management processes into the PMBOK such as motivation and leadership. Let’s face it, technical skills are the provenance of technicians. People skills are the provenance of management, and in case anyone has failed to notice, the person leading even the most technical of projects is called a project manager!
Numerous studies have shown that the core skills for any successful project manager are the ability to develop a successful ‘high performing’ team, and communicate effectively to influence key stakeholders. These are soft skills and very hard to achieve competence in. ‘Soft’ does not mean easy. Hard skills have an easy to learn framework that does not change. The ‘soft’ in soft-skills refers to the need to adapt their use to every new context. For more on this see: Confronting soft Skills
This reframing is important because well over 90% of project failures can be directly attributed to people issues, including headline disasters such as the original Hubble Space Telescope launch and Challenger (read the reports on the NASA web site). For IT read any of the Gartner reports on project failure.
The simple fact is we can continue to underplay the importance of soft skills because they are not ‘project specific’ and continue to see well over 50% of project fail every year or we can recognise the core elements that characterise projects are totally useless without people and start giving stakeholder management and the soft skills implicit in successfully managing them the prominence needed in the body of knowledge needed to successfully manage projects.
What do you think??
Pat Weaver
Lynda Bourne
Mosaicproject's Blog 
Hi Pat,
I am currently assisting a project initiation and our organisation has its own PM methodology – and I found myself referring to the PMBOK today for advice about a particular aspect of cost accounting. Your reframing puts into words exactly what I have been thinking for a while.
Thanks
David
Hey Pat, that’s one of best posts I’ve read for some time now. The key to successful projects is not the hard engineering but rather the soft human skills. It is the people who get projects done. Anyone can learn how to do EVM and WBS, that’s easy. The real complexity is in managing people.
Cheers, Shim.
Both the Hubble mirror and Challanger were PROCESS failures. Read the Mishap reports.
Had Hubble followed the process of Operational Test and Evaluation (OT&E) has defined in (NPR) 8705.2A, the mirror would have undergone integration test and evaluation.
Had Thiokol pushed back on the Marshall Space Flight center management and insisted – according to contract – on a Safety and Mission Assurance stand done, the “mishap” would have not occurred.
The right people are necessary but far from sufficient for success.
IT is another world unto its own. No formal engineering discipline, abhorrence of process and procedure and all that “emergent” nonsense on enterprise systems, results in well deserved failure.
We work a 600 million $ software development program, a $300M bioscience program, a $100M helicopter software intensive program.
we’re usually over budget and behind schedule, but it is never a surprise in the way an IT $200M right off of ERP typically is.
It’s people, process and tools. But it starts and ends with process on all non-trivial projects. People without process is a “beach party.” This is lost on most project where they put people first. Establish the process, hire people capable of executing the process as well as executing their technical role and you’ve got a fighting chance at getting closer to success.
The official US DoD term is “improving your Probability of Program Success (PoPS)”
Both Charles Pellerin, manager of both the Hubble program and the repair program and Ed Hoffman were in Australia recently at the PMOZ conference where I was privileged to spend time with them. Their view was the root cause of both system failures can be traced back to a team culture that suppressed important information – people could not be heard. Charles book, ‘How NASA Builds Teams’ and the underpinning methodology flowed out of these problems.
Process and people issues go hand in hand. Atul Gawande’s new book “Checklist Manifesto” is really about process discipline. Discipline to follow the process often breaks under pressure, but pressure situations are where we need discipline most. Leadership is critical. Appropriate tools, such as checklists and process scripts, are invaluable.
Successful projects are the template for future success. “Show me a credible plan to do that again.” To do it again, you must understand what you did both right and wrong. That implies a process. Our selective memory focuses on failures. Learning from failure is important, but good results, 100% defect yields, 0% infections, etc are important too. It doesn’t happen by accident. Good people following good processes make it happen. Having good people and good processes is no accident either.
Pat and William,
The Perrlien book is a great start. But as he explains the process failed first. People choose not to follow the process. That is a meta-process failure, since the process itself did not alter the senior management of the “skipped step.”
William has hit the point. The “check list” paradigm has now entered other domains.
This is actually a meta-problem in many domains. In the end though it has been shown that “process rules,” then people, then tools.
You need look no further than the commercial airline cockpit. The United crash in Sioux City was the turning point. Relying on team and people alone was not sufficient up to that point. The outcomes was to train people to follow a process of cockpit management. Both are needed, but it starts with process.
I think the situation is rather more complex, we are in the space of closely coupled systems and ‘normal accidents’. In NASA’s case the view of Ed and Charles seemed to be that the root cause of the disasters was the shift in focus of the team leaders from engineering excellence to budget and schedule with the inevitable consequences on the way their teams behaved. In the airline situation what matters most, on-time departure or safety? Both are important.
The other area is the intelligent use of check lists and process compared to the blind obedience to process. Lynda’s post on ‘Command or Control?’ picked up on the concept of ‘auftragstaktik and bounded initiative’. You do not employ first class brains in a team for them to merely follow processes. The people are part of a complex system and the system needs to be sufficiently flexible to deal with changing circumstances effectively.
Glen, I’ve read and re-read your comments and find them somewhat puzzling. Your process centric approach is completely understandable as, obviously, lack of process would inevitably end if failure. The point Pat was attempting to promote is that the right process is necessary but far from sufficient for success (which is a play on your statement that “the right people are necessary but far from sufficient for success”).
The examples used throughout this post seem to only strengthen the conclusion that processes on their own are not a guarantee to success. The two examples you bring upfront, regarding the Hubble Space Telescope launch and the Challenger clearly indicate that the process existed but was not followed. You describe this as a meta process failure but I would argue that similarly (and not incorrectly) it could be described as a people’s issue.
If I were to form my view of your project management philosophy based on your comments alone I would have concluded that nothing matters but process. Establish the right process and everything else will sort it self out. The point Pat was trying to make was that there is a considerable people’s side to managing projects, and that component needs to be managed as rigourously and effectively as the processes they are asked to follow. You wouldn’t disagree with that, would you?
Shin, there never a guarantee of success. start with the process add the right people, the probability of success can be increased.
The people failure is a sub-system failure in the systems engineering context. All NASA and DoD work is Systems Engineering. The DoD 5000.02 and equivalent NASA procurement starts with systems engineering. Rarely are the NASA or DoD agencies or units doing the work. The vast overwhelming amount of the work is done by contractors.
The systems (Hubble etc.) are “Acquisition” program from the POV of the agency.
There is considerable people side of course. It woudl be foolish not to understand that. But the people side is a sub-system. Not the starting point.
People come and go, contractors are replaced, subcontractors are replaced, even whole agencies are replaced. Only process remains across those changes.
Those programs and the programs we work are not about the individuals, they are about the team of individually holding each other mutually accountable for a shared outcome. the “accountability” starts and ends with the process artifacts, since in many situations we are not in the same room with the customer, not working on individually selected work, bit working on “flow down”assignments.
Much like large construction the Master Schedule and the work instructions drive the project.
Absolutely the people must be the right people, but they FIRST must have a process – of some kind – to follow, be assessed against, be guided by, and be participants in to improve the process.
This is a prime example of the “world view” differences between the agile small team software developer and the $1B program manager working for anagency doing the procurement. Both world views are validate, it’s just a matter of where the “product” (Shuttle or Hubble) “see” this. This means from the agency PM, she sees it top down. From the top its PROCESS.
Shim,
Here’s another thought. If people, process and tools are the simple minded parts of the activity, and they interact in some defined way – ignoring for the moment the non-linear non-deterministic ways they interact.
When a person or a tool misbehaves the process is distributed. In the systems engineering and systems architecture (see Rechtin’s books on systems and meta-system and the early MIT work that now dominates the systems of systems paradigm) this misbehavior is “managed” by a process component of the system.
It is the separation of the process from the people and tools “during execution” that is the key to the system of systems paradigm for certain kinds of systems and projects.
There is a spectrum where dominance of one of these three elements takes place. This is the core gap in the agile discussion. The people-centric (People over processes) fail to acknowledge the “meta domain” in which that world view is effective and which is it not.
Building and flying Hubble and Shuttle, or the replace we work on, or the other “mega” projects we work (mega compared to small team IT), process and the “control systems” provided by the processes dominate the success factors.
It’s like a dance – you can’t waltz with someone doing the tango! The processes and procedures define the steps and the tempo. After that it is up to the people to create magic (Fred Astaire and Ginger Rogers), deliver an elegant and effective performance (the majority) or like me demonstrate two left feet and no ability….. But also like dancing, it is nearly impossible to start without some training and capability and most people improve with encouragement and practice. The role of leadership is to provide the motivation and encouragement for the rest of the team to improve and excel.
Happy to dance, just as soon as someone is able to explain this to me:
http://www.wired.com/dangerroom/2010/09/revealed-pentagons-craziest-powerpoint-slide-ever/.
It’s either Rap or a secret new show that Michael Jackson was planning…..
Great analogy Pat. Even more so with “Dancing with the Stars.” The judges (DCMA, DoD, NASA) know what a “10” is for the Tango. No about of convincing from the dancers is going to make it better if they don’t know what the “standard of measure” is.
Pat and Shim,
The Wired post is classic “the uninformed leading the ignorant.”
The diagram is not a PPT, it is a map of the DoD 5000.02 procurement guidance. This is the process used to procure materials for the DoD. Most programs we work on in Milestone C.
go here for source documents
https://ilc.dau.mil/
when the site complains about the cert, go to the upper bar and install the certificates (doesn’t work with Chrome).
This is one of the topics (Wired and many other supposed authority voices we hear in the community posts) where they are fully uninformed about the complexities and issues of buy multi-billion $ weapons systems.
You can order the printed version. also on the back is an explanation of the PROCESSES. As well, there are some other sites with nice detailed step-by-stpe processes for each of those Program Events in between the Decision Milestones
http://www.navair.navy.mil/kms/41g/
is one.