Skip to main content

Author: Kevin Aguanno

Why do Most Project Managers Fail?

Written by Kevin Aguanno on . Posted in Articles. 4 Comments on Why do Most Project Managers Fail?

I spend a portion of my time recovering troubled projects or helping project managers avoid traveling down the road towards a troubled project.  In doing this, I keep making the same observation over and over again:  most project managers are failing.

To better understand why I am saying this, we’ll first have to understand what I mean by failure.  Most people understand the basic premise that project management success consists of two things:  a successful outcome, and a successful journey towards reaching that outcome.  If we could even get project managers to focus on only those two elements, I think we’d be improving our overall success rates and the perception of the profession in the business world.  However, many project managers think about project management success as consisting of having a good plan, and following that plan, while staying on time, within budget, and with acceptable quality.  I agree that for many projects, doing those things alone would be a huge improvement and may, in fact, be very difficult to achieve.

I have a more mature view of project management success, however, one that considers many factors:

  1. Product Success – Does the product or service produced by the project meet the functional and performance expectations of the project sponsor?  Does it satisfy all of the key needs and has it been launched in a way that ensures a smooth transition with all applicable support structures in place?
  2. Project Success – Does the project stick to the costs and timelines outlined in the business case?  Did the project capitalize on opportunities for improving the business case through discovering and applying innovative approaches, optimizing processes to maximize the delivery of business value, and adhering to the technical, procedural, and other constraints?
  3. Relationship Success – During the course of project delivery, did the project manager maintain a good relationship with the project sponsor and extended list of project stakeholders?  It is no good to deliver a good project on time and on budget while building animosity with the sponsor and stakeholders during the process.
  4. Project Team Success – Were the task assignments, work locations, and other decisions made with the needs and preferences of the project team in mind?  Was the project managed in a way that allowed for some work-life balance for team members?  Were work hours reasonable?  Did team members have a say in how their work was estimated and planned?

Taking these last two factors into account significantly broadens the scope of a project manager’s domain of responsibility.  You cannot say that project management was successful if the team was burned out and demoralized, or if the project sponsor was angered so much that he or she won’t work with the project manager again.  One really needs to consider these additional success factors when planning a project.

Now that you understand my broad view of project management success, you’ll better be able to understand my earlier comment that most project managers fail – they just aren’t thinking broadly enough.  Most project management texts that I’ve read don’t go into this level of detail – even the PMBok Guide published by the Project Management Institute does not define either project success or project management success, though it does say that project objectives must include at least cost, schedule and quality elements.  So, it’s no wonder that there is some confusion over what elements should be included.

For those of you willing to look outside of the PMI empire for good ideas, the International Project Management Association (IPMA) publishes a standard called the International Competence Baseline (ICB).  The current version (v3) includes a definition of project success (“the appreciation of the various interested parties of the project outcomes”) and a definition of project management success that makes up one of twenty project management technical competencies described in the international standard, along with fifteen behavioral competencies and eleven project contextual competencies.  The ICB states that a project that is terminated (i.e. it has failed) could still achieve project management success if the appropriate management processes were used to trigger the termination decision and to control the orderly shutdown of the project.  The IPMA is clearly taking on a broad view of project management success, one that is much broader than PMI’s nine project management knowledge areas covered in the PMBoK Guide. 

Regardless of whether you follow the PMI or the IPMA standards, a broader, more holistic view of project management success is necessary to ensure that you are taking all of the relevant factors into account when you are planning your next project.  Take the time to think through all four success elements, and you will find that your project may go more smoothly with a greater chance of being considered successful by all relevant parties.

Don’t forget to leave your comments below

Is There Any Value to PM Certification?

Written by Kevin Aguanno on . Posted in Articles. 1 Comment on 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

The Change Control Myth

Written by Kevin Aguanno on . Posted in Articles. 3 Comments on The Change Control Myth

You can always spot the project managers who have just received their PMP – they are eager, idealistic, and prone to proclaim at length the necessity for “Change Control” as if it were the cure for all project management evils.  Don’t get me wrong – I am glad that the level of training that new project managers receive is increasing, and I am glad that they are learning that change can derail a project. However, new PMs appear to have a naïve view of how projects work in the real world, and I would like to do my part to correct that.

To start with, there is NO SUCH THING AS CHANGE CONTROL.  Yes, you read that correctly.  The idea that we can control change is a myth.

I’m well into my second decade of being a PMP, and I’ve taught project management for almost as long as that, so I am quite familiar with what PMI tells us in the PMBoK Guide.  The book is filled with the words “change control” with the phrase appearing in most chapters.  Yet, if you read the description of change control, say for example in section 4.3 (Overall Change Control), you’ll see that what they are really talking about is change management. 

Now, I know this sounds picky, but the distinction between the words control and management is very important – the word you use can affect your thinking and drive very different behaviors.

There are many sources of change, some generated from within the project, and some generated from outside the project.  Let’s look at how we should respond to these under normal circumstances.

External changes come from stakeholders and others who are not part of the core project team.  Some examples of external changes could be new government regulations with which we must comply by a certain date or face severe penalties; new corporate leadership with a different vision/strategy for the organization that no longer includes our project, or a competitor beating us to the marketplace with a new product that has more features at a lower cost than the one being produced by our project.  In each of these cases, the project manager (even the project sponsor) will have little control over these changes. The change just happens and we have to learn to adapt to it quickly.

Internal changes come from core project team members.  Sometimes we have a small measure of control over these changes, but other times, we do not.  Examples of internal changes to a project could be a core project team member having to take a sudden medical leave; team members realizing that the product or service that they are producing or modifying is much more complicated than they at first thought; the project sponsor asking for a new feature that was forgotten during the requirements gathering phase of the project; team members suggesting changes that would greatly improve the functionality or performance of the product or service being built, or even design defects uncovered during later testing stages in the project that require the team to go back and redesign a portion of the solution, then rebuild and retest the solution to match the updated design.  Each of these internal changes can also generate significant chaos on a project if they occur without any restraint.

So, realizing that we cannot “control” most of these types of changes, we need to find a way to make sure that unrestricted change does not completely derail any chance of our project meeting its business case.  If we cannot control then we at least must manage.

Change management can be done in a number of ways, and there many tools that have been developed to help.  Traditional approaches to change management are discussed in the PMBok Guide, including having a system of formal, documented procedures that describe how a change will be assessed and approved within the project, usually by a “Change Control Board.”  Other approaches used in agile management methods include having a prioritized list of project scope items that can be easily updated and reprioritized before any iteration of the project, ensuring that the team is always working on the next most important outstanding pieces of work.  Of course, there is usually still a formal signoff of this modified scope list, but the underlying concept that scope will be fluid during the project, and providing formal mechanisms for managing the dynamic scope, are quite useful on high-change projects.

Perhaps the most important difference between “change control” and “change management” is one of attitude.  The term “change control” is often found on projects that are being managed using deterministic planning models such as the ubiquitous “Waterfall Method” – a sequential series of gated phases within which all work must be completed before we can move through the gate to the next phase.  Deterministic models try to create a “perfect plan” and then the rest of the project is spent trying to adhere to the plan.  In fact, most project tracking and control metrics found on these projects are measuring how well the project is doing in relation to the plan.  For example, Earned Value metrics track our variance from plan and use these metrics to try and reforecast the impact of this variance on the project end date and financial spend.

Change management is the term found most often on project managed with empirical methods.  Empirical methods recognize that there are often too many variables on a project for a project manager to control them all.  These methods permit a tolerance range for the variables, and monitor them to ensure that they stay within acceptable boundaries.  In essence, these methods are accepting that there will be ongoing and frequent changes within a project, and that changes are allowed – even encouraged – as change helps the project deliver the optimal level of business value.  Examples of empirical management methods include the agile methods Scrum, Feature-Driven Development, and Lean Development.

Lastly, the attitude of a project manager may be affected by the terminology used.  Change control sets up (at least in new or junior project managers) a confrontational mindset that tends to see project managers trying to stop or discourage change, often to the annoyance of business stakeholders who are trying to adapt to a changing business environment.  More senior managers tend to take a more collaborative approach towards working with the project sponsor in determining how best the project can adapt to new changes. These managers understand that the real game is one of change management not control.

Change can be good – we need change to allow us to incorporate lessons learned from earlier stages in the project; and adapt the scope, timeline and budget of the project to match evolving business needs This ensures that we are delivering the optimum level of value to the project sponsor within our project constraints.  What we need to do is manage the process of how we adapt to the changes to ensure that we are always focused on delivering this optimal level of value.  It is not a perfect science; there is a lot of uncertainty and predicting the perfect answer is not possible. However, there are change management techniques that will allow us to stay responsive to internal and external changes while still keeping the project performing within acceptable parameters. 

As professional managers, we need to understand the range of tools and techniques available to us for both deterministic and empirical project management environments, and to know which ones to use for a given situation.  Our basic project management training, and even the  PMBoK Guide, is lacking in some of this sophistication.  We need to begin teaching the next generation of project managers about how we respond to change in the real world – a management paradigm that works collaboratively, not confrontationally, with project stakeholders.  Remember:  without change, many projects will surely fail.

Don’t forget to leave your comments below

Project Managers Can Shine in Today’s Tough Economy

Written by Kevin Aguanno on . Posted in Articles. 3 Comments on Project Managers Can Shine in Today’s Tough Economy

In service companies, people have characterized sales people as the ones who bring in revenue to a company, but project managers as the ones that translate that revenue into profit.  Project managers are the ones who lead in the creation of value for project stakeholders.

Yes, I admit that, in most projects, project managers are not creating deliverables that will drive business value for their clients. However, project managers are the ones who focus the rest of their teams on the right goals, and then lead the team on a journey towards meeting those goals.  If the right goals are chosen, then incremental business value can result from the project.

In an economy where the word “recession” has been in the headlines for the past two to three years, using incremental business value as the measure of project success has become more and more common in the marketplace.  Project managers are being asked more and more to track financial benefits along with financial costs, and to document business case justifications inside their change authorization forms.

While the ability to read business cases and financial statements has always been required of senior PMs, the requirement that PMs create these documents and link business benefits to business strategy is more recent.  In my experience, I have seen that the extreme emphasis on business value can be linked to economic cycles:  when times are good, more projects get approved with “soft” benefits like improvements in customer service; while in hard economic times, projects need to deliver “hard” benefits, valued in dollars.

But aside from juggling the numbers in various reports and documents, how else does this affect the role of the PM?  I believe that economic downturns allow the more experienced, “senior” PMs to differentiate themselves from those more junior – specifically in the area of business strategy.

I like to work directly with the project executive sponsor as a partner in helping them to make their business case a reality.  This partnership paradigm is not just a feel-good word – it drives significant behavior changes.  I believe that what distinguishes the very best PMs from the rest of the crowd is this partnership mindset.

Being a partner to the project sponsor means that I will be their trusted advisor in providing opportunities (or alternative approaches) for the project that will help him or her achieve project goals, in the most effective way possible.  This improved effectiveness is measured using phrases like increased return on investment, lower project risk, better integration with external projects, etc.  To communicate these benefits to the sponsors, project managers must stay away from jargon like “earned value” or any of the technical terms used by the delivery team: talk to the sponsors in their own (business) language.

On technology projects, this is critically important.  The technical jargon and technical issues can overwhelm business executives who don’t have the background to be able to understand the implications of many of these terms in order to make appropriate decisions.  As a result, when they have had technical issues discussed with them in the past (using technical terms) they don’t understand the underlying message, and as a result they experience “surprises” later when the true impacts of the issues arise.  I’ve heard many executives talk with deep disappointment about “technology projects that always take far longer and cost much more than originally planned.”  With frequent cost overruns, executives have lost confidence in their delivery teams (and with good reason).

To reestablish trust with the business, technology delivery leaders need to learn to speak in the business’s own terms.  In effect, use “MBA-speak” – the jargon of the business world.  By speaking in business terms and taking the time to truly understand the business case behind the project, the PMs will soon be seen as “peers” of the sponsor, and soon can move towards being seen as a “partner” in helping the sponsor achieve his or her goals.

Another technique I use to speed up the process of being seen as a partner is to seek out the hidden agenda of the sponsor.  In other words, to uncover what personal objectives the sponsor would like to achieve alongside the project objectives.  I explain that I can plan a project a hundred different ways that will each achieve the project goals, but only some will help the sponsor achieve his or her own personal goals.  By having a frank discussion about his or her own performance measurements, commitments they made to their boss (or that their boss has made) and other similar items, I can present strategic options for structuring the project to make the sponsor more successful in their personal or career endeavors.  This will help build long-lasting, partnership-based relationships that can last across multiple projects.

In a down economy, companies are looking for ways to cut costs – often including the dismissal of underperforming staff.  As a project manager, your own performance may be measured based upon the success of your projects and the happiness of your sponsors.  And experienced PMs know that building a strong relationship with a sponsor can mean the difference between project success and project failure.  By taking the approaches mentioned above, you can position yourself as the trusted partner – one who is too valuable to consider dismissing – and better protect yourself from downsizing during a recession.

Don’t forget to leave your comments below

What Value Does a PM Provide at the End of a Project?

Written by Kevin Aguanno on . Posted in Articles. 4 Comments on What Value Does a PM Provide at the End of a Project?

The other day, I was challenged by a client to provide a description of why they still needed a PM at the end of their project. To understand their question, and my response, you need a bit of background information first.

This software development and package integration project had been running for several months, had completed the installation, custom development, and integration testing. Nearly all of the project team had been released from the project: only the lead programmer and a part time solution architect remained to deal with any issues arising during user acceptance testing (UAT), to answer questions from the client’s technical team who would be supporting the solution after the end of the project, and to provide some knowledge transfer to the client’s team on how to use the custom software solution. With such a small team (1.5 FTEs), low risk for failure, and only a few items left to complete with adequate hours remaining in the budget to complete them, the project was in a very enviable position.

The problem was that the schedule had been extended and, while there had been additional hours added for programmers to develop and test new functionality for the custom application, additional project management hours were not added with each change authorization signed between the two parties. Instead, with only a couple of project management hours left in the contract, I was negotiating with my client to have additional project management hours added in another change authorization.

The client refused the suggestion of additional project management hours, saying “We have our own project managers handling our portion of the project deliverables – they can also manage your two team members, in addition to their current teams, meaning that we don’t need any extra project management time from you.”

How do you respond to a statement like that? I suggested the following items to the client’s senior management chain:

  • Relying on Vendor Responsibility. The client had chosen my company as the vendor of services for this project because of our solid reputation in the marketplace and our long list of references. They were not just hiring a few of our staff members in a staff augmentation (a.k.a. “body shop”) mode; rather, they were buying our overall organizational expertise, tools, and processes to help them through the project. If they were to proceed without a project manager, and manage the resources directly, the client would in effect be absolving our company of further responsibility for the project, as our project manager ensures that issues of risk, governance, and our organizational commitment are being dealt with appropriately, including internal escalations, if necessary. With staff augmentation arrangements, such organizational commitment and responsibility rarely enter the relationship.
  • Financial Reporting Support. This client had asked several times during the project for financial reconciliations such as invoiced hours versus hours authorized in signed contracts and change authorization forms. As the project manager, it was my duty to provide this information to the client, whether I provided the information directly, or through an assistant. The programmer and solution architect remaining on the project would not have access to the correct systems to access the information required to respond to these requests.
  • Negotiating Changes. As we were in the final stages of the project (user acceptance testing and then deployment), issues and defects were arising that could have broader implications for the project as a whole. For example, one performance issue had a number of possible resolutions that needed to be evaluated, each with its own cost and benefits that needed to be discussed in detail with the client before a decision could be made. Neither the developer nor the architect had a technical focus, but the business impact of these resolutions spread more broadly than the technical impacts, and these technical resources didn’t have the business acumen to recognize or to communicate these impacts effectively with the business stakeholders. Finally, as the services vendor, we would need someone delegated with the authority (and with the right skills) to negotiate a solution that worked for both parties, including writing up the change, gathering estimates, calculating cost and schedule impacts, and getting the agreement signed by the right authorized parties. The technical people assigned to the team did not have these skills, which are typically found in project managers.
  • Focus on Customer Satisfaction: The personal performance of the resources left working on the project is measured with productivity metrics (like percent of worked hours billable to clients). This drives a certain behavior that is desirable in people building deliverables for a client: a single-minded focus on completing the solution. What is missing, is someone focused on customer satisfaction. In most organizations, customer satisfaction is used to evaluate project managers, who tend to have the most face-to-face interactions with senior business stakeholders (sponsors). The vendor’s sales staff (called “relationship managers”) are focused on customer satisfaction, as that is how they drive future sales; however, they are not typically focused on delivering contractual obligations and usually don’t have the authority and resources to make that happen. As the project manager tends to have stronger relationship-building skills, and the authority to shape the project processes to better influence customer satisfaction, it is in the client’s best interest to ensure that they still have some hours in the project for the vendor’s project manager.
  • Internal Escalations: Some issues and defects that were arising (and that would likely continue to arise as the project moves through UAT and into deployment) would require the coordination of vendor, customer, and subcontractor resources. This requires someone like a project manager who has experience navigating the vendor’s organization and who has familiarity with the vendor’s management processes and also the procurement (subcontractor) management processes.
  • Managing Vendor Resources: Even though the client thinks they can manage the vendor’s two project resources, what they are referring to are the work assignments and timing of delivery. There are other aspects to managing the vendor resources that they won’t want to do or cannot do: resolving personnel performance problems, approving vacation schedules, acquiring additional (or replacement) resources, resolving conflicts with the other projects being worked on by the part-time solution architect, etc. In many organizations, project managers take on broader human resource management roles than just task assignments.

So, even in the final weeks or days of a project, when most of the work has been completed and most of the team has been released to other projects, it is in the best interests of the project sponsor to retain the services of a project manager from the delivery organization.

Don’t forget to leave your comments below