Tag Archives: Information Technology Infrastructure Library

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

Why “Successful” Projects Fail …

[The Truth About Change Management]

The project satisfied its requirements. The project was delivered on schedule AND under budget. It was a “success”, right? … Perhaps.

The open question is: How was the project received by its stakeholders?

Some were very happy with it. Most liked it a lot, but there were a handful of stakeholders who were dissatisfied. They didn’t think that the project delivered everything it should have, but those stakeholders didn’t participate fully and had false expectations of what was within the project’s scope.”

Does that sound like the familiar lament of a “wronged” project manager?

It’s easy to blame those stakeholders for their own dissatisfaction, but is that fair or even correct?

The Project Management Institute (PMI) includes “Manage Stakeholder Expectations” as one of the five processes included in Project Communications Management. On smaller projects, managing stakeholder expectations would fall under the Project Manager’s responsibilities. On larger, more complex projects a Change Management specialist might be assigned to address that process/task group.

How Quickly They Forget …

Even though stakeholders may have participated in the requirements gathering / definition activities, they may not remember (or may have chosen not to remember) what was decided to be “in” scope or “out”. A good project management team will carefully document the project and deliverable requirements, as the requirements are used to determine product acceptance criteria and completion. As the project proceeds, additional definition might be added to the requirements (progressive elaboration), but the core requirements remain unchanged.

Both the PMI  and the Information Technology Infrastructure Library (ITIL) processes include Change Management methodologies to accommodate changes in project scope (when requirements are modified). These processes / methodologies allow the change to be documented, reviewed and approved, prior to development work or implementation proceeding.

Without strict Change Management controlling of project scope, many projects have problems meeting their schedule or cost commitments. These Change Control documents are also useful in helping stakeholders understand the project scope.

Change Management: Not Just Scope Control

While PMI & ITIL focus on Change Management primarily in terms of scope control, it is actually a much larger work effort. The PMI process, Managing Stakeholder Expectations, is mostly about Change Management, in spite of not being specifically identified as such in PMBOK. (PMBOK is  PMI’s Project Management Book of Knowledge. It is a book which presents a PMI’s definitions of project management terminology and guidelines.)

Even though the project documentation may, for example, specifically describe a data input screen in terms of its fields and functions, if, after Go Live, Stakeholder B  thinks that the font size on that screen was too small to be readable, then that stakeholder will be unhappy. He might describe the project as having “failed”. So whose issue is this?

Stakeholder B might have chosen not to fully participate in the interface review or acceptance, but that doesn’t change how he feels.

Regardless of the stakeholder’s abdication of his responsibility to review the interface, it is still the project team’s responsibility to manage that stakeholder’s expectations through meetings, demonstrations and, if necessary, one-on-one discussions.

Change Management is not just about controlling scope, it’s about communications, managing expectations, education/training and it’s about helping the user community and stakeholders adjust to the changes that the new process or product might bring to their organization.

When changes occur too quickly or too dramatically, stakeholders may have problems integrating the changes into their business processes. Regardless of whether a project met its goals (definition of “success”), it could still be considered a “failure” to the user community and stakeholders if they can’t effectively integrate it into their operational processes.

“Success” may be in the eyes of a project team or project sponsor. “Failure” is commonly in the world of the end users and stakeholders. At project closure, if the users aren’t satisfied with the end product, regardless of what a contract or requirements document might say, that “successful” project might still be viewed by them as a “failure”.

That’s not fair!

The project manager and team had worked hard to deliver on scope, on time and on budget. It’s not “fair” that someone is saying that the project is a “failure”? This is one case where perception really is reality. The PM can try to convince the stakeholder that he’s wrong, but it’s very difficult to argue with a “perception”. Pushing facts toward a stakeholder with a bad perception of project delivery is generally a losing battle. Perceptions are often based more on emotion, than fact.

The best approach is one that should have been taken much earlier in the project … communicate with the stakeholders. “Communicating” means more than distributing information at a meeting or via email. “Communicating” includes the delivery of information AND the confirmation that the information has been received and understood.

Managing Stakeholder Expectations is not just sending out emails. It’s engaging the stakeholders in active discussions of the project scope and the requirements. It’s about understanding their perceptions of what the end product or service might be. It’s confirming or correcting those perceptions long before Go Live.

If, after the scope definition discussions, there is still a significant gap between the documented requirements and what the stakeholder(s) understand is to be delivered, then the Change Control Process component of Change Management should be engaged. The Change Control Process moves the project team out of the line of fire and the perceived scope gap becomes an question of money and schedule.

Start Change Management processes early and continue them throughout the project. It’s always better to confront a problem head on than to allow it to grow and fester into a more significant problem that is difficult to effectively address later.