From the Sponsor’s Desk – Project Recovery Fundamentals

In my last post, Five Stakeholder Priorities, we looked at the trials and tribulations experienced by a businessman and entrepreneur who saw an opportunity to create a unique artistic center using a recently acquired, long abandoned industrial complex. The initiative got off to a great start. But then he took his eye off the ball and the difficulties started.

In this post, we’ll look at the steps a project manager took to turn around project performance and stakeholder support when the initial assumptions and guidance structure on her project proved to be fatally flawed. Sometimes, in a project world, things are not always as they seem. This project manager was surprised on a number of key fronts but took the right actions to turn the situation around and deliver with smiles all around.

Thanks to D.G. for the details on this case.

The Situation

This manufacturing concern operated eight distinct web sites to support the wholesale and retail distribution organizations’ sales and service activities. The sites were supported by a content management system (CMS) that controlled over 300 unique web pages. Unfortunately, the version of the software being used was three releases out of date and was no longer supported by the vendor.

IT had tried to convince the business executives to upgrade to the latest release on a number of occasions but the initiative was always deferred because of pressing business priorities. The CIO finally sold the upgrade by promising a quick five month project that would be completely transparent to business operations. The business VP’s affected by the upgrade were somewhat concerned with their sites ongoing stability and so agreed to the project, but only if it could be done within the five month timeframe. They agreed to hold any changes to their sites for the five month period.

The Goal

Upgrade the content management software to the latest release to support the eight sites and 300 plus web pages and convert the sites to the new release in five months elapsed time with no impact on business operations. The upgraded sites would be identical to current sites in function, look and feel and performance. The estimated cost of the project was $2,400,000 based on an estimate from the vendor of $6,500 per page plus an additional 20% to cover planning, training, testing costs and contingency.

The Project

The CIO assigned a senior project manager to the effort. The PM had been with the company for a number of years, was familiar with the web environment and the software that needed upgrading and had a solid track on a variety of projects. Her first step was to sit down with the CIO and clarify the stakeholders and their goals and objectives. The CIO positioned himself as the sponsor, the software vendor as a change agent along with the PM and the groups that supported the content management software and web site operations in IT as targets. Those staff would have to update their knowledge and skills on the new CMS version to support the upgrade and its ongoing operation.

With those marching orders, the PM started assembling her team and developing a plan of attack. Because of the tight time frame, she assumed that she’d have to work on all eight sites in parallel. Other assumptions she made, based on the guidance from the CIO:

• No business involvement was required
• The latest software release would allow the generation of pages identical to the existing sites
• There were no new function or data needs
• There were no changes required in the underlying technology infrastructure (e.g. data bases, servers, communication and management technologies, web services, security, etc.)
• Skilled and trained resources were available internally and on the open market to handle the conversion.

As she attempted to build a rational plan to deliver on the five month target, she realized the immensity of the challenge. Using the vendors per page estimate, she would need, at the peak, up to fifty staff fully fluent and productive on the new software for about three months. She was familiar with Brook’s Law – adding staff to a late software project just makes it later. She needed help!

She sat down with the CMS vendor account manager to clarify roles and responsibilities and review her initial plan and assumptions. What she discovered just made the situation worse. The vendor was not planning on playing any change agent or project management role as the CIO had suggested. The account manager viewed the vendor’s role as a software provider and provider of technical support and training, nothing more. In addition, he indicated that the $6,500 per page he had quoted related only to upgrades from one version to the next using the vendor supplied conversion tools. Going up three versions would cost considerably more. Other discoveries:

• There were no conversion utilities to facilitate the software upgrade. The vendor provided tools to help upgrade from one version to the next but not to upgrade over three versions.
• Implementing exactly the same look and feel as the old sites with the new CMS release probably wasn’t doable. The new release didn’t support the old theme and templates used by three of the sites. It used different plugins for blogs, news feeds, contacts and other functions. The code was more search engine optimized which changed some of the look and feel. And, there were more robust tie-ins to social media sites and tools which required site design decisions.
• There wasn’t a lot of staff available in the open market with the latest knowledge and skills on tap to do the conversion.
• The CMS application itself had a number of functional and look and feel changes which would require training and learning curve for the business staff who maintained the business content.

If you’ve ever run, unexpectedly, into a clear plate glass door, you’ll know how the PM felt after that meeting with the vendor. Flattened and deflated. She met with the CIO to brief him on the challenges. She recommended a number of actions:

• Meet with the three business VP’s and update them on the recent developments. That would include the finding that the five month window was not doable, the costs would be considerably higher and business staff would need to be involved to make the decisions about functionality and look and feel in the revised sites.
• Explore a staged implementation on a site by site basis over an 18 to 24 month period to address the anticipated CMS skill shortage, business staff impact and other risks associated with the upgrade. That would require concurrent versions of the CMS software for the duration of the project.
• She also suggested that the CIO approach the vendor for additional support and threaten a switch to a different vendor if more support and some automation tools weren’t forthcoming.

Remember, the CIO and his VP of IT operations had been trying to convince the three business VP’s to upgrade for a number of years. The CIO was not inclined to go running back to them now when there were “a few challenges”. So he ordered the PM to proceed with a conversion on one of the eight web sites and gather information that would enable them to make “a more informed decision”.

The PM picked the smallest and simplest site, assembled a small team with the requisite skills and expertise, badgered the vendor account manager for additional assistance and went to work. Her team made the decisions about any necessary functional or look and feel changes. Their strategy was to use the capabilities of the CRM software and avoid any customized code to replicate the look and feel of the old sites. They created a limited test environment and evaluated the new site against the old. When they were as close as they were going to get and satisfied with the results, they closed the pilot and assembled the results. Their findings:

• The average cost per page was $10, 200 excluding the costs for planning, training and testing. That was almost 60% over the original estimate. This was the smallest and simplest site but there was a learning curve involved so the PM and her team concluded the findings would be applicable to the remaining sites.
• The pages had a substantially different look and feel because of the new themes and templates they chose. The old themes and templates were not supported.
• It took a couple of weeks for staff experienced with the old version of the software to be completely comfortable and fully productive. It took two to four weeks longer for someone who had no experience with the software.
• Minimal changes were required in the supporting technology infrastructure and tools and the technical skills required for managing the environment.

The PM took the results to the CIO and pitched her previous recommendations. Faced with the information that would support “a more informed decision”, the CIO capitulated and agreed to arrange a meeting with the business VP’s. To the surprise of the CIO and the VP of IT Operations, after some pointed questions and comments, the business VP’s agreed with the PM’s recommendations. Completely! They even agreed on site priorities and a rough time frame, subject to revision to support some planned business initiatives.

With the business VP’s agreement and commitment, the PM revised the stakeholder roles to reflect the business VP’s as co-sponsors, the VP, IT Operations and the business directors responsible for the staff involved in the functional and look and feel decisions were targets and the PM and a newly appointed vendor PM were the change agents. The CIO’s threat to start looking for a new CMS vendor had the desired effect. The vendor agreed to develop conversion tools that would help the company move to the new release and provided the PM to oversee the technical conversion.

The Results

The project was completed sixteen months from the day the business VP’s agreed to the PM’s recommendations. The PM structured the initiative as a program, with a project for each of the eight sites plus a distinct project for the technology infrastructure needed to support the concurrent instances of the CRM software. Sites were converted according to the priority established to integrate effectively with business plans. Total cost – $2,560,000 – just 7% over the initial budget. The overrun was small due, in large part, to the conversion support from the vendor. It also covered the cost of a number of enhancements the business chose to implement, leveraging enhanced capabilities in the new software.

Perhaps the most significant success was the enthusiasm from the business organizations. The business VP’s went from an adversarial, disinterested, “it’s an IT problem” perspective to enthusiastic, informed owners of their technology services. They had new, attractive, functional and fully supported web sites. Their staff were fully involved with the functional and look and feel decisions and thoroughly trained in the new environment. Even the vendor was happy because it was able to take the conversion utilities developed to move across three versions to other clients in the same boat. It was a great ending!

How a Great PM Succeeded

1. Confirm stakeholder roles

   The PM established the stakeholder roles right up front which let her focus in on the key decision makers. She also evolved the stakeholder model as the project progressed. That enabled her to redirect her attentions accordingly as sponsorship migrated from the CIO to the business VP’s. It was also the catalyst for pushing the vendor into a more active role.

2. Socialize your assumptions

   It appears that one of the stumbling blocks preventing approval for the CRM upgrade in previous years was the underlying assumption that all web sites had to be done at the same time. It was never stated, but the pitch from the VP IT Operations and the CIO didn’t articulate an alternative. The PM articulated a number of assumptions that she felt had a material impact on her project. She did not include one-time implementation among them. She also vetted them with the other stakeholders and received their reactions, positive and negative.

3. Translate your assumptions into facts

   The PM not only documented and socialized her assumptions, she went one step further – she took the time to verify the accuracy of her assumptions, to determine whether they were risks that had to be managed and mitigated or to address them with targeted actions. And she took those actions right up front, before they could seriously damage her project.

4. Think big, do small

   The PM had a significant amount of work to deliver in a limited amount of time, not an unusual situation for a project manager. However, instead of having one massive plan, she looked at the overall challenge, the business priorities, the various pieces and the relationships among them and developed her program and project approach. It made planning and managing the work much easier and facilitated tracking and reporting that was much more meaningful to her stakeholders. Also, by phasing and staging her deliverables, she was able to reduce the risks and incorporate learnings from the previous phases in the business, technical and conversion efforts.

5. Call in all your favours

   Positioning this undertaking as an IT initiative was dumb. It was a business project with a large IT component. But it was still a business project first and foremost. The business VP’s needed to be involved. Their staff needed to be involved. The vendor needed to be involved. Forcing their hands and getting them committed and involved set the project on the path to success.

If your project is in trouble, go back to first principles. Who am I working for, with? Who should I be working for, with? What do they want? Why? When? Why? What’s the overall goal, objective? What are my options for getting there to minimize risk and maximize value? You know the drill. This PM did all the right things to get back on track. If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a Great PM. And remember to use Project Pre-Check’s three building blocks right up front so you don’t overlook those key success factors.

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.