Those of you who, like me, have been in Information Technology for a long time, will probably fondly remember Tom as one of the evangelists of measurement and control in software engineering, which appeared to me at the time to have its roots in Fredrick Taylor’s, “Principles of Scientific Management”. And even if you haven’t heard of Tom, you may have heard of his early book, “Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982), or failing that, you may have heard his catch phrase, “You can’t control what you can’t measure,” or some variant thereof.

No, no, and no

Tom’s focus on measuring and controlling will probably strike a chord with many project managers, and it may also strike you as odd that someone who became famous advocating tight control, is now decrying it.

In his article he says,

“In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.”

As you read through the article he reveals that the cause of his discomfort is the implication that “metrics are good, more would be better, and most would be best.” He then goes on to say that software development is by nature somewhat imprecise, and therefore difficult to measure and control in a meaningful way.

Those of you who are familiar with PMBOK (a guide to the Project Management Body Of Knowledge) will know that the definition of a project (irrespective of the discipline – engineering, IT, or whatever) is:

“A project is a temporary endeavour undertaken to create a unique product, service or result.”

And right away you see what Tom is alluding to, it’s the very “uniqueness” of projects that make them slippery little devils, and the only thing you can predict with certainty is that you can’t predict anything with certainty.

Ok, up to this point I’m pretty much in agreement with him

Tom goes on to say that many projects have succeeded without much control (citing the creation of GoogleEarth and Wikipedia), and it’s around about here that it was MY turn to feel uncomfortable, as I could sense a “throwing out the baby with the bathwater’” approach, which we find soon afterwards where he says, “Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost.”

There is a often quoted statistic that 75% of all IT projects fail, which to me implies that for each large project that succeeds without measurement and control, three or more will fail! If you “manage” one of the three-or-more failed ones, you will be reviled for failing to measure and control your project, and if you “manage” a successful one, it will not be attributed to your abilities as a project manager, for the same reasons.

So how does Tom suggest we run projects?

“So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.”

The problems that it see with this approach are

“control the time and money”

But how on earth do you control time and money without measurement (and I thought we were doing away with controls)? The proper management of these resources requires the techniques of Earned Value Management, through which we can work out were we are, where we should be, were we will be in the future (if we continue at the current rate), and how to bring the project back on track.

“You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product.”

As a project manager you are responsible for change management, team building, morale and buy in, among many other things. The main tools in your PM toolbox include, painting the big picture/imparting the project vision, showing people where they fit in, their importance to the project – and providing information on what’s expected from them, and when, and how they are tracking against expectations. I believe that keeping important things secret from even the team leads, then springing a surprise deadline on them, will have the reverse affect and lead to missed deadlines, lower quality and considerable stress.

Most people work best when they have a deadline to aim for. Imagine athletes competing in a race and being instructed, “I’m not going to tell you the number of laps that you have to run. It’s somewhere between 2 and 50 – but I’ll rush out to signal when there’s one more lap to go! And there won’t even be a clock to look at” How many think these athletes would perform at their best under these conditions?

“Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value”

But what is meant by “their relative value”? You see the “value” of a piece of work usually means “its importance in relation to completing the project”, rather than some sort of monetary value. But the only way to truly know the importance of an activity or deliverable in relation to completing the project, is through some form of critical path methodology, which of course is based on measurement and control.

My comments may seem a little harsh, but I’m afraid of a return to the “bad old days’, when project “management” just meant doing “stuff” reactively and repeatedly, in the hope of a satisfactory outcome.

Keeping the baby

The PMBOK is not prescriptive, it tells you what you should know as a project manager, rather than a step by step guide. I.e. it is a framework, rather than a methodology. And you will read all through PMBOK that not all methods, tools and techniques are applicable to all projects, or should be applied to the same degree. This means that using your experience as a project manager, you need to decide the type and level of  measurement and controls and so on, required for the successful completion of your project, and regularly review their use.

Jim Owens PMP

Jim Owens PMP

July 2009

A better mousetrap

 Projects and Strategic planning

Although this may sound a little obvious, projects must have been chosen for a reason, and projects performed in organisations are usually strategic, that means they contribute to the strategic plan of that organisation.

If you are unfamiliar with strategic plans, you can think of them this way:

An organisation should have a Mission Statement and a Vision Statement. The mission statement is a declaration of where the organisation is at the present (or at least, where it was when they drew up the mission statement), and the vision statement is a declaration of where the organisation intends to be at some stated time in the future.

For example, a mission statement for a small software company might include,

“We are a software house that provides Finance and HR software for the leading banks and building societies in Sydney, Australia…”

And the vision statement could include,

“Within three to five years we will be the Finance and HR software provider of choice to 75% of the leading banks and building societies across Australia…”

We could represent this by the following diagram

Mission in relation to Vision

In order for the organization to move from where it is now (its mission) to where it hopes to be (its vision) the organisation must develop and execute a strategic plan, a coordinated series of steps, to achieve the vision, and each one of those steps will be one or more projects.

Strategic plan is a stairway from mission to vision

The everyday operations of an organisation cannot achieve the vision; only projects can do that. Why is that? It is because operations just maintain “business as usual”, i.e. the mission.

And if management authorise projects that are not on the strategic plan, they will not take the organization to where it wants to go (i.e. the vision).

But in order for a project to be placed on the stairway, first it has to be selected, and the areas that they usually arise from are:

1. Market demand (e.g. a survey strongly suggests that the public would like a stronger-smelling cheese)
2. Strategic opportunity/business need (e.g. with stronger-smelling cheese on the market, mice are multiplying, so a company authorizes a project to build a better mousetrap)
3. Customer request (e.g. develop mouse-resistant packaging for their line of strong-smelling cheese),
4. Technological advance (e.g. new photocell chip will be used to develop electronic mousetraps that distinguish between friendly, white pet mice and ferrel brown ones), and
5. Legal requirements (e.g., a pest exterminator company authorizes a project to establish guidelines for the handling the dead mice, which have become toxic after eating the cheese).

Program and Portfolio

Collection 1                                      Collection 2

Programs and Portfolios

There are benefits to be gained by grouping projects (and other related pieces of work) together. For example they can be managed in a coordinated way, resources can be balanced between them, there can be better communication across them, and clearer oversight by senior management and so on.

PMBOK defines a  program as “a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually”.

So we can see from our diagram above that the projects in collection 1 are related, and so could be managed as a program, similarly, the projects in collection 2 are related and so could be managed as a program.

But there are benefits to be gained by grouping together projects that may or may not be related, and such a grouping is referred to as a “Portfolio”, rather than a program. For example if the organisation where to manage collections 1 and 2 together (or any parts thereof) this would be called a portfolio.

The Project Management Office (PMO)

PMBOK tells us that a project management office is “an organizational body or entity assigned various responsibilities related to the centralized and coordinated management of those projects under its domain. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of a project.”

In some organisations the PMO mutates into a project management “elite”, who view their role as PM SWAT Police, and they boss the “ordinary” project managers around, audit their Gantt charts, and so on. But getting back to basics, while there may be some elements of the above, the real intended function of a PMO is to support the organisational project efforts of and organisation and their primary role is to support the project managers.

PMBOK tells us that they can support the project managers in a variety of ways which may include, but are not limited to:

• Managing shared resources across all projects administered by the PMO;
• Identifying and developing project management methodology, best practices, and standards;
• Coaching, mentoring, training, and oversight;
• Monitoring compliance with project management standards, policies, procedures, and templates via project audits;
• Developing and managing project policies, procedures, templates, and other shared documentation (organizational process assets); and
• Coordinating communication across projects.

For further information, see PMBOK 1.4.4 “Project Management Office”

Jim Owens PMP

Another trap for the unwary

Jim Owens PMP

A lexicon

A lexicon is a definitive list of words and their meanings. It’s similar to a dictionary, but in the case of a lexicon it’s limited to a particular body of knowledge (BOK). Lexicons are invaluable, to us in Project Management, just as the various other lexicons are essential everywhere else that a BOK exists, e.g. to practitioners in Information Technology, medicine, etc. Law tends to be out on its own a bit, because they seem to need a book to define each word, and no two lawyers seem to agree on anything.

The main purpose of a lexicon is to ensure that people who work in the same BOK (or are otherwise stakeholders of it) have reasonable certainty that when they use a particular term, other people who share that same BOK will understand exactly what is meant.

Clarity of terms is vital to a successful outcome in any professional field. Say for example, you are training in medicine, and attend an interview at a hospital. Then if a doctor on the interview panel says, “Please show us your testimonials,” you do not seriously embarrass yourself.

A thesaurus on the other hand, is a book that lists the many alternatives to a word (I wonder why there is no other word for “thesaurus”?). It lists words similar to each other in meaning, usually giving synonyms and antonyms, and is often used for cheating at crossword puzzles.

Of course a lexicon is only one of the tools we use in our profession, it is not sufficient in itself, as we need the knowledge to apply the words. E.g. last week I bought a PMP (don’t look at me in that tone of voice, I mean a Portable Music Player) and the manufacturer in China had obviously used just a dictionary to translate the user manual, so it lacked some of the knowledge required for English communication. Here are a couple of excerpts, directly from the user manual,

• “When a battery uses up almost, diagram the mark is central to change into the blank, at this time should on time recharge”
• “For example the name the song is ‘Pretty Boy.mp3′” – no comment
• “Any of the upgrading error can make the player can’t work. You should lock the user manual carefully. This operation is fit to people who have certain foundations of operation computer”. Yes I think locking the user manual is a good idea for some people (I think they mean “look”)”

The creation of a project management lexicon, was one of the goals in creating the original PMBOK. This has been largely successful (however they have a different word for it, they call it a glossary).

I say “largely” successful, because distilling the meaning of a recent BOK is never easy. Medicine for example has been around for thousands of years, but “modern” project management has been in use for a little over fifty years. The “youthfulness” of our profession means that significant groups of practitioners, all under the general heading of “project mangers” hold differing views on the meaning of many terms and concepts.

One of the areas this shows up in PMBOK, is the dual meaning of the word “phase”

Phase 1: the Project Lifecycle phases

The following diagram is from the PMBOK Fourth Edition (PMBOK) and shows the typical stages that a project might go through.

“A project life cycle is a collection of generally sequential and sometimes overlapping project phases whose name and number are determined by the management and control needs of the organization or organizations involved in the project, the nature of the project itself, and its area of application. A life cycle can be documented with a methodology.” PMBOK page 15

Figure 2-1. Typical Cost and Staffing Levels Across the Project Life Cycle

Figure 2-1. Typical Cost and Staffing Levels Across the Project Life Cycle

So here we see a typical project life cycle (not to be confused with a Product life cycle, defined in the same chapter, on page 18), and PMBOK reminds us that all projects can be mapped into this four-phase model. The phases are:

1. Starting the project,
2. Organizing and preparing,
3. Carrying out the project work, and
4. Closing the project.

Phase 2: Project Phases

So far there are no problems, but note well section 2.1.3 Project Phases, beginning on page 18.

Because, although we are still in the same chapter of PMBOK, these phases are NOT the same as the phases defined a couple of pages earlier. These phases are in effect, mini-projects within larger projects.

A project phase can have its own scope statement, WBS and so on, just like a regular project, and they are used to break down a larger project in more manageable chunks.

Your project may be to develop a completely new car for example, so you might initiate one project (a phase) just to perform the research on engine type to be used. Another mini-project (phase) may develop the actual engine, as a result of the research from phase 1. Another phase could be to develop the electronics, and so on, but all under the control of the main project.

Each project phase typically has a single deliverable that feeds into the main project. In fact, some large projects consist of a series of phases, the output of each phase being the input of the next. The completion (or failure) of a phase can also be a time when a decision is made whether on not the overall project should continue.

And just as with regular projects, the lessons learned and other Organisational Process Assets, should be recorded for the phase.

I hope you are not too fazed by all this

Jim Owens PMP

July 2009

Jim Owens PMP

Baselines

The Quality Baseline has gone in this edition, but greater emphasis has been placed on the scope baseline (comprising the project scope statement, the WBS and the WBS dictionary.

Life Cycle needed work

If was felt that the Third Edition Life Cycle and project needed some rework and further explanation. This has been addressed in Chapter 2, where you will also find in-depth information on types of project stakeholders.

Lite process descriptions

Process descriptions at the start of each process have been slimmed down, in many cases to one sentence. This makes them easier to understand, and they are repeated at the beginning of the Knowledge area chapter, so you don’t have to flip back to read them.

Note this one though:

6.4 Estimate Activity Durations has changed from “Estimating the number of work periods” to “Approximating the number of work periods”. Yes folks, it’s all about consistency J

More graphic detail

More graphs and charts have been added to Chapter 8, Cost Management, and more detail on the cost of quality.

Preliminary Scope Developments

The “Develop Preliminary Scope Statement” process has been merged into the “Define Scope” process, so Integration Management has gone down to 6 processes. That’s fine because it’s such a lightweight operation that it doesn’t need its own process. Personally I think it really belongs in Integration Management, but it will do no harm where it’s been moved.

Call Collect

A new process that they call “Collect Requirements” appears where “Scope Planning” used to be. It doesn’t replace it per se (as I have seen other authors claim) as it has a different function.

The main outputs of this process are the Requirements Management Plan and the Requirements Traceability Matrix and Requirements documentation.

Welcome back PERT!

In the Third edition, Three Point Estimating – a simple average of Optimistic, Most Likely, and pessimistic estimates i.e.:

(O+M+P)/3

replaced PERT estimates, a weighted average, whose formula is:

(O+4M+P)/6

so that meant that PERT dropped off the exam.

The optimists thought it was gone for ever, but the pessimists thought it was 4 times most likely to return.

The pessimists were right! In the Fourth Edition, the formula for PERT is explicitly stated, and it is also compared with Three Point Estimates, so that means PERT could appear on the exam again. So learn the formula, it’s very easy and could possibly mean an easy exam point (or three).

Although the Third Edition Glossary said that the Three Point Estimate could be used for both cost and time estimates, it appeared only in Time Management. In the Fourth Edition, Three Point Estimating, has been added to Cost as well.

Note that in both Time and Cost chapters it now appears as a “Tool & Technique”.

Performance Anxiety

The Control Costs process now has TCPI (To-Complete Performance Index) explicitly as a Tool & Technique. I know I’ve explained this concept a number of times on PMHub, and it appears in exam questions, so it’s good to see it in described in PMBOK. This means that it’s something CAPM’s need to know about as well.

TCPI is “the calculated projection of cost performance that must be achieved on the remaining work to meet a specified management goal”.

Inactive WBS?

In Time Management, Define Activities, at first glance it looks like the WBS, WBS Dictionary and Project Scope Statement do not appear to be inputs, yet they are essential to the process.

The reason why they do not appear to be there is because now they are now rolled up in the Scope Baseline.

This highlights the importance of knowing what the Scope Baseline is for the exam.

Not Approved

One area that does give me problems though is the removal of Requested Changes from the Define Activities outputs, I believe it should be there, but for the exam, know that it’s not.

And if you look at the next process – Sequence Activities – you will notice that is no longer has “Approved Change Requests” as an input.

Stakeholders

The previous “Communications Planning” process has been split in two, “Identify Stakeholders” and “Plan Communications”.

Identifying the project stakeholders was implicit in the old Communications Planning. Although it doesn’t seem sufficiently complicated to warrant its own process, it is important and so highlighting it in this way will do no harm.

This process increases the process count in Communications management to five.

The process “Manage Stakeholders” has been replaced by “Manage Stakeholder Expectations”. This makes sense insofar as managing stakeholders is like herding cats, you are not really managing them stakeholders, you are managing communications with them, to reduce surprises and shocks. Additionally, the process has been moved to the executing group, to reflect its proactive nature.

There’s an interesting change in 10.4 Manage Stakeholder Expectations (nee Manage Stakeholders). Dealing with issues is included in this process (as it was previously), and as proof, you can see “Issue log” as an input. But where are the resolved issues recorded?

In PMBOK Third Edition, “Issue log” was also an output.

The answer lies in the accompanying flow diagram. – the Issue log is included in “Project Documents” (as is the Change log). But this appears to detract from the goal of consistency, i.e. project documents listed explicitly as inputs, but implicitly as outputs.

Change for change sake?

You will see minor word substitutions here and there that seem to changed for the sake of change; for example, the definition of Communications Management has changed from

“…includes the processes required to ensure timely and appropriate generation, collection, dissemination, storage, retrieval, and ultimate disposition of project information.”

To:

“…includes the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information.”

Hard to spot, isn’t it!

From a project management point of view it makes little or no difference, but from an examination point of view (which is arguably why most people read PMBOK) it does make a difference to those who have studied PMBOK Third Edition, who will be examined on PMBOK Fourth. Because at times PMI will ask questions on key definitions, where four definitions with very similar wording are presented, with one being correct of course. But if minor changes have been made to definitions that you have memorised, it makes the question harder.

Why they changed “dissemination” * to “distribution” is a puzzle, but as I said, it’s only exam contenders, who cut their teeth on PMBOK Third, need to worry.

* Dictionary: Disseminate, “To distribute or spread something, especially information”

Procurements section contracted

Chapter 12 Procurement, has contracted from six processes to four, and removed explicit mention of “Contacting” in the process names.

The four processes are now:

1. Plan Procurements,

2. Conduct Procurements,

3. Administer Procurements, an

4. Close Procurements.

The concept of Teaming Agreements is introduced. Essentially these are temporary legal contractual arrangements between parties or entities for the purpose of harvesting an opportunity.

The wording surrounding Teaming Agreements in PMBOK is sufficiently strong to make me believe that you will be tested in them in the exam.

Conclusion

In all, the PMBOK team at PMI has done a great job, and PMBOK Fourth Edition is a very worthwhile update to the previous edition. The improved consistency, clarifications and additions (soft skills, etc) are all very welcome.

May the Fourth be with you!

Jim Owens PMP

Jim Owens PMP

I’ve just returned from Mars, and so I thought it’s time I had a look at PMBOK Fourth Edition.

Iron ore mine Flat-pack truck. Photo by Jim Owens PMP

Actually I was at an Iron ore mine in Western Australia. An Artist friend went there to paint for a few weeks last year, and she sent back an email:

“Painted some great pictures, but please send LOTS more red paint!”

How PMBOK has changed over the years! I first started studying PMBOK for my PMP exam early in 1998, using the PMBOK 1996 version, which I still have by the way. PMBOK 96 was of course a quantum leap forward on the first edition in 1987. And then we had the 2000 edition with quite a few more changes, then 2004 saw another quantum leap with the “Supersize Me” Third Edition.

The Fourth Edition makes a lot of changes that should have appeared in the Third Edition – so few surprises with these!

Many of the changes are not major, and so this could not be classed as a quantum leap again, which is what one would expect because the PMBOK has matured to a stage when further major rewrites are unlikely.

Having said that, and despite advice you might read elsewhere (about the changes not being many) don’t be caught napping, there are a stack of changes in this release, and a lot more than you might think at first glance.

In fact I would expect that someone with a good knowledge of PMBOK Third edition would still need to spend quite some time re-learning enough to pass the new PMP/CAPM exams, and there are many traps for the unwary.

This means that I might have to redo all my Exam Tips for PMBOK Fourth Edition L

And as noted below, there is no period of grace with this changeover; after the change-over date you will be examined on Fourth Edition.

Freeloaders

As with PMBOK Third Edition, financial PMI members can download the new PMBOK free from the PMI.org site. You still can’t copy and paste from it (can’t understand the logic behind that) but at least you can print it, which is a big help, because despite all the advances and advantages of computers, people still need paper copies too, to help with studying..

Maybe the Kindle reading device will change that – if someone wants to give me a free kindle, I’d be happy to test it J.

Warning: Don’t be tempted to give a copy of your e-PMBOK to your friends, as the PDF file will be “watermarked” with your identity and it requires your PMI password each time you want to open it.

There’s no such thing as a free CD

On the slightly negative side, PMI no longer seem to send out PMBOK on a CD ROM to members, so if you have a poor Internet connection, or don’t know how to hack into your neighbour’s wireless Internet, or forget your PMI password, it could take a while for you to obtain a copy.

The times they are a-changing

During a leadership group meeting with PMI over a year ago, they assured me that the exams would not change until 2010, but in fact they are changing in 2009.

The change to the exams happens on June, July and August:

PMP 30 Jun 2009

CAPM 31 Jul 2009

PMI-SPSM 31 Aug 2009

PMI-RMPSM 31 Aug 2009

PgMP 31 Aug 2009

Important: Unlike the change to PMBOK Third Edition exam in 2005, all exams this time will switch to PMBOK Fourth Edition on the set dates – no exceptions!

So if you take an exam after this date, you will be tested on PMBOK four.

And if you fail a Third Edition exam, you will have to re-sit a Fourth edition exam, if it occurs after these cut-off dates.

The Changes

And now to the actual changes. As I’ve already mentioned, a lot of the changes are intended to clean up the Third Edition, and give it the same look and feel across the various sections (which is what they claimed they had done in the Third Edition).

The PMBOK has always suffered from the various sections being produced by different groups, who didn’t seem to communicate as well as they should. But the demarcation is much less obvious this time.

Other sources suggest the changes are small – don’t believe it, I’m updating my training course at the moment and almost every slide is changing. There are subtle wording changes everywhere, to improve readability (which it does, in most places) but all these changes translate to changes in exam questions too.

When people speak of the changes being relatively light, that is true from the perspective of a practicing project manager using PMBOK in the course of business – but they are not that minor from the point of view of someone studying for the exam.

The biggest changes may be for CAPM candidates, because topics that were examinable just for PMPs, are now fair game for the CAPM exam too, as a CAPM can be examined on anything in PMBOK.

Other attempts to improve readability fall flat IMHO, and others muddy the waters, such as the wording in “Create WBS”. PMBOK has always struggled with the WBS, which is essentially a very simple concept, and parts of the Fourth Edition seem less clear than the Third.

Project, Programme, Portfolio

Chapters 1 and 2 of the new PMBOK have been aligned with the Standard for Programme Management: 2^nd Edition and the Standard for Portfolio Management: 2^nd Edition (you will probably see these chapters change again in the Fifth Edition).

These changes, along with further elaboration on projects, programmes and portfolios (and their respective managers) mean of course, you can expect questions on the differences between projects, portfolios and programmes.

Go with the flow

The hard-to-understand process flow diagrams have gone, and in their place a data flow diagram has been inserted before each process.

In Order

PMBOK Fourth has attempted to be more consistent with sequencing inputs and outputs (this should not affect the exam, as just the actual inputs and outputs are examinable, rather than their order).

For example, when a process has EEF (enterprise environmental factors) and OPA (organisational process assets) as inputs, these appear last in the list. I think I would have been inclined to place them first (as you need to consult them first), but as I said, this does not impact the exam.

The Sextuple Constraint

The classic project management triple-constraint (scope, cost, schedule, or variations thereof) has been supersized as well, with the addition of budget, resources and risk (maybe you can remember it by “Super Sized Cheese Burgers Risk Rotundness” J).

This change makes sense from a theoretical point of view, because the triple constraint was too simplistic, and you will need to remember the list for the exam.

Depicting these multiple constraints graphically could be fun though, because previously we had a cute triangle – but what sort of diagram would you use now, and would it have to be 3-dimentional.

Arrows have no point

The venerable Activity On Arrow (or Arrow Diagramming Method) has finally gone. I think PMBOK finally realised that John Fondahl came up with a better method in 1961, i.e. PDM. And accordingly, AOA is no longer a Tool & Technique of “Sequence Activities” in Time management

Also gone are the conditional diagramming methods, GERT and Systems Dynamics. If you don’t know what they are, don’t worry – they’ve gone.

Do-Stuff

Process names have been standardised on “verb-noun” format, this is a welcome change because consistency makes it easier to remember things. For example, “Risk Identification” becomes “Identify Risks”, “Performance Reporting” becomes “Report Performance”, “Scope Definition” becomes “Define Scope”, and so on.

So if you see something in the exam that looks like it might be a process, but it’s not in “verb-noun” format, then you’ll know it’s not a process. But of course going from the Third Edition to the Fourth, you will have quite some relearning to do.

Undercover Inputs

Another change to the inputs that WILL impact the exam is that the Project Plan will no longer be shown as an input to any planning processes.

I think I can see why they have done this (although I don’t agree with it). I normally advise students not to memorise lists of ITTO’s (Inputs, Tools, Techniques, Outputs) but rather, understand WHY they are there – but this change makes that method a bit more difficult.

The Project Plan however remains as an input to monitoring and controlling processes. The Fourth Edition team was charged with improving the consistency of PMBOK, but in this instance I believe some consistency has been lost, and perhaps we might see this decision reversed in a later edition, because planning is iterated throughout the project, it’s not a once-off, so it should be in the planning inputs.

What they have done though is clarify the use of the Project Plan where it does appear as an input, by adding details the sub-plan of the project Plan that is actually required in each instance.

Project Documents

The next change that will impact the exam is the concept of “Project Documents”, That is, documents that are not part of the Project Plan, but are still necessary to manage the project – a “shadow project plan”, as I call it. In real life this segregation is not so clear, but be prepared for questions like, “All the following are contained in the project plan, except…”

Project documents are largely the “scratchpad” type items, such as estimates, logs, checklists, etc. A full list can be found in Appendix A of PMBOK (page 350).

I find it unusual that Activity Attributes and Quality Checklists etc are in this list, but for the exam all you need to know is that they are.

PMBOK Fourth Edition says, “While project documents are used to assist the project manager in managing the project, they are not part of the project management plan”.

Charter and Scope Statement

The Charter and Scope Statement received a long-overdue overhaul, as there were areas of overlap.

Wanted: “Soft” Project Managers

Project managers have traditionally been good in the “hard skills” areas (technical areas) and not so good in the “soft skills” (interpersonal, influencing, motivating, etc) and so the Appendix G (page 417) and Chapter 9 HR management, Develop Project Team and Manage Project Team processes, includes considerable detail on interpersonal skills, intended to highlight this very important part of the PM’s role. It’s part of what good PMP instructors have been teaching their students for many years, so it shouldn’t raise many problems for PMP students.

This means that CAPM’s will need to learn about the Soft Skills too, because traditionally the PMP exam is 60% PMBOK and CAPM is 100%, so CAPM’s theoretically didn’t need to know much in this area (to pass the exam, not to be PMs) but now that it is enshrined in PMBOK, it can be on the CAPM exam too. So read it ten times.

The Tools & Techniques for soft skills are listed in Chapter 9, but much of the detail is relegated to Appendix G, as it was felt (J) that these skills should not be considered part of a standard.

But of course, just about anything that appears between the front and back covers (except the publishing details and history of the PMBOK) can be used in the exam.

The skills listed are:

· Leadership

· Team building

· Motivation

· Communication

· Influencing

· Decision making

· Political and cultural awareness

· Negotiation

PMBOK says, “The project management team can greatly reduce problems and increase cooperation by understanding the sentiments of project team members, anticipating their actions, acknowledging their concerns, and following up on their issues. Skills such as empathy, influence, creativity, and group facilitation are valuable assets when managing the project team.”

Another change to HR management is that the Manage Project Team process was moved to the executing process group, from the monitoring and controlling group.

They’ve even changed the Changes

Change requests, corrective actions, preventive actions and defect repairs are now grouped under the heading of “Change requests”. But often the type of change (preventive or corrective action) is highlighted, with examples.

Continued in Part 2…