Posted on September 22, 2009 by Paul Ritchie
I saw a somewhat depressing article in this month’s PM Network about the need for project managers to get business-savvy. Not that there’s anything wrong with what Gary Heerkens writes (the article itself is here). What saddens me is what this article implies about the mindset of project managers:
- Too many project managers don’t see “business understanding” as part of their job.
- This expectation isn’t explicit enough in PM job descriptions or how PM performance is managed.
- PMs seem to want the title, but not the responsibility.
IMO, a project manager who can’t participate in business discussions can’t meet the substantive requirements of whole swaths of the PMBOK Guide. How can a project manager participate in charter, scope, and change control discussions without knowing the business? Otherwise, aren’t they really project coordinators, assistants, etc.? As Gary notes (and understates):
Basing choices solely upon technical or functional considerations means all of the critical inputs required to make the best possible decision aren’t being considered. Project managers who do not understand the business aspects of their projects are destined to make subpar decisions from time to time.
Filed under: PMO | Tagged: Business, Gary Heerkens, PM Network, PMBOK Guide, PMI, Project Management, Project Management Skills, Project Manager | 9 Comments »
Posted on May 8, 2009 by Paul Ritchie
That’s the question posed by James Brown (here). He points out that the PMBOK Guide 4th Edition no longer discusses the Triple Constraint — yes, I was shocked it was missing too! He wonders if the PMBOK Guide:
…is not a standard if it is always changing!… PMI is at risk of devaluing the PMP certification because now you have project managers certified on different sets of terms. When an organization hires a newly certified PMP based on the fourth edition of the PMBOK. they may not know the term triple constraint. A standard doesn’t have to be perfect, but a standard must be a standard to effectively serve its purpose!
In this case, I agree that the loss of the term “triple constraint” is pointless. It is a powerful way to highlight the choices that one needs to make among competing priorities. Why not elaborate the concept or point out its limitations instead of dropping it?
However, I challenge the idea that a standard cannot be “always changing.” For example, should there only be one edition of the Merck Manual or various ANSI standards?
While we should avoid change for change’s sake, project management is still trying to codify the common sense Dr. Brown mentions. We’re a long way from having a stable project management standard, IMO.
Filed under: PMO | Tagged: Dr. James Brown, PMBOK Guide, PMBOK Guide 3rd Edition, PMBOK Guide 4th Edition, standards | 5 Comments »
Posted on January 16, 2009 by Paul Ritchie
Andrew Meyer at Inquiries into Alignment provides a useful corrective to the faith that we project management types put in our industry standards and frameworks (post here). He hits on a lot of topics that are only alluded to in our project management “bibles”:
[P]rojects often pull people from different departments together to work on a project. While that is what the project requires to be successful, what does that mean for the people pulled from the different departments? Is the project of primary importance to them or is what’s happening in their department of primary importance?
Now, I believe Andrew that has set up a bit of a straw man here. I’m not sure that it is the responsibility of the PMBOK Guide or PRINCE2 to elaborate some of these topics fully (I’ll leave Agile aside for the moment). At least in the case of the PMBOK Guide, it is only a guide to the project management body of knowledge. While a guide should reference the need to ensure business alignment, only so much content “meat” can be expected from such a guide.
My take is that firms should not count on generic standards to cover some of these topics – one’s firm-specific methodology should elaborate the questions Andrew suggests (and more):
What is the business environment your company is working in?
How is that environment changing?
What is happening inside the business?
What is the state of the project?
Where does it need to go?
What needs to happen to get it there?
Filed under: Business Case, Methodology, Portfolio Management, Program Management, Project Management, Strategy Management | Tagged: Andrew Meyer, business alignment, Inquiries into Alignment, PMBOK Guide, PRINCE2 | 5 Comments »
Posted on December 3, 2008 by Paul Ritchie
My last PM Quote (here) reminded me of this PMBOK Guide issue. There’s an awkwardly phrased topic sentence in Chapter Three that gives some the impression that the PMBOK Guide intends to segregate monitoring and controlling activities in the executing process group:
The Monitoring and Controlling Process Group consists of those processes performed to observe project execution… to control the execution of the project. — Page 59, PMBOK Guide 3rd Edition
The focus on execution is unfortunate, because a lot of folks seem to stop there when skimming the Guide. Throughout the Guide — and even on this same page — we find better indications of the team’s intent, IMO:
The integrative nature of project management requires the Monitoring and Controlling Process Group interaction with every aspect of the other Process Groups. — Page 40, PMBOK Guide 3rd Edition
[A]ll of the Process Group processes would normally be repeated for each phase or subproject. — Page 41, PMBOK Guide 3rd Edition
The Monitoring and Controlling Process Group not only monitoring and controls the work being done within a Process Group, but also monitors and controls the entire project effort. — Page 59, PMBOK Guide 3rd Edition
The botched topic sentence notwithstanding, the PMBOK Guide doesn’t give us an out. Monitoring and controlling activities are needed throughout the project. There’s even a purdy picture…
Filed under: Program Management, Project Management | Tagged: Monitoring and Controlling, PMBOK Guide, Project Controls | 4 Comments »
Posted on November 11, 2008 by Paul Ritchie
Glen Alleman shoots down some of the common misconceptions about the relationship between the PMBOK Guide and agile principles (here). As regular readers know, I’m sympathetic to agile approaches, I’ve found them very powerful in the right project context, and I push to incorporate agile principles further into our own content.
Of course, if I commented on Glen’s post itself, I’d be writing “ditto” or “I agree” a lot, so I’m just going to add on a bit:
- While many agile advocates over-read the PMBOK Guide, the guide did imply a waterfall approach, especially in earlier editions (Chapter 2). I can understand the confusion or over-reading.
- The pending 4th edition does have a more sophisticated treatment of project life cycles and explicitly addresses iterative relationships among project phases. It is hardly sufficient, but it is heading the right direction.
- PMI itself is quite eager to engage agile advocates for future editions (or extensions) of the PMBOK Guide. Several Global Corporate Council members were approached about how and whom to engage in the agile (or agile-savvy) community.
- My take is that creating an Agile extension to the PMBOK Guide would be the best initial approach. If nothing else, integrating agile-oriented PMs into the standard-setting process should be easier in an extension project.
Filed under: Methodology, Program Management, Project Management | Tagged: agile, agile development, Glen Alleman, Herding Cats, PMBOK Guide, SDLC, waterfall | 3 Comments »
Posted on October 8, 2008 by Paul Ritchie
There have always been a few in-apt or questionable glossary terms included in the PMBOK Guide‘s glossary. But in particular, the persistence of the Delphi technique puzzles me. I mean, how many people actually use it? Have any of you all seen this technique used recently?
A lot of such techniques are around and all have their place. And it isn’t that I have desire to see Delphi stamped out. It just seems so out of place as something that should be codified in the PMBOK Guide.
The bottom line is that Delphi just doesn’t belong; here are four reasons off the top of my head: Continue reading
Filed under: Methodology | Tagged: affinity diagram, brainstorming, Delphi technique, Fishbone diagram, Ishikawa diagram, PMBOK Guide, PMBOK Guide 4th Edition, prediction markets | Leave a comment »
Posted on October 3, 2008 by Paul Ritchie
Scope Defintion section of Scope Knowledge Area -- 3rd Edition PMBOK Guide (Copyright PMI 2004)
When I saw the pre-release PMBOK Guide 4th edition draft, the new data models attached to each process caught my eye.
I liked the 3rd edition’s attempt to capture data and process flow. However, the approach was a bit clumsy, largely because it was done by knowledge area. To be fair, the 3rd does have a set of process group diagrams in Chapter 3 with a decent overview of the flow.
Scope Definition Process Data Model -- 4th Edition PMBOK Guide (Copyright PMI 2008)
While the big picture view those diagrams provided was nice — versions of them exist in the 4th edition — mapping the data inputs/outputs by process is more rigorous and intuitive IMHO. I was OK with the boxes listing the data I/O, but the models are much more effective visual representations of the individual processes.
I’ve provided a couple of examples of the different approaches FYI.
Filed under: Methodology, PMO, Project Management, Scope Management | Tagged: Data Model, PMBOK Guide, PMBOK Guide 3rd Edition, PMBOK Guide 4th Edition, Process Model, Project Management Institute | 3 Comments »
Posted on October 2, 2008 by Paul Ritchie
As a registered education provider for PMI, SAP gets to see pre-release drafts of certain PMI standards. And sure enough, we just got a late draft of the pending 4th Edition of the PMBOK Guide.
My first impressions were that the 4th edition was a fairly straightforward continuous improvement of the 3rd. This relatively small set of changes is in contrast to some of the big changes between editions two and three, never mind the giant leap between editions one and two.
Which is IMHO, a good thing and a measure of the maturity of the profession. As regular readers know, my take is that most of the “action” should be in managing complexity, which takes us out of the project world and into programs and portfolios. I would have been a bit worried if the profession — as represented by the PMBOK Guide project team — had felt the need to do a large-scale revision.
More on the specifics in later posts…
Filed under: Methodology, PMO, Project Management, SAP | Tagged: continuous improvement, PMBOK Guide, Project Management Institute | 7 Comments »
Posted on August 21, 2008 by Paul Ritchie
Sreejith at PM Karma takes a crack at resolving the debate about whether functional or project management skills are more important when leading initiatives. I’ll let you agree or disagree with his take directly on his post (here).
My take is that this topic is one where our friend – the much-maligned PMBOK Guide — is perfectly sound. The discussion on pages 12-15 of the 3rd Edition (Section 1.5: Areas of Expertise) lays out the basic elements that the project management team must understand and use:
- The project management body of knowledge (please note that Figure 1-2 on page 13 of the 3rd edition clearly depicts that the PMBOK Guide is a subset of the PMBOK itself).
- Application area knowledge, standards, and regulations.
- Understanding the project environment.
- General management knowledge and skills.
- Interpersonal skills.
If you’re looking to ensure that your project team has all the requisite skills and competencies, you could do worse that building a simple checklist derived from Section 1.5 of the 3rd Edition. And yes, it is the project team, not the project manager.
Filed under: People Development, PMO, Program Management, Project Management, Skills vs. competencies | Tagged: domain knowledge, general knowledge, PM Karma, PMBOK, PMBOK Guide, Sreejith Kesavan, team building, team composition | 3 Comments »
Posted on August 4, 2008 by Paul Ritchie
In my comment I wrote “it’s funny,” but it’s actually sad that Carl Pritchard has to defend the PMBOK Guide when he conducts PMP prep classes (post here).
What good is a certification that says that every process needs to be followed every time in a consistent fashion? It sounds very good to me. And it also provides a jumping-off point to take steps toward that perfect world.
Of course I agree. But IMO, Carl is softening the blow when he accepts his students’ assertion that PMBOK practices represent the “perfect” world. Of course, not every process is executed perfectly in the “real” world, but as Carl says, don’t we want to insist on these basics?
Senior management writes and signs chartering documents; Procurement departments deliver what we ask for …; Human Resources departments provide skilled resources…; Management understands that range estimates are more honest and realistic than single-data-point estimates.
Aren’t our projects are more successful and our lives easier when we insist on such fundamentals of project management? We need to ask ourselves if we have a problem with the practices, or a reluctance to deal with the conflict and effort required to insist upon them.
The latter is the real issue. I doubt that folks still really believe that an industry standard that comes out every five years represents best practices or the “perfect world”. If they so, they’ll be in for a rude surprise w/r/t customer and employer expectations. For our organization, PMBOK-based practices are simply the foundation for our minimum standards. The minimum…
Filed under: Leadership, Methodology, Organizational Change Management, People Development, PMO, Program Management, Project Management, Project Success Factors | Tagged: Carl Pritchard, PMBOK Guide, Project Connections | 4 Comments »