Passing Your PfMP Board Review

The PfMP Exam is for senior executives who have reached a point in their career where they are part of the council within an organization that decides which projects get funded next. The PfMP is short for Portfolio Management Professional, and is a certification offered by the Project Management Institute (PMI).

Once you've met the criterial for experience and training, you must submit an application detailing your experience, to be reviews by a board of existing PfMP holders at PMI.  This is a challenging process and often applications are rejected.

The rejection letter appears to be somewhat vague, and is actually a standard form-letter. Something a bit confusing is that because it is a rejection form-letter, the reasoning given in it is not always accurate.

What the board is looking for are details of your portfolio (size, types of outcomes, projects, programs), and also what you did to establish the PfMP process, if it did not already exist, and what you do to govern it.  How often you mmet with the portfolio committee, etc.

Portfolio Management is critical within a company because organizations grow through projects.  Project spending actually sets the strategy for a company.





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



Book Review: Motivating Employees

Employee motivation is an ever-present concern for most proactive managers.  Interestingly enough, motivation can come from both functional and dysfunctional sources.

I've seen employees motivated for many different reasons: recognition, financial incentive, empowerment, personal growth, tension release, fear, and finally there's that weird Lord of the Flies thing where employees get motivated together against another employee.

In their book, Motivating Employees, Anne Bruce and James S. Pepitone describe the most effective ways to motivate a team.  They describe the three C's which are vital to functionally motivating employees:

1. Collaboration: Be sure to involve employees in decisions and discussions where their efforts are involved.

2. Content: As they produce suggestions, act on those suggestions immediately.

3. Choice: Be sure to offer choices to your employees--even if you can predict what they will decide.

These three techniques actually empower your employees.   Involving employees in decisions that affect them, or the outcome of what they are working on produces a level of buy-in that is hard to match any other way.

Bruce and Pepitone continue with an examination of Theory-X and Theory-Y motivation and management styles.  These styles were originally presented in the 1960's by Douglas McGregor.

McGregor states that Theory-X managers proceed from the assumption that their employees are uninformed, lazy, and needy of high-structure.

Theory-Y managers, however, proceed from the assumption that their employees are qualified, intelligent, and capable of making proper decisions provided they are given proper goals, accountability, authority, and resources to accomplish their tasks.

Although Theory-X is the most effective approach during some situations, if you consider the amount of college-educated employees in the workforce today, it's easy to see how Theory-Y, if applied properly, yields much higher performance.

The authors continue with a formula for encouraging Entrepreneurial Thinking.   Their five-step formula is:

1. Explain the organization
2. Demonstrate how the organization operates and generates income
3. Help your employees understand the competition
4. Encourage intelligent risk-taking
5. Inspire innovative thinking

Another great idea the authors present is to link motivation to performance.  They suggest you develop a written-list of performance standards for meeting and exceeding the expectations you've agreed upon during collaborative sessions with them.

The authors talk about how important it is to weave fun into everything your organization does.   This may sound like a unusual suggestion at first, but the authors point out that there is a direct correlation between fun on the job and employee productivity, moral, creativity, satisfaction, and most importantly--retention.

The final few chapters in the book discuss de-motivating factors (or individuals), and how to deal with them.  There is also a good chapter on conducting effective employee-reviews.

Overall I recommend this book to any manager.   It's a great book to re-read every so oft r/>
Mike J. Berry

CBAP and Agile Development

I attended an excellent presentation hosted by the Northern Utah PMI Chapter, featuring Mike Sandberg, Novell's Chief Business Analysts.  Mike spoke to a room of well over 200 folks about the CBAP certification.  This is the Certified Business Analysis Professional credential that us now coming of age.Mike talked about his own experience discovering the CBAP community and about the successes and issues involved with adopting the framework.

Specifically, Mike spoke about how the PMP and CBAP roles work together.  He talked about some challenges regarding turf and terminology that sometimes befall newer groups.

Someone in the audience asked Mike about how CBAP fits in with Agile.  Mike explained that this is a common question and that the business analyst would be most suited for the Agile Product Owner role. This se to make the most sense to me, and to the others present.

Mike J. Berry

Agile Development Requires Documentation

I keep hearing horror stories from managers about how their teams that have adopted Agile Development insist there are no documented requirements necessary when using the Scrum framework.This is wrong.  

Scrum is intentionally quiet about software requirements so that groups can use what works best for them.

In our training seminars, we show groups practicing Agile how they can benefit from a high-level "strategic" use case model.  This strategic model, or High Level Analysis, is used to flush out the users, the needs of the users, and to expose any data flow components. This technique has proved quick and effective.

Mike J. Berry

Agile Development and Government Contracts

So I attended our SLC-based agile development forum yesterday.  Alistair Cockburn was there, along with some other associates from around the valley. We discussed various successes and challenges with using the Agile Development Model for software development. 

One particular topic that became a main discussion point was how to get government agencies to accept Agile Development Model contract bids. Fortunately, executives from several companies were represented in the room that use the Agile Development Model and pursue government contract work.  They gave us some insight on how to proceed. The challenge is that the Waterfall Development Model (SDLC) is the traditional project development process for government contract submissions.  They like it because it expresses a project in terms of scope, components, time-lines, and milestone dates.  All of this is measurable, so it works very well with the government procurement types.

Agile is a less structured methodology--where you build requirements and code more in a module, by module format.  These modules, called user-stories, aren't spec'd in detail until they are actually being worked on.  Because of this, milestones and time-lines for an Agile project are not as predictable.  The Agile Development Model accepts this reality, and suggests that most projects are not really so predictable anyway.

The trick with the Government is to bid your first project as a waterfall project.  Then, after you have a relationship, suggest that forthcoming projects have an Agile model. You can also submit a Waterfall project with some additional requirements listed on the contract.  ie: "Requirements base-lined at a high-level" or "Progress reported via Project Backlog" or "Prioritization by Need" or "Daily Scrum" or all of these things.

Mike J Berry

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

Why you should stop using SQL Server 2000+ (even though it's a superior product!)

SQL Server 2005 is fantastic.  SQL Server 2000 was wonderful.  SQL Server 7 was OK.  I hear SQL Server 2008 will be even better...

...but wait a minute??  Really, SQL Server 2000 does everything I need.  So does Oracle versions 6, 7, 8, 9, and 10!  So does PostgreSQL, so does MySQL.  So what gives? Don't get me wrong.  I've grown up in the Microsoft garden.  I still have a VB for DOS development kit, and I have used VB 3, 4, 5, 6, and .NET 2003 and 2005.  These are superb and superior products.  The madness is accumulating with a new release every 2 years.  Microsoft is now forced to offer a downgrade from Vista to XP option because folks are getting fed up.

One client of mine is busy upgrading their flagship product from SQL Server 2000 to SQL Server 2005.  Why?  Not because of any new features.  Not because of a better price.  Not because of really any reason at all, except for the fact their customers are asking for it by name. Because SQL Server (and Oracle) are highly visible in the public's radar, many trade journals speak volumes of marketing info about the new bells and whistles they contain.  As developers, however, we all know that perhaps the management UI is better, and 64-bit it great, but basically the engine worked fine and met all of our needs several versions earlier. So my client is spending $500,000 and seven or eight months upgrading their core product--and all of the internal support tools that must work with it--to SQL 2005.  Again why?  To 'add value to the customer experience'...meaning that the salesperson can say "yes, it works with SQL 2005."

You see, in the real world, often non-technical or semi-technical people make the final purchasing decisions for enterprise software.   They grasp for 'clues' of what should separate an inferior product from a superior product, and--well--version 2005 should be better than 2000, right?  Therefore, a product based on 2005 is better than a product based on 2000!  Right?  In reality, somebody must pay for the $500,000 so that same customer is misleading themselves into requesting a higher price-point.

A better model would be to choose a database that is solid, but not in the customer's radar.  This way, they would have no 'journal information' about the database and would not be pressuring you to spend $500,000 every other year to keep up with Microsoft. PostgreSQL, MySQL, Interbase, etc. are all robust databases with 64-bit support now.  If your software is for an internal client (your own company), this whole dynamic shouldn't affect you, but if you make a commercial client-server product, there's no doubt you've experienced this already.

Mike J Berry