Easy in theory, difficult in practice

PMO Leaders, Project Managers, Stakeholders, lend me your ears; I come to neither bury knowledge-based certifications, nor to praise them!

There are two broad types of project management certification approaches - purely knowledge-based or those that incorporate experience-based evaluation.

PMI uses both approaches - the PMP certification uses a predominantly knowledge-based approach while the PgMP certification uses a balance of knowledge and experience-based methods. Although PMI's PMP certification is the global de facto standard, other project management associations also offer knowledge-based certifications.

I previously wrote in "The dualism of the PMP credential and challenges with any knowledge-based certification"  about the limitations of a knowledge-based certification and didn't want to recycle that content.  However, a very common question in online discussion groups is "Should I get my XYZ PM certification?", so I felt that there might be some value in assessing the most common justifications.

Fact

• It's a hiring prerequisite - right or wrong, in many companies, hiring managers or recruiters will only look at your resume if you have a certification.  While this might not be the only method of evaluating someone's suitability, it is a filter that simplifies the workload for these gatekeepers.
• You might be paid more - according to the Sixth Edition of the PMI Salary Survey, it could increase your salary by up to 10%, either through a change in role, base compensation or bonus.  This will obviously be influenced by factors including local supply and demand for project management skills and geographic differences.
• It'll improve project management consistency - certifications provide a common lexicon so long as your organization's methodology and its practitioners use a single association's body of knowledge.
• You might gain some project management technical knowledge which you didn't possess before - given the comprehensive nature of most PM bodies of knowledge, even experienced PMs are likely to learn something new by studying for a certification exam.

Fiction

• It'll make you a better PM - as the majority of the issues I listed in "Seven Deadly Project Manager Sins" illustrate, the differences between a good and a bad PM often relate to their ability to appropriately apply soft skills and no knowledge-based certification can assess this.
• It's the best way to learn about project management - While attending a certification prep course or reading certification study aids might increase your knowledge, a foundation project management course, managing real projects or being mentored are more cost effective means of gaining the same knowledge.  A common recommendation I've made to PMs is to read their association's monthly journal cover-to-cover each month and then to assess their knowledge of the profession at the end of the year.
• It will differentiate you from others - the ubiquity of the PMP certification has mostly marginalized this benefit.  Specialized or esoteric project management certifications may still provide this benefit.

While this article is not written to make you avoid knowledge-based project management certifications, hopefully it has helped with the decision-making process.

(Note: this article was originally written and published by me in April 2011 on Projecttimes.com)

Dear reader, don't be alarmed - this IS your regularly scheduled article!

I'd like to thank Sante Vergini for providing the inspiration for the first topic and the second one had been a splinter in my mind so I couldn't wait till next week to write about it.

Why oh why would someone set up a virtual PMO?

In one of my past articles, I had written about the challenges of establishing and running virtual PMOs. I'm not referring to a PMO which is staffed by geographically distributed team members but rather one which has not been established as a staffed organizational entity. Virtual PMOs might be setup as a single individual spending a portion of their time delivering PMO services or a group of project management practitioners who commit some time to this.

Given that it might be difficult for a virtual entity to elevate organizational PM capability, mature project portfolio management practices or provide a meaningful delivery oversight function, why would organizations choose to go this way?

The most simple use case is when the leadership of a small functional organization-oriented company starts to realize the need to standardize or improve the company's project management approach. The first person who starts to apply some project management discipline might be drafted into being a PMO of one.

Funding constraints could be another reason to establish a virtual PMO. The majority of PMOs are cost centers and the ROI for the investment in setting up and running a PMO might take a few years. If leadership recognizes the need to do something to improve project outcomes but funding is limited, one approach is to establish a community of PM practice and empower that group to design and implement change on a best effort basis.

Once bitten, twice shy might be another driver. Leadership teams which have lived through the fallout of a failed PMO might try to avoid the sunk costs of Groundhog Day syndrome by going the virtual route. Of course, if they haven't addressed the root causes for why the original PMO failed, they shouldn't expect miracles from a virtual approach.

A standard should be the means to a goal and not a goal unto itself

Repeatability is a good guideline when elevating organizational project management capability. But standardizing how information is captured needs to be carefully weighed against the benefits of tailoring and customization.

So what are some criteria which would justify standardizing a specific project management template?

If the information within it is going to be ingested by some automation to feed other processes then standardizing the format will improve processing efficiency and quality. If the consumers of the completed template are working with multiple project teams, there is a benefit in providing them with a consistent look and feel.

But if these conditions are not present, the emphasis should be on the quality of the content and not on the format or structure. If there is still a perceived benefit in standardization, effort should be invested in developing a template which can be easily populated, easily updated and presents what is required by its consumers in a minimally sufficient manner.

Anything more is waste.

It is a well recognized concept that the overall risk inherent in a project generally decreases as you reduce its scope or complexity.  This leads to the common practice of splitting complex projects into many small mini-projects to divide the risk across them and hopefully improve the predictability of the overall initiative.

While this is a good approach, the challenge comes when putting it into practice – how do you decide on a method for slicing the larger project and how many projects should you created?

Here are a few ideas:

• Split the initiative by value chains – the benefit of this approach is that the integration risk for any single customer or consumer is reduced, and if the need comes to reduce the scope within the overall initiative, you can terminate an individual project and still deliver some tangible value.
• Split the initiative by the nature of the deliverables – For example, on a systems development or implementation project, technology deliverables might benefit from being created within one project to avoid cross-project integration challenges, and it may be possible to have operational readiness deliverables (e.g. SOPs, training documentation, or maintenance procedures) created in another.
• Split the initiative based on resource skills or availability – One method of reducing risk is to match the skills of the project managers and team members to the work they are most comfortable with delivering.  This might result in increased complexity from an integration perspective in which case it might make sense to remove the responsibility for integration from each mini-project’s team and centralize it in a separate integration project management function.  Resource availability might be another driver – if there are multiple resource bottlenecks, is there a way to spread these bottlenecks across the projects as opposed to focusing them within a single one?  The overall guidance here is to avoid splitting resources across multiple mini-projects if at all possible.
• Split the initiative based on deliverables with maximum inter-dependencies – To reduce integration risks, review the deliverables list from your WBS and group the ones that are very tightly related into a single project.

Regardless of which method you use to split up complex projects, the key is to perform the rough cost-benefit analysis related to reduced complexity risk but increased lines of communication (don’t forget N*(N-1)/2) and integration risk.

(Note: this article was originally written and published by me in November 2011 on my personal blog, kbondale.wordpress.com)

A PMO might be just the means of achieving your company’s project portfolio management objectives.  Of course, establishing a staffed PMO can incur significant hard costs as well as messy political infighting so savvy sponsors sometimes prefer to start by just dipping their toes into the shark filled waters of organization change.

If you are the coordinator of a virtual PMO, you have a good opportunity to demonstrate your ability to lead a staffed PMO in the (hopefully near) future.  Of course, behind every opportunity is a risk waiting to kick it off a cliff so the following tips might increase your odds of surviving this privilege!

1. Know your role (and make sure that everyone else does too): Many PMOs suffer from the Rodney Dangerfield-syndrome of “No Respect”.  This is aggravated in the case of a virtual PMO where you won’t have dedicated staff nor the political influence that comes with direct reports.  A formal definition of the services scope and authority for your role should be communicated and reinforced with stakeholders to reduce the likelihood of expectation gaps.

2. There’s only so much of me to go around. PMOs tend to be chronically understaffed and this is especially true when it comes to virtual PMOs!  Focus on high value services and automate (or delegate) as much as can be effectively automated.  A PMO should be a facilitator for timely, beneficial business decision making, so if you are finding that all your time is being consumed in administration or in being the “process cop” to project teams, it’s time to start climbing up the food chain.

3. Be a missionary.  The virtual PMO leader is often the sole champion for project management within their organizations.  To succeed, you must help key influencers to see the light.  This can include delivering such activities as lunch and learns, helping junior project leaders plan and deliver projects, seeking opportunities to present project management topics on behalf of your company at conferences and effectively selling the value of project management to executives.

4. Measure, communicate and envision.  A successful virtual PMO leader is one that knows where the organization was, can quantitatively prove how the changes introduced have helped the organization and can paint a picture of where the organization could be if the PMO function continues to evolve.  Leadership is often satisfied with good enough – when the sharp pains associated with a total lack of project management are reduced to mild pangs, attention shifts to other priorities.  A good PMO should be able to sell the business benefits of increased capabilities.

5. Make friends and influence people.  Much more so than for a staffed PMO, a virtual PMO relies on influence and indirect reporting relationships to get work done.  Building on point #3, like all missionaries, strive to answer the following two questions for your stakeholders and influencers:

• What’s in it for me?
• What have you done for me lately?

Running a virtual PMO can sometimes make you feel like you have been cast into a dark pit.  However, as Ralph Waldo Emerson said “When it is dark enough, you can see the stars”.

(Note: this article was originally written and published by me in November 2010 on my personal blog, kbondale.wordpress.com)

While I wrote in “Today, my (PM) jurisdiction ends here!” that a project manager who focuses purely on the triple constraint without considering the organizational outcomes of their project is adding limited value, I’ve also worked with some that willingly operate at the opposite extreme.

This might be the behavior of a project manager who believes that the full accountability for the project’s success falls on their shoulders and that the best way to avoid being blamed is to take over all critical activities. This can also occur with junior project managers who are assigned projects that are within the domain of their past experience – it is too tempting for them to backslide into their “past lives”.

Another rationale could be if it is the reaction to an organization that suffers from low project management maturity. If sponsors, functional managers or team members abdicate their duties, a project manager might be faced with the choice of picking up the slack or letting the project suffer. What’s challenging is that even if the situation improves, the project manager might be very reluctant to let go.

It’s hard to define exactly when a project manager crosses this invisible line, so what are some of the warning signs that their manager could monitor?

• Frequent negative or positive feedback on the project manager’s performance from project participants. You might be surprised by my inclusion of the positive, but in the case of a low maturity organization, excessively positive praise of a project manager’s ownership could be an indication of too much involvement!
• Significant, sustained overtime on the part of the PM while other team members are able to complete their work within normal working hours.
• Neglect for project administration or other low value duties – logs are not maintained, schedules are out-of-date, minutes from key meetings don’t get published.
• As 90+% of a project manager’s role is communication, if they are spending too much time wearing other hats, communication consistency and quality is likely to suffer.
• Excessive use of the pronouns “I” and “Me” instead of “We” when referring to the project. This might seem minor, but it can be indicative of the latent problem.
• Premature departures of previously high performing team members. If a good worker feels that someone else is doing the job that they were assigned to do, they’ll likely prefer to move to a project where they will be able to shine.

While sponsors and team members may appreciate someone who is willing to roll up their sleeves when the situation demands it, if this behavior becomes the norm, the project manager will get blamed regardless of whether the project succeeds or fails.

To avoid this, it’s best to ignore Clint Eastwood’s other quote “Now you know why they call me Dirty Harry: every dirty job that comes along.”

(Note: this article was originally written and published by me in July 2012 on Projecttimes.com)