Tag Archives: ITIL

What makes a Project Manager, Professional?

The Professional Certification vs Experience Bias

Like many Project Managers, who had “earned their stripes” in the delivery of projects prior to the popularity of certifying organizations, I have often looked at the PMI certification “tags” after a signature with a certain level of skepticism. Was this really a Project Management “Professional” or just someone claiming expertise after paying a fee and taking a test? While it is true that there are many highly skilled and greatly experienced PMP‘s out there, there are also many PMP’s who present themselves as more than they really are.

The value and meaning of a PMP certification, or really any certification, has been well discussed in blog postings across the Internet and over many years. (See below for links to several of those discussions). The posting that hit the mark for me is one from 2006 by Timothy L Johnson, “Those Star Bellied Sneetches“. He sums up the issues,

[The Dr Seuss book] is about class warfare backfiring, but I see many of the same parallels showing up in the project management certification debate … especially in hiring and staffing decisions.

The presence of a PMP “star”, especially in today’s recruiting practices, is often misinterpreted as a guarantee of success and its absence, a sign of risk.

While such assignment may be misapplied, the concept of an organization that certifies the professional skills and experiences of a project manager does have merit. Companies and public agencies today have significant project needs and complex initiatives that would benefit from a skilled project manager … a project management professional.

So What Makes a Project Manger, a “Professional”?

Skills

“Skills” are the organizational structures that a PM brings to a project along with the ability to apply them expertly. Whether these structures are expressed in terms of PMI/PMBOK Processes or an ITIL Framework or some other form, these are the tools that a PM uses to build a project’s definition, plan, execution and control. Expertise in using these tools effectively is a basic requirement for a PM, who falls into the “Professional” category.

Perspective [aka experience]

Classroom studies and readings can provide an understanding of particular PMI or ITIL deliverables, but they don’t explain people or problems. Project management is not about managing “things”. Project Management is about leading and managing people / teams. When performed at a “Professional” level, Project Management utilizes experience (and the perspective can come with it) to help the project teams to be successful in their delivery.

Ethics

While all adults may be expected to conduct themselves ethically, recent years have shown that it not always the case. To avoid any confusion over what is “ethical conduct”, PMI created a formal Code of Ethics and Professional Development  that is enforced under penalty of certification loss:

  • Responsibility — Taking ownership of decisions including their consequences. This includes knowing and meeting all legal requirements, reporting unethical or illegal conduct to appropriate management, fulfilling commitments and protecting proprietary and confidential information.
  • Respect — Being respectful of yourself, listen to others and protect resources entrusted to us.
  • Fairness — Being fair and transparent in decisions including disclosing conflicts of interest to appropriate stakeholders.
  • Honesty — Being honest in communications and conduct.

ITIL similarly places importance on ethical conduct, but handles the topic of “ethics” through its Best Management Practice Partnership with APM Group‘s Ethics and Standards Board.

Ownership / Quality Delivery

Finally, with a “Professional” Project Manager, there is an inherent sense of ownership of a project. Just as a gardener carefully plants a seed and nurtures it as it grows to maturity, the “Professional” Project Manager guides a project through its life cycle.

The end product (the “fruit”) may belong to the business, but the project itself is “ours”. We take pride how well our “seedling” is supported by the project tools and framework that we utilize. We may add more structure along the way (or remove some) to ensure our projects grow fast and straight. The quality delivery of the project is our responsibility as Professional Project Managers.

The Role of Certifications & Organizations

As much as I dislike the inherent inference of expertise that certification monikers indicate today, the certifying organizations do provide effective tools, structures and frameworks upon which project management practitioners can effectively build.

Certifying organizations also have the potential to further their stature by addressing the experience gap. Instead of accepting form-based experience validations, these organizations should consider the creation of modern (project management) “trade” guilds, where apprentices can learn under the supervision of experienced PM “craftsmen” and masters. Instead of discarding certifications, stronger mentoring links with seasoned professionals or structured apprenticeships should be established as part of certification requirements.

[Yes … I am a PMI-certified PMP.]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

The De-valued Professional Project Manager” by Bruce McGraw, 2012, http://fearnoproject.com/2012/03/17/the-de-valued-professional-project-manager/

If you have devoted your career to being a professional PM, like I have, you are frustrated watching companies put individuals into project manager positions who do not have the experience nor the skills to do the job.

Those Star Bellied Sneetches” by Timothy L Johnson,  2006,  http://carpefactum.typepad.com/my_weblog/2006/05/those_starbelly.html

[Dr Seuss book] is about class warfare backfiring, but I see many of the same parallels showing up in the project management certification debate .. especially in hiring and staffing decisions.

Project Management – A Modern Profession” by Michelle Symons, 2012, http://www.pmhut.com/project-management-a-modern-profession

But recognition of professionalism is not just about training and qualifications – it is also about continuous professional development and the ability to demonstrate the skills necessary to competently manage complex projects.

License to manage? (On PMP and certification)” by Scott Berkun, 2006, http://www.scottberkun.com/blog/2006/license-to-manage-on-pmp-and-certification/

I just don’t believe that on their own these things signify much about the ability to perform, especially as a manager. To be fair, I doubt any exam or degree can do that, which explains my general opinion about certification programs.

Why I’m Not a PMP“, by Glenn Alleman, 2006,  http://herdingcats.typepad.com/my_weblog/2006/05/raven_young_pos.html

I guess in the end the PMP moniker doesn’t appeal to me that much. It seems to be a “gate keeping” type badge.

Advertisements

Methodologies and Project Madness

There are times when technology projects seem to be something more of William Shakespeare’s Hamlet or Macbeth than they are manifestations of today’s business world. The relative obscurity of Shakespeare’s prose is certainly challenged by the confusing technical jargon often used by today’s project stakeholders.

Whether it be the seemingly positive prophecies of Macbeth’s witches (Initial Estimates ?) or the warnings of King Hamlet’s ghost (Historical Accounts ?), the initiation of a project can be filled with confusing, often conflicting, data. It is the skill and experience of the project management team that sorts through that initial information and develops a plan.

The project team can select an aggressive methodology, employing a Macbeth-style Agile (?) approach, or it can study a problem intensely before acting (e.g. Hamlet’s “madness” / waterfall planning methodology [Act 2, Scene 2]). The selected project methodology provides only a framework. It is the action of the actors (the project management team) that really shapes the outcome.

With both power and urgency, Lady Macbeth certainly plays her role as a key stakeholder well. It was unfortunate for Macbeth and those who surrounded him that he listens just to her. [Literary Reminder (L-R): Lady Macbeth encourages Macbeth to kill the King. Macbeth then orders his friend, Banquo, & Banquo’s son killed.]

While some stakeholders may be vocal and play lead business roles, it can be risky for a PM to let them independently influence project decisions. Some might argue that Lady Macbeth was not just a stakeholder, but actually an Agile Customer or Business Sponsor or perhaps an Agile Product Manager. One thing was for certain, Macbeth’s weak employment of an Agile approach left much to be desired.

Unfortunately, Macbeth’s failure to build a strong Agile methodology includes an absent, independent Quality Assurance review process. As he piles bad decisions on top of a poorly advised strategy, his detractors are not in a position to properly challenge his processes.

Eventually, Macbeth returns to the resources (The Witches) who had been advising him since Project Initiation. At this point in the play, the audience might question the Witches role. Perhaps they are stakeholders, with a direct interest in the outcome, instead of just being influencers. Macbeth, however, does receive additional information which he adds to his Risk Register. [L-R: The Witches to Macbeth … Beware of McDuff, you cannot be harmed by any man “born of woman”, and you will be safe “until Birnam Wood comes to the Dunsinane Castle”.]

Macbeth properly assigns the risk impacts (i.e. his death), but he fails to properly assess their probabilities. Consequently, Macbeth’s risk mitigation plans (preparations for battle) end up being less than adequate. (I hope I’m not ruining this  the ending for you…)

Risk analysis is an extremely important part of Project Management. It begins early and continues throughout the life of the project. Proper assessment and routine reviews of risk probability can have significant impacts on project outcomes.

In the final act, poor Macbeth realizes the errors in his assumptions and how they echoed into risk probability assessments and mitigation plans. [L-R: McDuff was born by C-section, i.e. not of woman born; the armies marching on his castle cut boughs from the Birnam Wood for protection.] The general loss of stakeholder support (from the Scottish noblemen) proves to be his undoing.

Most of us hope to learn from our project failures and to manage another day. Macbeth literally lost his head over it (and may have set back the use of Agile in Scotland for several centuries).

Let’s check in on our other Shakespeare character-turned-Project Manager. Like Macbeth, Hamlet receives significant input during Project Initiation. [L-R: Hamlet talks with his father’s ghost while Macbeth talked with The Witches.] Hamlet, however, does not have a strong stakeholder pushing for immediate results, and instead, he selects a waterfall methodology with extensive planning.

As with many of us who have chosen more traditional project methodologies, Hamlet’s reflection and planning processes were viewed by his stakeholders as madness. Hamlet’s lack of external activity was generally viewed as “melancholy”. One of his stakeholders, Polonius, did see that there might be something else. [L-R: “Though this be madness, yet there is method in’t.”]

When external events do change, Hamlet (still the planner) sees his opportunity to validate a key assumption (Claudius did kill his father) and begins execution of his plan. After a brief test, assumption validation is in-hand and Hamlet moves forward with what should have been the final stage (killing Claudius). At the critical moment in the play, however, huge scope change appears. [L-R: Hamlet doesn’t kill Claudius while he is praying because Claudius might enter heaven … under a rare, being-killed-while-praying clause.)

In my opinion, had Hamlet received either PMI or ITIL training, he never would have allowed that last minute scope change and Shakespeare’s play would have been much shorter. As it was, Hamlet did allow the scope change (the requirement that Claudius be damned, in addition to being killed) and Hamlet went through several more trials (scenes) before he could bring his project to a “successful” conclusion.

Changes in scope, especially as they occur near to project closure can have significant negative impacts on project outcome. In Hamlet’s case, he did end up killing Claudius, but surrendered his life in the process. Hamlet’s funeral, provided by the stakeholders that were still alive in the end (and there weren’t many), was a testament to his drive and get-it-done management style, but Hamlet was still dead.

Project methodologies, whether early-Agile (Macbeth) or traditional waterfall (Hamlet), are helpful in providing structure and approach, but they are not guarantees of project success. It is the people, the project managers, who employ those methodologies who make the difference between success and failure.