Opinion: Monitor your project sponsors

Computerworld - It has become an article of faith that projects without sponsors will inevitably crash and burn. But unexamined beliefs can lead us astray, and we need to be thoughtful about how we apply any maxim. In the case of project sponsorship, more is required of us than checking a box on a form and holding monthly status meetings.

In fact, some projects don't need a sponsor. Pure infrastructure projects, for example, are unlikely to attract a real business sponsor, any more than a revamp of the office restrooms would. You can call it aligning the business with the underlying plumbing if you like, but no one is going to step up to take responsibility. Everyone wants a toilet and a sink, but no one thinks they're mission-critical infrastructure until they're no longer available.

On the other hand, we sometimes fail to recruit a sponsor when one is needed. It might be that every potential sponsor is too busy, or they're wary that they could be blamed if things go badly. Sometimes a sponsor signs on but then tries to delegate his responsibilities so far down into the organization that decisions can't really be made in a timely fashion. In cases such as these, we give up and just get on with the project.

Even when we do recruit sponsors, things don't always work out well. Simply having a sponsor is not enough to ensure success. I've observed two distinct issues with sponsorship that commonly undermine its effectiveness.

The first of these is that sponsors and project managers fail to clearly define the sponsor's role. We often assume that sponsors will automatically know their responsibilities, but nothing could be further from the truth. Think about it: Business people are rarely steeped in IT project processes or technology, and they rarely study how business and technology interact. Even experienced sponsors can be confused, because no two projects are the same.

Project managers and sponsors need to clarify what a project is going to need from its sponsor and how communication will take place. Does a sponsor have veto authority over some decisions, or does he operate in an advisory capacity only? Does the sponsor have budget authority? What are the boundaries of the sponsor's rights? How will sponsors be kept in the loop on project status?

This absence of clarity can lead to some misconceptions, on either side, about the nature of the sponsor's authority, including the following:

The sponsor is the project boss. The sponsor should be the advocate for the interests of the business community, but that is not the same as being the project supervisor. Business sponsors rarely have the expertise to oversee an IT project, and they are also unlikely to be effective at balancing the competing interests of the various communities affected.

The sponsor is the uber project manager. Sponsors should not be consulted on every detail of daily project operations. Process is not their domain. They should instead focus on ensuring that users and the business get value from the product of the project.

The second common problem involves a sponsor who becomes politically disconnected from the business community. Those of us in IT might assume that just because the sponsor is actively engaged with us and is making seemingly reasonable requests, all is well. If we don't monitor the sponsor's connection to his constituents, we won't know when one starts to peel away from the other. And if the gap between the sponsor and the business grows, then the gap between the project and the business grows too.

If you want to effectively use sponsors, think carefully about what you need from them and how well they can ensure alignment. If your sponsor is unplugged, your project will be too.

Paul Glen is a consultant who helps technical organizations improve productivity through leadership, and the author of the award-winning book Leading Geeks (Jossey-Bass, 2003). You can contact him at info@paulglen.com.

Read more about Management and Careers in Computerworld's Management and Careers Topic Center.