Consulting Journal: Methods - Effective project champions

Methods: Effective project champions

by David Blakey

Projects without effective project champions are more likely to fail. The main user may not be the ideal project champion, if they lack some necessary attributes.

[Monday 10 December 2007]

Unless a project has an effective project champion, it is likely to fail.

That may seem a strong statement. After the failure of a project, several reasons may be given for that failure. So, scope creep can be blamed. Unclear or ambiguous statements of work can be blamed. Inaccurate budgeting can be blamed. It is rare that the effectiveness or even existence of a project champion is blamed.

Consider what happens at the party after the completion of a successful project. Various people are thanked for their work. One of these is the project champion. The words that are often used about the project champion are that they made it all happen. Without them, the project could not have succeeded. They kept the project on track. They kept the project team going in the right direction. And so on. Often somebody will say that they have so much to thank the project champion for that they don't know where to begin.

As almost every successful project seems to involve an effective project champion, it seems reasonable to me to say that unless a project does have an effective project champion, it is likely to fail.

Project champions

Many organizations appoint the main user of the resulting product as the project champion. These organizations believe that the best person to keep a project going is the one who will benefit from it most. They may be right.

Voice

The project champion needs to have a strong voice, to be unafraid to use that voice, and to have that voice listened to at all levels in the organization. If the goal of the project is to enhance the payroll system, then the payroll manager may very well become the project champion. Payroll managers will certainly have strong views on what they expect, but that does not necessarily mean that they will have a strong voice. If the payroll is regarded as a service or a commodity, removed from the basic supply and demand chain of the organization, then payroll managers may not be involved in overall strategic decisions. Their voice would weak simply because it was rarely exercised.

More than that, they may believe that they have a weak voice, and therefore be unable to use their voice. Someone can still succeed if they believe that they have a strong voice, even if they do not.

Beyond these two considerations, other decision-makers in the organization may not recognise that the payroll manager has a strong. It can sometimes happen that a manager does have a strong voice in the organization and they are aware that they do, but that their colleagues do not recognise this. The payroll manager may exercise a powerful voice in having changes made that their peers do not see as important to the business.

A strong voice must

exist
be used
be recognised.

It is more important that the project champion has a strong voice than that they are the main user.

Context

The project champion must understand the products of the project. The project champion must know how the products will fit in the organization. If the project will have far-reaching effects, the project champion must know what those effects will be. Even if the effects are secondary, in that they will not be caused directly by the payroll system itself, the project champion must understand them.

The payroll manager can be a good choice for project champion if they are interested in and involved with the rest of the business. They should be the kind of person who gets out and about in the organization. The payroll manager would be a bad choice if they were focused solely on payroll.

Projects will be successul if the impact that they will have on the entire organization is understood and managed.

Learning

The project champion should be able to learn how the products of the project will work. For a payroll system, the champion must learn how to use the system, from the point of view of every user. So, as well as knowing what all the users will do, the project champion must be able to use the system as if they were each of those users.

During the early stages of testing, the project champion can be involved, helping the project team to get the product ready for a smooth beta test by the users. Beta testing should result in some minor changes to the product, rather than stopping development while major problems are resolved.

Visibility

The project champion must be visible. They should take every opportunity persuade other people that the project will be successful and that the product will provide real benefits. In other words, the project champion should be a champion. The project champion should not be seen as merely the main user, set slightly apart from the project.

Conclusion

I favour a particular kind of person who works in a particular way as project champion. For the project champion to be the main user is not enough. If the project champion is also the main user, then that is helpful. It is not necessary.

In many organizations there is a limited number of such people. Before one of them agrees to be a project champion, they must understand the amount of time and work that they will need to give to the project. Often, it will not be reasonable for any one of those people to be project champion for more than one project at a time. Even if some of them can champion more than one project, there will be a maximum number of projects that these people will be able to champion concurrently.

I am sure that project champions are critical to the success of projects. I would delay any project that could not get one of these people as its champion. I would not accept the risk of failure as a result of having a champion who did not have a strong, effective voice, a good overall view of the business and the context of the product within it, the ability of learn what users do and how they will use the product, and the time and commitment to keep the project visible. I would rather postpone the project.

If an organization was willing to take this risk on a project, I would ask them whether the project really was necessary, given that they were prepared to risk its failure. They would be wasting resources by embarking on a project that they were prepared to have fail. It would be better to cancel the project entirely.

We are aware that there are only so many projects that any organization can undertake at any one time. I would argue that a major limiting factor is the number of effective project champions.

[ List articles on Methods ] [ View printable version ]