From the Sponsor’s Desk – Collaboration in a Command and Control World
In my last post, Managing IT Services Contractors, we looked at the experiences of a project manager trying to corral two IT Services contractors as part of a major infrastructure upgrade and the steps he could have taken to improve the overall project experience.
In this post, we’ll look at one project manager’s experience trying to guide a technology upgrade offering a multitude of opportunities to enhance maintainability, performance and usability in an environment where the sponsor focused exclusively on time and costs. Thanks to reader S.R. for the details on this case.
In 2000, this medium sized, mid-west based manufacturing concern launched an in-house development effort to automate and enhance a core administrative function that had been a mish-mash of older technologies and manual processes that were costly, error prone and time consuming. The new application, developed in Visual Basic version 6 (VB6) back then, leveraged the in house development group’s experiences with earlier versions of the language and delivered the expected improvements in quality and performance.
Unfortunately, in 2008, Microsoft ended support for VB6 and replaced it with its .NET offering. The VP Administration at the firm was aware of the impending loss of support but declined to take any action until just before vendor support for the product ended. He then challenged the CIO to find a way out of the dilemma as quickly as possible and at the lowest cost possible.
The VP Administration, the sponsor of the undertaking, established the following objectives for the project:
- Deliver a supported solution in six months or less
- The costs should not exceed $250,000
- There should be no changes to the business user experience. They should be able to operate exactly as before.
The CIO, with the sponsor’s agreement, appointed an experienced internal project manager to lead the effort. She identified and met with the other stakeholders who needed to be involved. Collectively they met with the sponsor to review his expectations and discuss some of the needs and opportunities the other stakeholders had in mind.
The sponsor restated his three objects. He rejected all other suggestions from the other stakeholders. He made it perfectly clear to everyone in the meeting that there would be no further discussion on the scope of the project. A follow-up meeting between the sponsor and project manager produced the same outcome but the sponsor added an additional requirement. He wanted an external company to bid on the project. When the project manager pointed out that that would add additional time, cost and risk, the sponsor exploded and challenged the project manager to get the job done within his expectations.
This is probably where the project manager should have removed herself from the project. However, she motored on. She worked with the other stakeholders and their staff to develop a Request for Proposal, worked with the CIO and other IT managers to identify two external candidates with solid track records and worked with those contractors to help them understand the challenges ahead. She also facilitated the development of a proposal from the internal development group. The proposals:
- External Company A – $900,000 and 10 months duration
- Internal Development Group – $600,000 and 7 months duration
- External Company B – $500,000 and 6 months duration.
The project manager, with the support of the CIO and other stakeholders, recommended the Internal Development group’s proposal over the two external proposals based on a thorough, objective, fact based review. The sponsor picked External Company B’s proposal. In spite of considerable debate and discussion at the executive level, the VP Administration got his way. The contract was awarded to External Company B which immediately assigned its own project manager. The internal project manager was assigned to another internal project. She was lucky!
The project was a mess! It ended up costing over $1 million and took over a year to complete. Much of the overrun was due to rework. The sponsor demanded that the contractor’s project manager find ways to cut costs from their original $500K estimate. He personally cut out the costs associated with the participation of the internal development group in plan and code review and unit and integration testing. He also personally cut the involvement of the business unit staff in the same activities. He rejected any attempts to take advantage of the .NET platform and declined to consider changes to the application the business proposed to improve overall performance.
This sponsor from Hell should have looked in the mirror to place blame. Instead, he threatened the contractor with bad press and legal action. The contractor ultimately agreed to swallow most of the overrun. He also publicly criticized the other business and IT stakeholders for failing to identify competent external contractors and doing their part to ensure a successful outcome.
In this situation, there was no collaborative stakeholder group. In spite of the efforts of the internal PM to engage the other stakeholders, the sponsor’s frame of reference was command and control – I say, you do! No sponsor, regardless of how experienced, informed and qualified has all the information needed to make all the right decisions necessary for managing a change. This sponsor’s unwillingness to leverage the knowledge and insight of the other stakeholders was the number one cause of failure.
In this situation, the internal development group and the two contractors relied on their experiences with similar technology upgrades to provide a proposed roadmap for the work ahead. The roadmaps presented a rational series of steps and decision points, the participants in each step and the roles and responsibilities for each participant. When the sponsor started dictating what steps would not be done and what parties would not be involved, any opportunity to leverage a proven, end-to-end process went out the window. Failure cause number two!
In this situation, the sponsor’s attempt to dictate all three variables – time, cost and function – caused the contractor’s PM to abandon best practices that had served the organization well in the past. Their estimating practice, their approach to planning and delivering quality solutions, planning and managing risk, always considering business and technology alternatives, phasing development and staging delivery to provide early insight and added value, and others, were all sacrificed in an attempt to please an out-of-control sponsor. Cause of Failure number three!
How a Great PM Could Have Changed the Outcome
As the saying goes “Hindsight explains the injury that foresight would have prevented”. We know what’s needed to deliver a successful project: a committed, collaborative stakeholder group, proven processes that can be applied or adapted to the situation at hand, and use of proven best practices to cover the change landscape.
In fact, the internal PM did most things right. She engaged the other stakeholders. She escalated by bringing her CIO into the fray. She offered a number of intelligent options to the sponsor. Unfortunately, the contractor’s PM didn’t challenge the sponsor’s edicts and didn’t attempt to escalate within his own organization or within the client’s organization until the damage had already been done.
Dealing with sponsor incompetence is a challenge. The sponsor is in that role because of his or her place in the organization. A replacement sponsor typically has to come from the same organization, either in a position above or below the incumbent. Obviously, a PM needs lots of assistance to make that happen. Changing a sponsor’s perspective and style towards an engaged, collaborative stakeholder model can happen if the PM and other stakeholders are able to demonstrate that it’s a more effective model for achieving the sponsor’s goals. However, for that to work, the PM needs the other stakeholders to be actively on the sponsor’s case, the message has to be delivered consistently and repeated often until the metamorphosis happens. Finally, a great PM knows when to pull the plug. You’ve heard the saying “Life is too short to drink bad wine.” In this case the saying should be “A PM career is too short to take on bad projects.”
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 PM, and your sponsor’s best friend.
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 have a go.