From the Sponsors Desk – For Best Results Use Your Sponsor Wisely

In my last post, we looked at Project Interlopers – project players who are often contributors to project difficulties and project management migraines – and how they can negatively influence project outcomes. We also looked at steps you can take to counter their negative impact and improve the performance of your own projects.

In this post, we’ll look at how a director’s refusal to engage the project sponsor on a multi-million dollar reorganization effort resulted in project failure and his own loss of position.

Thanks to reader G.M. for contributing the details on this project.

The Situation

This public sector organization had a multi-year plan to improve the responsiveness and cost-effectiveness of its IT organizations to deliver $100 million in annual savings. Part of that plan was the consolidation of four local service desks into one virtual service organization.

The Goal

• Reduced cost of Service Desk and associated services
• Provide a consistent level of customer service for service desk and associated services
• Provide a single point of contact for technology users to report incidents and make service requests
• Provide a single organization responsible for providing standard services to the organization’s technology users.

The Project

The project was launched to great fanfare, with an announcement from the CIO outlining the goals and addressing plans to close the local service desks and consolidate the functions and staff in a remote, virtual site, accessible by phone, email and web services.

A new director was appointed by the VP Technology Services to form and operate the new organization, transfer staff from the local centers, acquire additional staff as needed and put the services and technology in place. The new director proceeded to hire a project manager to guide the process design and implementation and manage the technology initiatives necessary to support the new service desk operations.

The new director found that very few of the existing service desk staff were willing to transfer from their existing communities to the city where the new organization was based. That meant that the hiring and training challenges were significantly greater than originally anticipated. In addition, the new director faced considerable resistance from the architecture and IT operations organizations over the technology that he wanted to use to support many of the service desk functions. The estimated project and operating costs ballooned and the target dates slipped and slipped again.

The director and his PM tried to phase in the new service one local service desk at a time. However because of the cost and schedule slippage, the local service desk managers were reluctant to release their staff and the technology users continued to make use of their local service desks, leaving the new consolidated unit with significant excess capacity.

The Results 

The new service desk director continued to build his organization but much of the technology supporting its operation was legacy offerings from the local service desks. Because of this, the service experience was not a terribly pleasant one for technology user. They continued to frequent their local help desks for assistance where they knew the staff on a first name basis, could drop in unannounced with their questions and problems and receive the same personalized, friendly service they had become accustomed to over the years.

The new director had no authority over the local service desk managers (they reported to a peer director) so he couldn’t unilaterally close them down and the director who oversaw the local help desks was in no hurry to close them down because of the negative feedback he was receiving from technology users about the service of the new organization. It was a costly mess.

With a growing number of complaints from technology users and an increasing number of questions from the executive ranks, the CIO was forced to pull the plug on the new consolidated service desk. The director and PM were reassigned. The staff were either reassigned or let go. The price paid: $3 million in operating costs and $1.5 million in project costs. The cost of the reputations sullied: priceless!

How a Great Project Manager Would Have Helped

Sometimes on projects, perception is not reality. The new consolidated service desk director thought he was the sponsor of the initiative he was heading. The project documents actually stated that. When asked how often he interacted with his VP, he replied “only when I need his signature”. In reality, the director was a target, a manager of an organization that is affected by a change much larger than his span of influence. The real sponsor should have been the VP Technology Services, who had authority over both the local help desks and the new organization. He was also on a peer level with the heads of the architecture group and IT Operations, the two organizations that were resisting the new technology that was essential for a superior user experience.

So, what could the project manager have done to remedy the situation? Here are a few questions he could have posed to get the discussion about stakeholder roles and responsibilities underway and hopefully change the game:

• What organizations need to be involved and change the way they operate for the project to be successful?
• Which managers have the authority to allocate time, costs, resources and establish priorities in those organizations?
• What explicit role will each of those managers play on the project – sponsor, change agent, target or champion?

In my Project Pre-Check practice, a stakeholder is a decision maker who:

• Directs an organization that initiates, is affected by or is charged with managing all or part of a change,
• Has the authority and responsibility to set direction, establish priorities, make decisions, commit money and resources and
• Is accountable for delivering the planned benefits on budget and on plan.

Stakeholder involvement and commitment is one of the most important ingredients for successful business and technology change. Let’s look at what probably would have happened if the right decision makers were involved in the appropriate roles:

• We would have had the following players sitting around the stakeholder table:
  • The sponsor – VP Technology Services
  • Targets – the new director of the consolidated service organization, the four managers of the local help desks, the heads of the architecture group and IT operations (because of the impact of the new technologies) and someone representing the interests of the technology users (because of the changes in the service desk location, processes and technologies)
  • Change Agent – the project manager, who would take his primary marching orders from the sponsor as well as addressing the needs of the targets.
• Those stakeholders would have been committed and engaged from project inception through completion.
• The issue of relocating staff would have been addressed and perhaps the location of the new consolidated center would have been changed to facilitate staff moves.
• The technology choices would have been addressed with the buy-in of all stakeholders, including those representing the interests of the technology users.
• The phased close out of the local centers would have been managed in concert with the phase in of the new service desk.
• The technology users would have been much more amenable to the new service, processes and technologies because of their upfront engagement and ongoing involvement in the decisions affecting their world.
• The incremental operating costs would have been eliminated or minimized.
• The reputations of the CIO, Director and project manager would have been preserved and probably enhanced.

I know this analysis is hypothetical. However, without the right players in place and the right guiding coalition going forward, the project was essentially doomed from the start.

The stakeholder group is a most powerful force for enlightened project guidance and an essential resource for project managers. But it needs to be nurtured and cultivated from project launch. That’s why it’s central to Project Pre-Check’s model, processes and Decision Framework. It is a great place to start your project and supplies a terrific framework for building an effective guiding coalition that will be there when conflicts and crises arise.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great Project Manager.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll present it for others to learn from and comment on. Thanks 

Don’t forget to leave your comments below.