Chasing After The Latest Fad or Evolving

This last weekend, I had an interesting exchange on the PMIWDC LinkedIn Group discussions board.  This healthy exchange of viewpoints came about from the following message:

In June, PMPs numbers are down by over 4000 while the PMI Agile certification numbers are on a steady rise. What is preventing the ACP from really getting traction?  http://ow.ly/i/NRLD [link to graphic showing the upward trend of the PMI-ACP]

Because that LinkedIn group is not public, I won't include the persons name.  Rather, I will refer to him as "Mr. PMP, CSM, ITIL" and include his responses in red.  Even if I don't agree with everything he writes, I have to respect a differing viewpoint.

PMP numbers likely vary slightly throughout the year and 4,000 is less than 1%. Plus, in the current economy, I don't think a drop is surprising at all.

Now about PMI-ACP. In my opinion, the PMI-ACP has no market (no one asks for it and, as you note, no one is really seeking it even after PMI lowered qualifying standards to get it). It is simply a me-too certificate competing with already established certifications by Scrum.org and ScrumAlliance.org. Besides, it is mislabeled as Agile when all it talks about is Scrum without ever using the word Scrum--making it even less distinguishable.

Personally, I'd rather see PMI focus its efforts on strengthening the PMP, and the overall body of project management knowledge and practice, than chasing after the latest fads.

[Mr. PMP, CSM, ITIL], interesting opinions. I always find these "corrections" compelling. Everyone can read the August edition of PMI Today (the source of my numbers) and draw their own conclusions. It could be there were 4000 people who really weren't project managers in the first place, thinking they needed a PMP, and then realized they really did not. We'll never know for sure.

As for the PMI-ACP, the qualifying standards were corrected while the certification was still in pilot. I know this because I was in Miami with PMI when it happened. It just took several months to get the change implemented in the application process. At least there is a qualifying standard. You and I both have a CSM, yet we both know there is no qualifying standard for that.

The PMI-ACP is not all about Scrum. Again, I know this because I helped create the ACP and because I am the Co-Lead of the ACP support team at the PMI Agile CoP. I won't disagree that a large percentage of the ACP is Scrum related but in VersionOne's latest State of Agile survey, a majority of Agile practitioners are using Scrum to deliver value to their respective organizations. I think the certification is pretty representative of contemporary Agile practices.

If you'd rather PMI focus its efforts on strengthening the PMP, I'm curious how you will feel about the upcoming PMBOK Guide revision and Software Extension. Both include Agile knowledge and practices. Does that mean PMI is chasing after the latest fad or is it evolving?

Derek, I'll admit the 5th edition draft PMBOK is troubling--almost as if some folks are trying to sabotage the PMBOK or simply making changes for the sake of changes. Don't get me wrong, I am not against change but some of what is occuring is not good, doesn't fix some problems in the 4th Edition and introduces some new contradictions and confusion. Waiting to see what the final release settles on. 

Stats can be fun and too often misleading. I don't think month-to-month changes in active certificate holders is very meaningful and PMI-ACP's less than six month track record is nonetheless too short. It's 7 to 18% month-to-month increases are already faltering, losing 32% of it's growth rate in the latest month. During this same time, PMPs dropped just under 1%. If both of these two latest trends continue, PMI-ACP will max out around 6,923 and reach parity (with current month declining) PMP in just over 38 years. 

As a reality check, PMP and CAPM make up 99.2031% of PMI's certificate holders. I suspect the overall number of 'traditional' projects is a not too dissimilar ratio. Adding in the few thousand CSM and other certificate holders won't significantly shift this ratio. And traditional project management is, if practiced well, agile and not the caricature painted by Agile and Scrum advocates.

Listening to people who are participating in the PMBOK revisions sounds a lot like legislation in the government. In the beginning, a bill with a bold new idea or fix is presented. In order to close the deal, the bill gets watered down and new stuff that really has nothing to do with the original bill gets introduced. I can totally see that happening with the PMBOK. But I do think common agile concepts and practices should be included. The question is, will it be a square peg in a round whole, based on the format of the PMBOK?

Speaking to the certification stats, I once presented a correlation graph claiming an increase in ice cream sales caused deaths by drowning. It was merely illustrating that metrics can be used to support just about any claim. If PMI gets more market penetration in India and South America, I think the overall growth rate for the PMP (and ACP) will continue. With PMI being the marketing machine that it is, I see the ACP cannibalizing market share from ScrumAlliance and Scrum.org, not from the PMP.  Only time will tell.

It's my belief that "Agile" practices will be accepted as "Traditional" practices over time. Until then, the misinformed will believe it is a silver bullet. It's funny, when I coach new clients, I always have at least one project manager tell me that he or she proposed similar changes to leadership but was ignored. I've also had attendees of my training tell me that having PMI offer an "Agile" certification legitimizes it as a possible delivery mechanism. This isn't new stuff! Whatever gets people talking works for me.

HT: Project Management Institute

HT: VersionOne

ACP Community Guide vs AgileBOK

The Community Guide of the PMI-ACP (login required) is an initiative of the PMI Agile Community of Practice to provide ongoing support for the PMI-ACP agile certification. PMI Today recently highlighted the importance of community volunteers to create the certification, so it only follows that our community be the ones to mature it into the future.

What about the AgileBOK?

There will be no Agile Body of Knowledge (AgileBOK) supported by PMI.  PMI does not own, maintain, or support ANY web presence that lives outside of PMI.org.  There is not, and never should be an authoritative standard for Agile.  Having an AgileBOK would invite all PMI project managers to rigorously follow a standard and never adapt, tailor, or innovate their processes. This counters what we as Agilists stand and strive for.

How can you contribute to the Community Guide?

Team members will work as individual contributors within the Community Guide project. Their involvement may vary based on the nature of the work and their availability. If you are interested in creating or maintaining articles for the 'Community Guide', contact the current co-leaders of the ACP Support Team: Joeseph Flahiff and Derek Huether

Who is the Community Guide for?

The Community Guide is intended to be the authoritative source for all the stakeholders in the PMI-ACP ecosphere, including

• A study reference for those pursuing the PMI-ACP credential • A training reference for REPs and trainers • A technical reference for exam writers

What does the Community Guide cover?

The Community Guide is a unique community resource, offering you

• Links to relevant PMI documents regarding the certification • The original intent of the PMI-ACP creators for each topic on the exam • The current community consensus on how each topic works on "most agile projects, most of the time"

Image Source: Pictofigo

Social Norms at Work

I recently gave a talk in Michigan on the topic of servant-leadership.  Unfortunately, servant-leadership is something that is painfully absent in so many organizations.  Just a few years ago, it (servant-leadership) was not something I had even heard of.  Going back and reviewing the PMBOK made me realize two glaring omissions.  There is a lack of content on stakeholder or team engagement and there is a lack of content on leadership.  Fortunately, in the last few years, I have enjoyed books by authors like Clay Shirky, Seth Godin, Dan Pink, and Dan Ariely.  I've also met and interacted with some amazing people in the Agile community.  I now interact differently with my peers, as a result of these experiences.  I now apply my social norms at work.  What are social norms?  They are patterns of behavior in a particular group, community, or culture, accepted as normal and to which an individual is accepted to conform. We all go to work and we all get paid to do it.  Too many times, we take things for granted.  We don't question the things we do or the things that happen to us.  I'm pretty sure this is based on conditioning over a long period of time.  Perhaps we need to start treating those we work with more like those we socialize with.  Next time you interact with a fellow employee, ask yourself if your behavior is socially acceptable.

Social Norms

Within an organization, where we are working with other people, things can get twisted.  Some exhibit bad behavior and believe it's somehow forgivable because we're all getting paid.  Well, I don't think that's acceptable.  It's very interesting to see the same people behave differently, when not in the office environment.  Why is it some people forget basic manners or common courtesy, when in an office environment?

Case in point, I hold the door open for people, regardless if I know them or not.  I see this as socially expected behavior.  Socially, I expect a thank you.  To say I expect it is a slight embellishment.  Outside of the office, I still expect a thank you.  Unfortunately, at the office, I've started to accept not getting any reciprocation.  There are a few people in my building that I don't personally know but I still hold the door for them.  They won't make eye contact with me and they won't say thank you.  When the situation is reversed, these same people do not hold the door for anyone.  But, I refuse to accept their behavior.

We all need to strive to understand and empathize with others. People need to be accepted and recognized for their special and unique qualities.  Assume the good intentions of your coworkers and don't reject them as people, even while refusing to accept their behavior or performance.

Drawing:  Pictofigo

HT: Business Dictionary

Zombie Procurement Strategy

The last few weeks I have been advising a Federal Procurement team as they refine a Procurement Statement of Work (SOW).  Unfortunately, I see the existing version as being very heavy and I want the final product to be much more lean.  A perfect example is the current program has 29 documents that are contractually required to be delivered.   Do these documents provide value?  No, most of them to not.

Opportunity 1

Instead of writing the SOW with statements like "Contract holder will deliver this document" and not provide why or how it will help the customer accomplish their goals, I think we miss an opportunity.  I believe we need to advance the conversation with the potential vendors, by structuring the future work as Epics.  As long as the customer quantifies "reasonable", we give the potential vendors an opportunity to think outside the box.

As the owner of the production system, I want to be able to know the average wait time when a customer calls, so I can ensure they are receiving a reasonable level of customer service.

Opportunity 2

Rather than using practical wisdom to create a new SOW, some would rather rely on past policy, procedures, and governance, regardless of current and future needs or if they ever made sense.  I've challenged some by saying there are no procurement requirements stating that we must have these 29 documents.  One Zombie response was  "I found management plans and documents referred to in the PMBOK.  We should require the vendor to deliver all of them ".

Before I emptied a full can of Zombie Away on him, I said that wasn't the most efficient approach.  The PMBOK also says to use "expert judgement".  If you are not prepared to use expert judgement, a vendor is going to take your Zombie money and walk off with it.  All you'll be left with is an empty wallet and 29 documents.

I'm all for looking to the PMBOK for guidance.  But remember, it is a guide, not commandments.

Like the image? Find it at Pictofigo

Procurement Zombies

I just finished reviewing a 42 page Statement of Work (SOW), which at some point will become the basis of dozens of (if not more) proposals, which will result in the award of a contract.  If there was ever a time I would want to guard myself against zombie infiltration, the procurement cycle would be it.  But at some point, zombies will get involved. In an attempt to be thorough (yet entertaining and brief) let's focus on the Project Procurement Management processes: Planning, Conducting, Administering, and Closing.

Planning

The process of documenting project purchasing decisions, specifying the approach, and identifying potential sellers.

Conducting

The process of obtaining seller responses, selecting a seller, and awarding a contract

Administering

The process of managing procurement relationships, monitoring contract performance, and making changes or corrections as needed.

Closing

The process of completing each project procurement.

I pulled these from Chapter 12, Page 313 of the PMBOK Guide 4th Edition

For the sake of brevity,  I am not going to tell you the right or wrong way to manage procurements.  I'm not a procurement specialist.  So instead, since it's Festivus, I'm going to air grievances.

Procurements involve currency.  That means that if it is your money being spent, you want to get as much value for your money as possible.  It also means that if it is not your money being spent, zombies seem to be drawn to procurements more than brains.  Don't ask me to provide a metric for this.  Just trust me.

In 15 years, I can not say I've witnessed any zombie activity at the planning stage.  Then again, I've never seen a unicorn either but I'm not saying they don't exist.  Perhaps the zombies defer to the humans at this early stage.   But the further along in the process, the more zombies seem to appear.  If you really want to see a zombie swarm, add a purchasing card into the mix.  Somehow, purchasing card usage can actually accelerate human-zombies transformations.

Opportunistic Procurement Zombie

Let's say a zombie needs a new computer because its current one died.  I know, ironic.  The undead having something die.  Anyway, it gets on the phone with someone willing to sell a new shiny computer.  If the boss fails to establish a budget or specific specifications for the replacement device, there's a pretty good chance the zombie is going to order much more than really needed.  Good planning in this case, can cut down on zombie purchasing.

Entitled Procurement Zombie

Back in the day, working as a hardware consultant for a few federal programs, I witnessed a strange sense of entitlement. When it comes to zombie to human ratios, I've seen way more zombies on September 30th of each year than on any Halloween.   These zombies, to ensure their program budgets will be equal or greater than the year before, go on a wild spending spree every September 30th (end of the fiscal year).  I knew a colleague who worked for a zombie on a federal program.  He was given a purchase card and instructed to contact Dell and order as many laptops as possible until he had spent "X" dollars.  He was they instructed to ask them to not ship the laptops because the program had no need for them and nowhere to store them.

If you enjoyed the post great!  If not, I will challenge you to a feat of strength.

Like the image? Find it at Pictofigo

What's in PMBOK 5?

Though I know people are hard at work, deciding what will go into the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) 5th edition, I can't help but add my 2 cents.

We're all armchair quarterbacks at one time or another so I'm rationalizing this post.

What is one of the biggest gaps in the current edition of the PMBOK, in my opinion?  It's the complete omission of (management) models or approaches.  Agile, Scrum, Kanban, Spiral, Waterfall, and RUP should be defined in the PMBOK.  It would be really nice if the PMBOK added an entire section dedicated to this, complete with diagrams and workflows.  I think there is a problem, if you find yourself sending people to Wikipedia to find a list of the different software development processes.  I completely understand there is more to the world of project management than just software development. But, I'm trying to make a point and provide an available resource for this post.

I've had people use the PMBOK as the excuse not to use Agile, saying it wan't explicitly listed.  I pointed out that neither was Waterfall.  I wrote a post titled "Agile is in the PMBOK so it must be true" to make a point.  If PMI wants the PMBOK to be used as the de facto standard for over 400,000 PMPs, they need to take a more iterative approach in releasing editions.

If anyone at PMI is listening, I would be more than happy to help.

Like the image?  Find it at Pictofigo

Zombie (Stakeholder) Management Strategy

Today we're going to learn a little about zombie stakeholders. Now, I know you're a little apprehensive.  You don't believe in zombies.  You believe your stakeholders are just a little bit different.  Well, I'm sorry to break it to you but that's not a stubborn human wanting to arm-wrestle you for that last danish.  That there's a zombie!  How else do you explain that persistent stubbornness?  Now, stakeholder zombies are a little different from regular zombies.  Rather than brains, these zombies are highly unique and you much adapt to each one independently.

The Undead Stakeholder

Myths and Realities

Here are some specific background data. The first is a fictitious virus called "Solanum" that creates a zombie. The virus is spread (such as through an open wound, when coming in contact with infected blood or saliva), and treatment is limited (usually amputation).  Now, there was a mutation of the Solanum virus around the time PMI was created.  This mutant virus was known as Solanum-3c (Solanum-3-constraints).  Chances are it will only infect your stakeholders but you, as a project manager, may still be a carrier. In reality, stakeholder zombies walk among us.  You just have to be on your toes when you're around them.  They will try to infect you.  Don't let it happen.

Weapons and Combat Techniques

The weapons at the average project manager's disposal aren't quite a dramatic as those used on regular undead. For regular zombies, a common M1 carbine and the machete are highly effective.  For stakeholder zombies, finding out what's important to them will stop them dead in their tracks.  Different stakeholders have different needs. Zombie stakeholders are no different...with the exception of tattered clothing and a greenish skin tone.  If they say Brai...cooooooost, focus on cost.  If they say Brai...delivery date, focus on the delivery date.  All zombies want brains first.  They can't help it.  But, after that, find out what is important to your zombie stakeholder and make a note of it.

On the Run

If you're dealing with regular zombies, you need to know rules and necessities of traveling through zombie-infested territory. If you're going to drive a car, make sure you have keyless entry and the windows are rolled up.  Do NOT touch the zombies!  If you're dealing with zombie stakeholders, don't run.  If anything, get as close to them as possible.  If given the choice of interacting with them over the phone, through email, or in zombie (in person), choose to interact with them directly.  The more attention you give them, the quicker you can react to them and their needs.

On the Attack

Though some believe in avoiding zombies at all costs, which you should, there are strategies and tools to eradicate zombies from an area.  For zombie stakeholders, we don't want to eradicate them.  Rather, we just want to make them happy.  Find out what makes them happy!  Now attack.

Conclusion

Though you don't want to get close to regular zombies, you should try to engage the zombie stakeholder.  Know what's important to them.  Understand their needs.  I've made the mistake of sitting in a status meeting with regular zombies.  I asked what they wanted to see in the next release.  The answer? Brains.  I asked how could I streamline communications?  The answer? Brains.  I drank my coffee and ran.

Don't think the Solanum-3c virus is limited to stakeholders.  Elizabeth Harrin over at A Girl's Guide to Project Management wrote an excellent post on zombie project managers. Be afraid.  Be very afraid.

Graphic: The Daily Pennsylvanian

PMP Application Process and Reading Instructions

PMI Audit

An interesting thing happened when I was approached by a coworker asking for assistance in completing his PMP application.  His concern was he would be audited and word around the office was that I had been audited by PMI and did just fine.  Both facts were true and I was more than happy to assure him that as long as he was factual about what he put in this application, he would have nothing to worry about.  All the same, he said he would feel more comfortable if I would review what he wrote. He admitted that what he was going to show me wasn't his actual application, but rather, he was working on a spreadsheet to make sure he had his bases covered.  Good idea, I said, show me what you have. What he brought up was an Excel workbook, provided by another coworker who had recently attended a PMP boot camp. I noticed right away that he had 7 projects listed totaling over 10,000 hours.  What really caught my attention was the breakdown of hours across the process groups. Below is an example of one of the projects.  Names and titles have been changed but the hours were not.

Company

Project Title

Job Title

Start - End

Total Hrs

Initiate

Plan

Execute

Control

Close

Acme

Foo

Sr. PM

11/04 11/05

2000

100

500

1000

300

100

I asked him how he came to such exact amounts per process group.  He pointed to help text listed in the bootcamp-provided workbook.

In the following worksheet, we will try to compile the hours you spent on each Process Group for each of your project. Eventually, you will need these hours to fill in the PMP Application... Let us assume that this is the typical project manager job with about 85% of the hours involving tasks similar to those in the Typical PM Task worksheet.  Assuming this was a typical project manager task with a rough distribution of 5% of these hours in Initiation, 25% of hours in Planning, 50% of hours in Executing, 15% of hours in Controlling, and the remaining 5% in Closing.

When I asked him to explain what I was seeing, he stated he had worked on the project for a year and took a 2 week vacation.  (2,000 hours).  Then he said something that surprised me.  Well, the worksheet said to put percentages in so that's what I'm doing. My response was "Noooooo, that's for a "typical" PM doing "typical" PM tasks. I told him was listed in the help text was a calculated average and only there as a guideline.    In addition, I clarified, I didn't think he could map 100% of his time to deliverables.

I told him that he needs to look at mapping his work experience to the process groups like he would if he were identifying and scheduling activities of any project. (Reference the PMBOK for items in blue)

• Define Scope (Section 5.2 - Page 112)

• Create Work Breakdown Structure (WBS) (Section 5.3 - Page 116)

• Define Activities (Section 6.1 - Page 133)

• Sequence Activities (Section 6.2 Page 136)

• Estimate Activity Durations (Section 6.4 - Page 146)

Now, you may disagree with what I proposed but I hope you understand my frustration after seeing something like this.  First, he didn't read the instructions correctly.  Second, his primary concern was being audited, not meeting the fundamental requirement of detailing work activities.   This brings me to my final point.  Before defining scope, you need to collect requirements(Section 5.1 - Page 105).

I've come to find out, he doesn't even want to get the PMP. He's being pressured by his company to get the certification.  The whole situation could be fodder to half a dozen posts or articles.  I don't know what part bothers me more, that he missed the assumptions listed by the PMP boot camp or the fact that his company is pressuring him to get a certification that he doesn't want.

I wish him luck.