Skip to main content

Tag: Methodologies

Is There Any Value to PM Certification?

isthereanyvalue1I have been asked to participate in a panel discussion at a conference on certification.  The session is called “There is NO Value in Certification!”  At first, I thought this statement was ridiculous, and couldn’t imagine too many people wanting to support this premise; however, as I have talked to people, I realize that this position is not too uncommon.

The main criticism that people have of PM certification programs is that the well-known ones (at least in North America) all seem to be knowledge-based assessments.  Yes, many of them (like the PMP) have experiential components, but the core of the assessment is testing whether someone has memorized material from a standard syllabus.

What this means is that the assessing body has verified that these PMs have acquired knowledge of a common set of project management terms, processes, and techniques.  What it doesn’t verify is whether a specific project manager is any good or not at the practice of project management.

Having a PMP, for example, was at one time a distinguishing mark usually held by more senior project managers.  However, over time, PMI very successfully marketed the credential to the point that now there are so many PMPs that having the credential no longer makes one candidate stand out more than the next – it sometimes seems that everyone has their PMPs these days.

So, if you are looking to hire a project manager or select a contractor who will be providing services to your organization, you would need something else to help you filter through the mountain of resumes of people with PMP after their names.  What the business world has been seeking for years – the holy grail of assessments, if you will – is a credential attesting to the competence of a person.  In other words, something that can say “this person is a very good project manager.”  Businesses want something that will help them choose the best, lowest-risk candidate, helping to ensure that their project is successful.  A competence-based certification can do exactly that.

PMI doesn’t do this kind of assessment.  In fact, these assessments are quite hard to find in most countries.  There are two main reasons more organizations don’t offer these certifications:

  1. They are very time-consuming and costly to do.  These are not simple multiple-choice exams.  To assess competence in project management, you need to look at how PM practices were successfully applied across multiple projects, including an examination of evidence, speak to project stakeholders and team members to understand the leadership and stakeholder management skills of the candidate, and even perform oral interviews in order to assess some of the soft skills required of competent project managers.  This process can take many weeks – even months – to get through.
  2. There is a fear of liability/lawsuits.  In a society that is becoming more litigious, organizations fear that if they take the time to certify that a project manager is competent, and then that project manager fails and demonstrates incompetence, that the certification opens up the certifying body to a possible lawsuit from the project manager’s employer/customer.  This concern may be greater in the USA where civil lawsuits are more common than in Canada or some other countries.

Europe took a lead position in providing project management competence assessments and has been providing them for decades, with an expansion to the rest of the world.  Founded in the 1960s in Geneva, Switzerland, the International Project Management Association (IPMA) establishes international standards for project management competency assessment.  Now, IPMA’s model of PM competence assessment is available in over 50 countries around the world, on every continent (except Antarctica!).  This competence assessment model has been made recently available in North America through the American Society for the Advancement of Project Management in the USA (www.asapm.org) and the Project Management Association of Canada (www.pmac-agpc.ca).

Some companies have even tried to create their own PM competence assessment models, with IBM and Siemens being two examples.  Interestingly, both companies

have international operations in countries where the IPMA PM competence assessment model is predominant in the marketplace.  To effectively compete for work in these countries, project managers must have a competence-related qualification.  These corporations have, out of necessity, adopted these models for their own project managers and have adapted the model to their own specific needs.

So, the whole discussion around the earlier question of “Is there any value to a PM certification” becomes a bit more complex.  Before we can answer that question, we need to know which type of certification – knowledge or competence – is being discussed.  While there is value in achieving many knowledge-based certifications, clearly there is more value in achieving a competence-based certification.  Not only will a competence-related qualification highlight the best project managers, but also the process of trying to attain one of these credentials naturally leads to a career-development roadmap wherein people move up through the stages in their career as their competence grows.

I guess I would have to say that I strongly believe in project management certification; but I would qualify that statement to say that by far the best value in certification is achieved only through competence-based certifications.

Don’t forget to leave your comments below

A Heavyweight Fight; Scrum vs. Waterfall

heavyweight1I think people like a good fight. Certainly the media seems to, as is evident in the world of politics, sports, and entertainment to name a few. In the world of business analysis the current fight seems to pit Agile methods against the Waterfall approach. For the next several blogs we’ll have a Scrum vs. Waterfall match. In corner #1, representing the Agile methods, we have the Scrum framework. In corner #2, representing Waterfall, we have the “traditionalists.”

Round One

Relative Sizing of User Stories (Scrum)

  • Tee-Shirt Sizes. For release planning we might use estimates of relative size. When less is known about the user stories (features or requirements) for a release, we can estimate using a broad brush approach. Based on such criteria as how complex we think the user story is, how much effort it will take, and the unknowns or doubt, we give it a tee-shirt size (XS, S, M, L, XL). We can then compare all the user stories and assign relative sizes. For example, we can take one user story and based on the above criteria assign it a tee-shirt size of “Large.” We can then compare all the other stories against this “Large” size and assign the relative value of each story. This relative size estimating can help the product owner (business representative) decide which user stories to prioritize for a release.
  • Story points. We can then assign each tee-shirt size story points based on an arbitrary scale, such as the Fibonacci number sequence (1, 2. 3, 5, 8, 13, 21…). If a user story is Medium, for example, we might assign 8 story points. If Large, 13. We can then translate the tee-shirt size of all the user stories into story points. It’s important to remember that these story points are still relative. It really doesn’t matter if a Small is 2 or 3 points, as long as it’s consistently applied.

Relative Sizing of Projects, Phases, Deliverables, Tasks (Waterfall)

For years we have used relative size estimates on traditional projects. I have found this most effective when actuals have been collected over enough time to have confidence in the numbers. While I have only used relative sizing on deliverables (such as a small, medium, or large report), I know of teams that have used them on the whole project, project phases and tasks. As with Scrum, we usually base traditional relative sizes on complexity, effort, and doubt (risk), as well as on the history.

Round 1: Scrum wins, but it’s not a knock-out.

In my experience using relative sizes on traditional projects is often done to short-change the planning process. With Scrum the relative size of the user story actually gets refined as it approaches the sprint in which it gets delivered. While some traditional teams have the discipline to refine the estimates (as a project manager, I always encouraged it), many more give in to management’s pushback about not changing the date, scope, or cost. Scrum processes, by their nature, encourage change and refinement; traditional processes do not always do so.

Round Two

Scrum Planning Using Delphi (Planning Poker)

 Planning Poker uses a kind of Delphi technique to reach consensus on the relative size of the user stories. Each person on the delivery team (but not the product owner) uses a special “deck of cards,” which can be an actual deck or pieces of paper. Each card has a number. If using the Fibonacci scale, the deck would have cards, each containing a number in the scale (1, 2, 3, 5, 8, 13, 21, etc.) going as high as desired. The product owner explains the details of the user story and at the count of three, team members turn over the card with the points they think most appropriate. For example, two team members turn over a 3, one a 5, two an eight, and one a 21. They discuss their reasons for “playing” their cards. Then at the count of three they turn over a card, the same or different from the previous round. Again, they explain their rationale. This process continues until consensus is reached.

Traditional Planning Using Delphi

The Delphi technique involves a group of experts providing their estimates anonymously. Like planning, poker, there are rounds. The experts provide their estimates anonymously. A neutral party collects the estimates, shuffles them, and silently reveals them to everyone at the same time. No discussion is supposed to occur. Rounds continue until consensus is reached.

On traditional projects I have tried using Delphi anonymously only once. It didn’t work. I have found the real power of Delphi is in the discussion of each person’s assumptions about the estimates, so as a project manager, I modified Delphi to allow discussions between rounds.

Round 2: Scrum wins, but again it’s not a knock-out. I love the Delphi technique. I love having the team reach consensus on estimates, whether traditionally or through planning poker. It provides team accountability for the estimate, and increases the chance of team and individual commitment rather than compliance. So what difference does it make whether traditional Delphi or planning poker is used? Everyone can understand planning poker. I have seen teams take to this technique immediately. So while Scrum makes things easy and practical, the traditional Delphi, including its name, feels arcane.

So, the current score is two zip. But the match is not over. Much more to come…

Don’t forget to leave your comments below

Ending the Methodology Wars

I was in a meeting the other day when I encountered a bizarre exchange between a project manager and her project sponsor. I followed up after the meeting with both of them individually to try and figure out what was going on behind the scenes. Clearly, such strange reactions indicated some political intrigue was brewing in the back rooms and hallways of the organization.

What came out of my investigation was a better insight into how poorly we communicate when discussing change initiatives – and most projects could easily be classified as “change initiatives.” The project manager and the sponsor thought they were miles apart in their perspectives and were arguing over their different approaches. The project manager, after assessing the unique characteristics of the project, strongly believed that agile management methods were best for optimizing the delivery of that project. The sponsor was concerned about governance, control, and risk. As a result, he went with the only approach that he knew that provided the maximum control: a serial/sequential (a.k.a. “waterfall”) approach to project delivery.

Ah, it was the old “waterfall versus agile” argument – many have seen this before in their own organizations. What was interesting here, though, was that what the two parties were saying about the other’s approach shone a clear light on the problem underlying the whole argument. The project manager and the sponsor were not arguing over methodologies; rather, they were poorly communicating their concerns (fears) about the project and their own hidden desires for what they want to get out of the initiative.

The sponsor had deep concerns about the ability of the IT team to deliver. In the past, they had surprised him on numerous projects with requests for additional time and money due to a range of reasons that he felt they should have been able to predict better: unstable technologies being used, inadequately-skilled resources assigned to the project, the impact of assigning people to multiple simultaneous projects and the conflict in priorities that this creates for them on a daily basis, significant design defects uncovered late in the testing cycle at the end of the project, and many other examples. In short, the sponsor had no trust in the IT team. As a result, he wanted to fall back on what he knows best: a strong command and control approach to this mission-critical project. So, he was trying to impose a sequential phasing approach, with management stage gates for control points, and requests for detailed plans up front that incorporated risk mitigation activities and accounted for all of these possible problems.

The project manager, understanding the critical nature of the project, wanted to ensure a quality delivery in the most efficient way possible. She used agile approaches for the benefits of continuous prototyping and testing flush out any serious defects early on in the project, with lots of time left to correct them and still make the delivery date. She also liked the ability of the agile approach to minimize overall project risk on such a complex initiative. In the past, when her IT team had tried to do an up-front design for a similarly-complex system, the team got mired in trying to come up with a “complete” design, when the detailed requirements were still emerging. She saw agile methods as a way of dealing with the change and the complexity of the solution.

What really struck me as interesting was that both parties wanted the exact same things: a reduction of risk, a high-quality output, and the completion of the project in a relatively short period of time. What was underlying the argument was a misunderstanding of each others’ terminology and unstated desires. Let me address these separately.

If the two parties trusted each other enough to share what they really hoped to achieve with the project – on a personal level – then they would have more quickly come to agreement on the approach. The sponsor had made commitments to his own boss about the quality of the product and about the final delivery date – which was tied to his own performance review – so he was fearful about schedule delays, which was why he was insisting on so much up front planning and management involvement; he wanted a level of comfort that his commitments could be met. The project manager was using agile methods that would likely deliver a higher quality output. And agile methods, by building in short iterations and always working only on the next most important items, would ensure that if problems arose and something had to give to make the sponsor’s key deadlines, then the scope items to drop would be naturally the sponsor’s lowest priority ones (especially if his performance bonus was on the line).

The terminology differences would perhaps be easier to resolve. The sponsor was concerned over the use of extreme programming (XP) techniques on such a critical project. In his mind, he didn’t want anything “extreme;” rather, he wanted stable, predictable, and guaranteed. As soon as the word “extreme” gets mentioned, his back goes up and his fear increases. Instead of continuing to push the use of XP, the project manager should have discussed the practices in XP that would minimize risk, improve quality, and improve communications and visibility thereby addressing the concerns of the sponsor. We often get caught up in the extra meanings that we layer on to words and end up dealing with the emotional response which clouds our rational thinking. We need to be aware of this issue, and take care in choosing our words. My advice to the project manager would have been to suggest that she focus on the business benefits of the various practices, describing them in non-technical business-stakeholder-friendly terms. In that way, she would have been talking in her sponsor’s own language, describing how she is addressing his personal concerns, and showing how his business case needs were being addressed.

So, these methodology wars that we come across in our organizations can be avoided. We just need to be more careful with our communications. In the end, both parties usually are trying to achieve the same thing.

Don’t forget to leave your comments below