Skip to main content

Author: Kevin Aguanno

What’s New in Agile Project Management Certifications?

There’s lots of buzz in both the project management and agile communities recently with the announcement from PMI that they are launching a new agile certification. Questions abound:  what are the PMI agile certification requirements, how does this compare to the Certified ScrumMaster (CSM) or Certified Agile Project Manager (Cert.APM) qualifications, when can I apply, and many more.

PMI has provided some guidance on the process and requirements, but much is still currently unannounced as they are finalizing the details.  A pilot certification round is starting imminently with a full rollout this summer – the exam should be fully available through Prometric Testing Centres in September 2011 with the application process starting in May or June.  In the mean time, Internet discussion boards and chat rooms are filled with speculation.

What we do know for sure is that to become certified, you’ll need to pass a 3-hour multiple-choice exam on agile management with 120 questions, of which only 100 will count towards your score – the other 20 are experimental questions being considered for future exams.  The exams will be available via computer or paper at Prometric Testing Centres, the same as the PMP or other PMI exams. 

For educational requirements, you’ll need to complete a minimum of 21 hours of agile-specific training in addition to having a basic high-school diploma (at a minimum).  So, if you are CSM who has just completed the basic 2-day Certified Scrum Master course, you’ll need to go out and get an additional day of training.  This is probably a wise thing to do anyway, as the exam will cover a lot more than just Scrum practices.  For example, the sample questions that PMI has on their web site includes questions from Extreme Programming (XP) and Scrum, plus many questions that are outside the scope of pure Scrum, such as the construction of release plans.

There are also experiential requirements.  A candidate must demonstrate 2,000 hours of working on project teams in the last five years (not necessarily as the project manager – just working in a project environment), plus 1,500 hours of working on agile projects in the past two years.  PMPs will skip the 2,000 hour requirement, but must still meet the 1,500 hour requirement.  This agile experience presents a significant hurdle that will prevent many people (including new CSMs) from earning the PMI certification.  It is not just a test of agile knowledge, but rather you’ll need to demonstrate experience as well.

How does this stack up against the other agile certifications?  Take a look at the table below:

Agile Certifications

Certified ScrumMaster (CSM) Certified Agile Project Manager (Cert.APM) PMI Agile Certification (name still to be finalized)
Minimum Education None None High School
Mandatory Minimum Agile Training 2-day CSM course 3-day PMAC-accredited agile PM course 21 hours of agile training
Minimum Project Experience None 1 year as project manager 2,000 hours in last 5 years as project team member
Minimum Agile Experience None None 1,500 hours in last 2 years as agile project team member
Exam Length 25 multiple-choice questions in 1 hour 40 multiple-choice questions in 2 hours 120 multiple-choice questions in 3 hours
Passing Mark Not applicable – everyone who writes the exam earns their CSM regardless of score 70% Has not been announced
Certification Fee $50 (usually included in mandatory course cost) $100 (usually included in mandatory course cost) $495 (computer-based test) or $445 (paper-based test) $60 discount for PMI members
Certification Validity Period 1 year For as long as holder is a member of PMAC. 3 years
Recertification Cost $75 Not applicable (Membership varies from $25 to $100 per year) $130 plus 30 additional hours (PDUs) of agile-specific training

Initial observations show that the Certified ScrumMaster credential is not on par with the other two certifications.  Not only does it have low-to-nonexistent educational and experiential requirements, but its exam is not credible if everyone who attempts the exam gets their Certified ScrumMaster designation even if they don’t pass the exam.  The CSM credential is offered by the Scrum Alliance.  They state right on their own web site:  “Once you have completed the evaluation you will be granted Certified ScrumMaster status regardless of your score. If you score poorly, however, you will receive feedback detailing where you are deficient and what resources you should study to improve.”  The CSM certification was criticized in the past for not having an exam at all – this new approach does not make much of a difference if you get the certification even if you fail.  On the strength of this last point alone, those interested in agile certification should focus on the other two options.

Overall, the new PMI agile certification compares favourably with PMAC’s Certified Agile Project Manager.  Both require 3 days of agile-specific training, both require about a year of project experience, and both have a multiple choice exam (though PMI’s is longer).  The key differences:  PMI’s exam requires agile project experience (which may exclude many potential candidates) and it is much more costly to obtain (almost five times more expensive) and more costly to maintain.  Still, with the marketing might of PMI behind the exam, it should quickly catch on. 

Those interested in obtaining agile project management certification should put acquiring the new PMI agile credential on their long-term career development plan.  In the short term, the Certified Agile Project Manager credential from PMAC is a great interim step.

One should not forget the Certified Senior Agile Project Manager (Sr.APM) credential from the Project Management Association of Canada that was launched this year.  It takes an even more rigorous assessment approach than any of the three certifications mentioned above.  For this more advanced certification, candidates need to prove that they have competently managed agile projects in the past.  To assess the competence of the candidates, the PMAC looks for:

  • understanding of agile practices as evidenced by obtaining the Cert.APM qualification
  • feedback from team members to see if the candidate can effectively lead a team
  • feedback from sponsors to see if the candidate can manage stakeholder relationships effectively
  • evidence of sound agile practice through the presentation of agile project artifacts (release plans, backlogs, burndown charts, etc.)
  • a detailed project report describing how specific agile practices were applied on a sample project, and
  • demonstration of the necessary soft skills through a face-to-face interview.

With all of these elements, it is clear that this last certification is more costly and time-consuming to achieve.  However, it is clear that the Certified Senior Agile Project Manager credential is the gold standard of agile project management certifications.

Don’t forget to leave your comments below.

Project Management Advice from Popular Music

I was sitting in a project team meeting yesterday where a group of us were trying to figure out the right strategy for dealing with a difficult project sponsor.  The issue was that the scope of the project was constantly changing and we were being rebuffed by the sponsor when we tried to point out that our requirements gathering and analysis budget was already spent, yet new requirements were popping up daily.  The sponsor was saying that they need all of their requirements documented and the impacts on the solution design analyzed – which is correct; however, the sponsor is not willing to reallocate funds from the solution build budget to the requirements budget, nor is he willing to discuss adding funds to the project overall budget.        

To make matters even more difficult, the last time we approached the sponsor to make him aware of the impact of this ongoing requirements churn on the project budget and timeline, he escalated to our sales team to complain that we were upsetting him and not doing our proper jobs by managing the project within its constraints.  The sales team members in our meeting (who own the overall customer relationship) were insisting that we find a way of continuing the work without highlighting the budget issues.  In essence, they were arguing that we should hide the fact that we are going to use up so much of the overall project budget during this requirements churn that there may not be enough left to build a viable solution.  They were telling us not to speak with the sponsor further on this issue.

While this was going on, I heard the chorus of a song by Des’ree running through my head:

You gotta be bad, you gotta be bold

You gotta be wiser, you gotta be hard

You gotta be tough, you gotta be stronger

You gotta be cool, you gotta be calm

You gotta stay together…

I was immediately struck by how these lyrics could have been written for a project manager.

Being strong and tough while still keeping a calm and cool demeanor would be very useful in our situation.  We needed to stand up to the salespeople while not seeming to be unreasonable and too confrontational or difficult to deal with.

So, I took a deep breath, gathered my courage (was bold), and I started to push back (was tough).  I used logic (wisdom) to highlight the negative outcome of their approach.  I did not let their numerous interruptions and attempts to redirect the conversation divert me from explaining my position (was strong), and did all of this in a calm, level-headed (cool) manner.  Basically, I followed the advice of the song.

The delivery team was behind me and soon heads were nodding and supportive comments were coming from all members of the group.  They saw what I saw and were equally concerned about getting the project back on track.  All they needed was someone to follow, someone to stand up and lead them into confronting the dysfunctional approach promoted by the salespeople.

The more astute of the two salespersons quickly dropped his argument when he saw that the majority were behind me and that my arguments held up against their objections.  He eventually sided with reason and good practice.  The other salesperson continued to push his own dysfunctional approach for a while until he realized that he was the only holdout in the room.  At that point, he quickly changed his approach to match ours, but tried to make it look like our approach was his idea all along.  I wasn’t concerned about who got the credit for the idea – my self-esteem didn’t need the ego boost – so I let him save face by claiming credit in front of the group.  (It really didn’t matter, since they all saw how things had unfolded; he wasn’t fooling anyone but himself.)

In the end, if all worked out. The salespeople agreed to the approach that the team had initially proposed.  They agreed to meet with the sponsor and explain that the requirements churn on the project was consuming solution development funding and that he needed to be aware of this.  They agreed to propose that the project pause for a while until the sponsor can decide what to do about all of the changes being proposed by the various involved stakeholders – after all, the budget can only accommodate a small fraction of the work required to build a solution which  meets all of the newly-emerging requirements. They also aggred to get the sponsor to formally sign off on a re-allocation of funding or additional funding before the project resumes.

I guess it pays to be bad, bold, wiser, hard, tough, stronger, cool, calm and together.

Don’t forget to leave your comments below.

Testing Strategy is Critical to Project Success

I once heard the president of a large company say that sales people were important because they increased the revenues of the company but that project managers were more important because they turned those revenues into profits.  And those profits, he noted, drive an increased share price (the value of the company in the marketplace).

If we as project managers are responsible for the creation of a company’s value, then we have a professional obligation to perform that job well, as the converse would also be true:  project managers performing poorly can also destroy a company’s value.  How do we perform our job well?  To answer this, we need to look at which project management activities have the greatest impact on achieving the project’s desired outcome, as valued in the business case.

I personally believe that the two most critical contributors to achieving project business case outcomes appear at the start and end of our project lifecycles:  good requirements analysis, and the strategic application of testing activities.  The two of these combined ensure that the project is focusing on creating the right outcomes and that the project is verifying or demonstrating that the outcomes have been achieved to ensure the delivery of optimal business value.

The key concept here is “optimization.”  Yes, many project activities drive value.  Some, however, have an incommensurate effect on the total business value delivered by the project when it is completed.  By conducting a Pareto analysis of the most common project activities, we see that creating the right outcomes (proper requirements analysis) and ensuring that those outcomes are achieved (proper testing) have the highest business value to effort ratio.

Of the two, I believe that testing gives you the biggest lever.  Yes, proper requirements are important, but typically requirements-related activities are only a small portion of the overall project activities and happen at the beginning of a project when everyone – including the business people involved – understand the project environment the least.  Testing, however, happens mostly near the end of a project where there is much less uncertainty about what are the desired project outcomes.  Testing activities (and the related defect correction efforts) are what determines whether or not the project has been successful.  If inadequate testing is performed, then the outcomes created earlier in the project will not drive the proper (or possibly any) business value.  Quality assurance (testing) is one of the most critical activities for achieving project success.

Similar to under-testing, there is a danger of too much testing, too.  We need to find the balance between additional testing and the delivery of an equal (or greater) proportion of business value.  At some point during the testing process, additional testing effort will not create enough additional business value to justify the extra expense.  A strategic approach to testing needs to be considered by the project manager when creating the initial project approach.

Here is where another Pareto analysis may come in handy.  Consider all of the types of testing that we can perform on a project:  usability testing, accessibility testing, performance testing (including load and scalability), functional and systems integration testing, disaster recovery testing, etc. – on an individual project, some of these will drive more value than others.  We need to consider the business case behind the project to know which types of testing will drive the most business value.  For example, perhaps a given project requires rock-solid 24×7 performance or else the business will suffer; in that case, disaster recovery testing may drive a measurable amount of business value, while it may add little value in other, less mission-critical projects.  We cannot take the same testing approach on every project – we absolutely need to tailor our testing activities to the individual needs of each project’s business case.  In other words, it is essential that we consider testing strategy when we begin planning our project.

So, when that company president said that it was project management that drove business value, I believe that if we had the chance to dig a little deeper discuss what was underlying that comment we would have heard that the project manager’s responsibility for project value includes building the right things and then verifying that those things meet the business case needs.  And a disciplined focus on testing strategy will ensure that the project has created the planned business value, with the right test strategy ensuring that these validation activities have been performed in an optimal manner.

Don’t forget to leave your comments below.

My Project Management New Year Resolution

Jan12_PTBlog_AguannoAs it is January, I thought it would be a good time to share with you my project management New Year resolution.  But before I share it with you, I want to share an observation: if I could make up my own personality categorization system for project managers, I might say that there are two main types:  builders and maintainers. 

Builders are the project managers who love to manage projects that create brand new things:  shopping malls, online courses, software applications, new products, etc.  They are excited by the unexpected challenges they will face and thrive on the creative energy generated by the team.

Maintainers are those project managers who prefer projects where there are fewer “unknowns” and perhaps an overall lower risk profile.  These are projects updating, renovating, or maintaining existing products, buildings or systems rather than creating new ones. These project managers focus on optimization and efficiency as their main goal.

I would imagine that the New Year resolutions of these two types of project managers would be very different.  New Year resolutions tend to say that we will begin exhibiting some positive behaviour that we probably should be doing now but aren’t, or that we will stop a negative behaviour.  Builders (who are more interested in tackling challenges like project issues than in standard administrative processes) may have a resolution saying “This year, I will begin updating my project financial tracking spreadsheet weekly instead of monthly, just before the deadline.”  Maintainers (who tend to be more interested in using metrics to optimize the project process than in dealing with broadly-defined but imprecise strategic directives) may have a resolution saying “I will take the time to perform a formal stakeholder analysis at the start of all of my new projects, and will use this information when I craft the project approach.”

Now, let’s be practical.  I know that we should probably be doing all of these things all the time; however, in the face of day-to-day project pressures, and the common problem of not having enough hours in a work day, we have to let something slip.  What that may be depends upon our organization (what they measure), our project (what our customer wants), our team (how much direction they need), and our own personality (Builder or Maintainer).  The situation is not as simple as I may have made it sound above; however, I think that a project manager’s personality does have a strong influence on his or her choice of a project management New Year resolution.

My resolution:  to spend more time following up on action items assigned to team members.  I expect that, since we spend so much time trying to hire the right people for our organizations, that we have a pool of reasonably skilled, competent, and motivated people from which to draw our project teams.  I expect that people will keep their commitments, never lie, and generally try to cooperate with others on the team.  Basically, I expect everyone to act as professionally as I do myself.  Maybe this is a little too naïve – I have had a few disappointments over the years where others fail to live up to my standard – but I believe that most people mean well and will try to do their best.

My resolution will help me avoid some future disappointments by identifying those who are not meeting their commitments early on so that I can take action to avoid any major issues occurring.  It is easier to fix problems while they are still small ones rather than avoid them until it is too late to resolve them.

Based on my resolution, I am sure that you can guess my own project management personality type.  I am a Builder.  That means that I like dealing with “fuzzy” situations, project strategy, stakeholder relations, and project issues but I am less excited about the administrative side of my job:  issuing status reports, reviewing time sheets, financial tracking, sending out meeting minutes, etc.  Yes, I do these tasks, but to me they seem like chores – not something I look forward to doing, and a candidate for procrastination in preference for more exciting project challenges.

This year, I plan on focusing a bit more on the administrative side of my job.  I must find a way to make these activities seem fun.  Maybe I can “psych” myself up to looking forward to these activities.  Maybe I can repeat a mantra ten times each morning:  “I can’t wait to start working on this week’s status report!”  No, I don’t think this is working for me.  I guess I’ll just have to bear with it and force myself to do the work.  No one said project management was all fun.

Don’t forget to leave your comments below.

Project Startup Activities are Key to Success in Both Agile and Traditional Approaches

I recently attended the Business Analyst World conference in Ottawa, Canada. The audience was comprised of mostly (no surprise here) business analysts but also included project managers, technical leads, and a few project sponsors. What I found intriguing was that about one third of the track sessions were concerned with agile-related topics, and the buzz in the hallways between sessions and at lunch seemed to lean towards agile. I guess this means that agile is now solidly on the radar of the mainstream project community.

Having delivered a presentation and participating in a panel discussion on agile, many came to me during the lunch sessions and breaks to answer questions they had about the implementation of agile methods on real projects. A theme that commonly emerged was the chaos that project teams were facing in the face of inadequate project startup activities. Some believed that project startup work was essential to traditional (a.k.a. “waterfall”) approaches, while these activities were not required for agile approaches. Let me summarize for you the answer I shared over and over again during these discussions.

First off, for there even to be a project in the first place, some up front work needs to take place. For executives to approve the expenditure of resources on a project, they want to know three things: what are they going to get, for how much money, and when will it be delivered – the old iron triangle of scope, time, and budget. Typical governance policies in organizations will not allow a project to begin without appropriate approval, and those providing such approvals require this basic information to make their Yes/No decisions. Such decisions are usually based on some type of business case analysis. The level of rigor in developing the business case depends upon the size of the project, the organization’s industry, and its level of maturity. Generally speaking, however, the business cases should quantify the benefits expected from a project and the costs required to create the environment wherein those benefits can be realized. Using that information, a business executive can then decide if the project is “worth it” – i.e. do the benefits outweigh the costs enough to justify the risk and investment in the project. The work required to gather information on benefits and costs is required no matter which project delivery method is being used: traditional or agile. This information is needed to decide whether or not the organization should bother launching the project (traditional or agile) at all.

Developing the benefits analysis for a business case is one piece of work that I won’t go into detail here. The process is the same whether one is using a traditional or agile approach. Developing the cost case, however, differs somewhat.

A cost case is developed by gathering the prices of materials and labour inputs to the project. Labour input estimates from external vendors are usually provided in dollars, and internal service teams may provide their estimates in either dollars or hours/days. Regardless of whether these estimates are coming from internal or external service providers, think for a moment on what work is required to create them. In both cases, the underlying number is an effort estimate measured in hours or days. External vendors will then apply contingencies and multiply this by some type of cost rate in dollars. Effort estimates can then be translated into a project schedule/timeline. To come up with the effort estimate, however, requires a much deeper analysis.

A team being asked to estimate the effort to do some work first needs to understand the nature of the work (overall solution design or approach) and enough details (scope or estimating assumptions) about the work that they have a reasonable basis upon which to base their estimates. It is clear then that before estimates can be prepared, some amount of solution design work must be done; else, how will the team be able to prepare their estimates – they would not know what it is that they are being asked to estimate.

The overall solution design, in turn, is based on an even earlier analysis of requirements. We need to understand the business requirements that are driving the need for the project’s output in order to make sure that we understand all of the required aspects of the solution. These requirements can then be transformed in the context of an overall solution design into a list of solution features for which the project delivery team can then provide estimates.

Under most organizational governance models, all of this work is required to be completed before a project can begin. This work all leads to the completion of a business case that the project funding person or group within an organization needs in order to conduct a reasonable assessment and make its Yes/No decision on whether or not to proceed with the project.

The difference between traditional and agile methods is the level of detail that goes in to the preparation of the business case. Because traditional methods perform most of its analysis and design work up front in order to come up with a detailed project implementation plan, these methods need to spend a lot of time conducting detailed analysis in order to prepare a detailed business case. Agile methods differ in that they begin with only a high-level understanding of requirements and solution design before the team prepares rough estimates that can be put into an initial business case. Initial funding may begin with only a high level business case, but typically the detailed business case is required before the full project funding can be released. In traditional approaches, the detailed work is usually completed before developing the project solution can begin, while under agile approaches, the solution development work can begin right away and the more accurate estimates and plan are delivered after a prototype/proof of concept phase wherein the delivery team gains experience with the technology, the other team members, and the stakeholders before committing to a more firm set of effort estimates and timeline.

With the greater level of detail required, traditional approaches tend to spend more resources in preparing business cases for the Yes/No funding decision. Agile methods tend to work at a higher level of detail, avoiding deep analysis until just before the work on an element of the solution begins. This means that the organization can get to a Yes/No decision much more quickly and cheaply using agile methods. Yet, it is important to point out that a business case for an agile project still needs up-front requirements analysis and solution design, just at a higher level of detail.

Adequate performance on these project startup activities of requirements analysis, solution design, estimating and planning can mean the difference between success and failure on your project – regardless which delivery method (traditional or agile) that you use. If you are using traditional methods and do a poor job on your project startup activities, your estimates and plans will be wrong and your project will struggle right from the moment that real project begins. Similarly, and agile project that does not spend adequate time with up-front work (before the first solution development iteration) will not only have a difficult time getting funding approved, but also the team will struggle in trying to build the right solution and in providing meaningful tracking and forecast metrics to help manage the project delivery.

Many agile proponents minimize the importance of project startup activities to the overall success of the project. In part, this is due to the fear that teams will be tempted to do a full, detailed up-front requirements analysis and solution design, wasting resources on items that may change before they get implemented later in the project. In other words, they are afraid that teams will migrate back towards doing a big design up front (BDUF) – a less than agile approach. As a consequence of this, many inexperienced agile project leaders then try to launch projects without adequately performing the project startup activities, leading to failing or troubled projects and demoralized teams. Many organizations have attempted and failed at their adoption of agile methods for this very reason.

It is absolutely critical that our project leaders understand the differences in the level of detail required in traditional and agile approaches and to ensure that they expend the right amount of effort in these project startup activities. Failure to do so means that your project may not only be significantly challenged throughout its lifecycle but also its business case may never be approved in the first place.

Don’t forget to leave your comments below