PMBOK 6 vs PMBOK 7

In August of 2021, PMI released the PMBOK 7th Ediiton.  I have a previous post describing what's new. Surprisingly, is a book filled with professional soft-skills, and not really a process-guide for executing projects.  Wihile PMBOK 1-6 Editions contain step-by-step process guidance for project execution, PMBOK 7 is all about the soft skills.

I tell my PMP and CAPM students they will need both, and an easy way to think about it is to use PMBOK 6 for learning how to manage projects, and PMBOK 7 for learning how to be an excellent project manager.  One analogy I used in a recent public presentation is that PMBOK 6 is the bones, and PMBOK 7 is the meat.

Mike Berry  Red Rock Research

 

 

PMBOK 7 Announced!

In August of this year (2021), the Project Management Institute will release PMBOK 7!  This edition will be different than past editions of the PMBOK as PMI is emphasizing a descriptive program versus a prescriptive program.

The new Project Management Body of Knowledge will contain 12 Project Management Principles, which help guide decisions, 8 Project Performance Domains, and 7 Model Sets.  They are as follows:

 

12 Project Management Principles:

 

  • Stewardship
  • Team
  • Stakeholders
  • Value
  • Systems Thinking
  • Leadership
  • Tailoring
  • Quality
  • Complexity
  • Risk
  • Adaptability and Resilience
  • Change

 

 

8 Project Performance Domains:

 

  • Stakeholders
  • Team
  • Development Approach and Life cycle
  • Planning
  • Project Work
  • Delivery
  • Measurement
  • Uncertainty

 

7 Model Sets

 

  • Situational Leadership
  • Communications Models
  • Motivation Models
  • Change Models
  • Complexity Models
  • Project Team Development Models
  • Other Models
In addition, some definitions are expanded upon. One example is thinking of your organization as a System of Value Delivery.

Something a little awkward is that the book is actually 3 separate texts, glued together--complete with their own page numbering systems and indexes.

 

PMBOK 6 Announced!

September 6, 2017,  PMI will release Version 6 of the Project Management Body of Knowledge (PMBOK) Guide.  The updates in the new guide reflect slight adjustments to the framework expanding it to encompass managing equipment as well as human resources, and changing terminology from “control” to “monitor” in many areas.  In addition, PMI will publish the new Agile Practice Guide which will become PMI’s definitive resource for all things Agile.   

The PMP and CAPM tests will not change until January, 2018.

 

Knowledge Area Changes:

• Project Time Management > Project Schedule Management

• Project Human Resource Management > Project Resource Management

 

Process Name Changes:

• Plan Stakeholder Management > Plan Stakeholder Engagement (Planning)

• Plan Human Resource Management > Plan Resource Management (Planning)

• Perform Quality Assurance > Manage Quality (Executing)

• Control Communications > Monitor Communications (M&C)

• Control Risks > Monitor Risks (M&C)

• Control Stakeholder Engagement > Monitor Stakeholder Engagement (M&C)

 

New Processes:

• Manage Project Knowledge (Added to Executing)

• Implement Risk Responses (Added to Executing)

• Control Resources (Added to M&C)

 

Deleted processes:

• Close Procurement’s


Advice for Passing the PMP Exam

The PMP, or Project Management Professional certification, indicates a person possesses years of industry experience participating in projects, and they understand the PMBOK framework.

The PMBOK, or Project Management Body of Knowledge, is a framework comprising 42 processes useful to managing formal projects.

Legendary in the industry, the PMP exam is one of the toughest professional exams out there.  It consists of 200 questions and takes most people the entire 4 hour allotment of time to complete.

The test is put together using Blooms Taxonomy, a learning framework that describes different ways people process learned information.   Recalling lists versus selecting the best option from a set of viable options are examples of categories in Blooms Taxonomy.

One major tip for passing the PMP exam is to expect to be reading questions in street lingo.  For example, the question may be a short story about a manager asking for something from her project manager.  The question will contain no terminology...you will be expected to translate the street lingo into the particular framework component being described and select the correct answer from the choices given.

I teach a PMP Exam Prep class and have many students who pass, and a few who don't.  What's the difference?  Quality study time.  Be sure you take this exam seriously so that you can benefit from the PMBOK framework concepts.

Mike J. Berry, PMP, CAPM, CBAP, ITIL, ACP, CSP, CSM, CSPO
John C. Maxwell Leadership Coach
www.RedRockResearch.com

 

Anatomy of an Execution Plan

Have you been challenged with performing a high-risk task like upgrading a prominent server, for example?

Here's an execution plan template that you can use to guide you.

I. Executive Summary
Brief overview of intended event.

II. Review of Discovery
Details of what efforts were made to research what is listed in the following sections.  Meetings, Vendor consultations,  Online Resources, and Conventional Wisdom can be included.

III. Pre-Upgrade Procedures
Steps identified to be taken before the event.

IV. Upgrade Procedures
Steps identified to be taken during the event.

V. Post-Upgrade Procedures
Steps identified to be taken after the event.

VI. Test Plan
Verification procedures to confirm the event was a success.  This section should define the success criteria.

VII. Rollback Plan
In case the worst happens, what to do.

IIX. Situational Awareness Plan
After-the-event steps to validate the success of the event with the system's business users.  This would include a two-way communication between your group and the business users, announcing the success, and providing contact information for them to contact you in case there is still a problem.

IX. Risk-Management plan
A plan listing risks associated with the steps above and recommendations as to how to lower those risks.

X. Schedule
If the event spans many hours or days, you may want to draft a schedule for the benefit of all involved.  Include on the schedule the 'rollback point,' which would be the latest time a rollback could be successfully performed.  Your success criteria whould have to be met by this point to avoid a rollback.

Be sure the Execution Plan is in a checklist format, not a bullet-list format.  Require participants in the event to 'check' completed checklist items and sign-off sections they are responsible for.

For critical areas of high-risk, (ie: setting up replication), for example, you may want to require two individuals to perform the checklist steps and sign their names when that section is complete.

If you like, add a 'lessons learned' section to be completed later, and ke copy of the execution plan for historical purposes.

Mike J. Berry
www.RedRockResearch.com

Book Review: Under Pressure and On Time

Ed Sullivan's book, Under Pressure And On Time, is a no-nonsense guide for delivering software products to market in a timely manner.

In this industry where the average software project is late, over budget, or a complete failure, there are so many books written about what not to do.  It's refreshing to read a software development book that tells you "what to do" for a change.

Sullivan skips past conventional theory and provides real-world experiences and wisdom for how project managers and software development teams can succeed in this challenging industry.

Novel to Sullivan's recommended approaches is the concept of one-team-per-project, reporting to a single manager.  Conventionally, most companies split out development, quality-assurance, and product management into different departments.  Sullivan describres this configuration as a model set-up-for-failure.  Too many factors, he says, complicate team performance when each team-member is reporting to a separate manager.

I consult with software development companies to improve their product delivery speed and product quality.  I call Sullivan's single-team suggestion the "lean model," and I agree with his conclusions.

In the manufacturing sciences, there is a belief that the production manager and the quality assurance manager have an inherent conflict of interest, therefore, they should be separate departments within a manufacturing organization.  Many business books are written about this.

In software, however, this model is a less-effective approach.  It can work, but it creates barriers between project teams for several reasons:


  1. Contention can arise as an "us vs them" mentality builds when team-members go back to their respective departments dougouts, to commesurate with their non-project department staff.

  2. As team-members need each other to succeed, it becomes easy for a team-member in one department to delay requests, or grandstand, because their department manager "has asked them to work on other things this week."

  3. A department manager will tend to be uninformed about upcoming urgent project team needs and may unintentionally delay the project by asking their employee to do other things at the most inconvenient time for the project.

  4. A lack of focus will accompany any project team-member who has continuous department responsibilities outside of the project team.

  5. If contention arises, the project team-members from different departments may value disparaging another department, rather than working together to solve the problem at hand.


Sullivan goes on to discuss effective hiring techniques, retention techniques, and general healthy corporate culture factors.  He talks about ranking employees in terms of inner-circle, middle-circle, and outer-circle.  This reminds me of Jack Welch's theory on differentation.

Another novel concept Sullivan describes is his simple but effective project scheduling process.  He breaks each month into daily rows, listing team members names as column headers.  Inside of each cell is a letter/number combination representing who needs to be finished with what task on that day.  In my opinion this is much better than a gantt chart.

Sullivan goes on to describe meetings, schedule management, release management, and project closure.

I found this to be a beneficial book to read.  I would recommend reading it topically, as a reference, rather than cover-to-cover.

Mike J Berry www.RedRockResearch.com

Book Review: Software Project Survival Guide

In Steve McConnell's book, Software Project Survival Guide, he describes the foundation and procedures for managing a successful software development project.

Researching from NASA, IEEE, and some other industry giants like Grady Booch  and Tom Demarco, McConnell summarizes software development into six stages:


  1. Planning

  2. Design

  3. Construction

  4. Testing

  5. Release

  6. Wrap-up


McConnell also offers some great ideas like keeping a project history to record lessons learned and actual project data (time to completion, lines of code, etc.)

He talks about Quality Assurance practices and team development.  Interestingly enough, his book starts with a diagram and commentary on Maslow's human needs heirachy, and how the needs of a software development group are similar.  He proposes a Bill of Rights for the project team, and a Bill or Rights for the customers.

He offers a project health quiz--allowing you to measure your project to see how probable it is at succeeding.

McConnell ends his book with a chapter on project do's and don't, borrowed from NASA.  These are:

Software Development Project Do's:


  1. Create and follow a software development plan.

  2. Empower project personnel.

  3. Minimize the bureaucracy.

  4. Define the requirements baseline, and manage changes to it.

  5. Take periodic snapshots of project health and progress, and replan when necessary.

  6. Re-estimate system size, effort, and schedules periodically.

  7. Define and manage phase transitions.

  8. Foster a team spirit.


Software Development Project Don'ts:


  1. Don't let team members work in an unsystematic way.

  2. Don't set unreasonable goals.

  3. Don't implement changes without assessing their impact and obtaining approval of the change board.

  4. Don't gold-plate (don't add features no customer asked for).

  5. Don't over-staff, especially early in the project.

  6. Don't assume that a schedule slip in the middle of a phase will be made up later.

  7. Don't relax standards in order to cut costs or shorten a schedule.

  8. Don't assume that a  large amount of documentation ensures success.


Overall, this is a great book for new software development managers, and software development mangers who have chosen SDLC, or other non-Agile development methods. Published in 1998, this book came out before the Agile software development movement.  Regardless, it's a good book to refer to occasionally.

Mike J Berry www.RedRockResearch.com

To Gantt or not to Gantt? That is the question!

A curious experience is looking on Microsoft's Project Template website for 'Software Development Project Plan Templates.' 

With Microsoft being a software development company and Project being what it is, you would think there would be many software development templates--some for Waterfall, some for SCRUM, some for XP, some for Crystal, etc. I found only two.  Both were quite rudimentary.  Interestingly enough, though, there are tons of cookie recipes, scrapbook planning templates, and other fun, useful project plans.  I was tempted to add a new subcategory for weekend jeep projects. This sort of begs the question about how many of us are really using Gantt Charts in our software development processes.  I've asked my peers about it and seem to get an overall answer that it takes as much time to update the gantt chart is it does to complete the project.  Hmmm.

We used gantt charts for a while at one of my client sites, in an attempt to display project status.  Although I think the executive staff felt catered to, I got a sort of 'deer in the headlights' effect from them. An interesting side affect was that the development team discovered we could use the gantt chart, projected on the wall in all it's glorious complexity, to underscore how busy our workload was and to negotiate for more time.  (This seemed to momentarily put us in the strongest negotiating position.)

Still searching for a better project status communication medium, I came across a wonderful process called Earned Value Management.  This is a process that developed in the government contractor circles, that displays--all-at-once--the project projected baseline for cost and progress, the actual cost, and the actual progress.  It's a wonderful tool, and after you understand it, you would think why would we do this any other way? Other tools exist, including Agile Burndown (or Burnup) charts--and they are helpful.  They show workload vs. schedule--two of the three series of information.  But Earned Value Charting seems to be the final endpoint for communicating succinctly the progress of your project.

Oh, btw, Microsoft Project will produce an Earned Value Chart for you.  You just need an advanced degree and probably another staff member to keep track of all the numbers it requires.  I wonder if anyone has ever tracked earned value progress on cookies baking in the oven?

Mike J Berry  www.RedRockResearch.com