Projects are one time entities. Project managers usually only have one chance to get each project right. There are no do-overs in the real world. That offers an exciting career, but with the attendant pressures, issues and risks. Wouldn’t it be nice if we could hit the reset button and restart the project on occasion?
In this post, we’ll look at how one project manager had the opportunity to guide the same project on three different occasions, with two aborted attempts and a final, successful implementation. We’ll also discover the lessons he learned and applied along the way that made all the difference to the final outcome.
Thanks to M.A. for the details on this case.
This mid-size manufacturing organization had pursued a growth through acquisition strategy over the previous ten years. The strategy had worked. It had tripled revenue and grown the bottom line. But it hadn’t taken the opportunity to rationalize the acquisitions’ operating practices and technology infrastructures and that was creating a drag on profits. It had multiple financial systems, human resources offerings, ERP solutions, customer management processes and technologies and lots of organizational duplications. The CEO decided the time was ripe to fix the problem, cut the duplication and waste and start directing more of that growing revenue stream to the bottom line.
The CEO charged the CIO with fixing the problem. Both the CEO and CIO viewed the problem as a technology challenge that required an assessment of each of the technology offerings available, a decision on the preferred solution and conversion of all operating units to that preferred solution. With that frame of reference, they developed a list of candidates to lead the project and selected an engineer who had several years of experience with the parent organization and had distinguished himself on a number of occasions with innovative solutions to operational challenges. They reassigned the selected engineer to the project and gave him a mandate to do what was necessary to eliminate infrastructure duplications and improve operating efficiency.
The CEO and CIO agreed on the following goal: to standardize operating technologies and processes across all operating units within three years at a target budget of $3.6 million. The budget was arrived at by counting the six operating companies, assuming six core processes in each and assigning a $100,000 per process conversion cost.
As I indicated in the introduction, there were three attempts to deliver this project successfully. The first two failed. The third time’s the charm.
The newly assigned project manager, let’s call him Steve, jumped at the challenge. He contacted colleagues in all the operating units, explained his mandate and asked for their help. Where he had no previous relationships, he looked for guidance from the CIO and used his recommendations to establish contact. He identified eleven participants in all, people he believed had the knowledge and influence to help him achieve his goal. Everyone he talked to was supportive of the need to streamline operations. So, feeling very confidant, Steve developed a five step plan:
- Identify all the core operating processes
- Catalogue the various technologies used to support those operating processes in each organization
- Develop assessment criteria to evaluate each technology on an objective basis
- Assess each technology using the established criteria
- Select and recommend one technology for each operating process
As Steve contacted his eleven contributors to get the ball rolling, he found their availability was a challenge. While they all insisted they believed in his project, they claimed lack of time to contribute because of other priorities. He’d call meetings. Six would accept. Three would actually show up. He’d book appointments. Some wouldn’t respond at all and many that did would cancel the day of the meeting. He’d send out draft documents for comment and typically receive feedback from less than half the recipients, many with just cursory or general remarks.
Steve reported to the CIO on a periodic basis. Every meeting focused on the difficulty of getting time and attention from his contributors. The CIO just urged him to keep plugging along but made no other suggestions to improve the effectiveness of the exercise.
Steve had allowed himself nine weeks to complete the five step plan. To his horror, it took him eight weeks to get through the first two steps and even then he wasn’t convinced that he had everyone’s agreement. Things got even worse when he started contacting the vendors who supported the technologies operating in the various business units. Most of the vendors didn’t seem interested in dealing with him. They all had their own contacts and relationships with his company and suggested that if he needed information, he should go through those channels. That added four more names to Steve’s list of contributors and meant that he had to backtrack to bring the new players up to speed on his project and what had been completed to date.
Developing the assessment criteria took seven weeks, not the two weeks he had planned. While he had hoped to develop a generic checklist for use on all the technologies, the contributors wanted process specifics so he had to create purpose-built checklists for each core process. Again, he kept the CIO appraised of the challenges he was facing but the CIO offered very little in the way of assistance to accelerate progress and gain back some of the lost schedule.
By the time Steve started step 4, assessing each of the technologies, his project was eleven weeks behind with no idea how to address the core issues – this change would involve massive business process change and he lacked committed contributors and the ability to influence enterprise priorities to get that commitment. To compound the challenges, the vendors of the various technologies used in the operating units now knew that something was afoot. They recognized the risks and the opportunities and so they started to exert pressure on their customers to use their offerings across the enterprise. Political pressure would make an objective assessment of the technologies even more difficult. On top of that, the CIO was getting hounded by all of the vendors. They wanted a say.
So the CIO met with the CEO to discuss the problem. Between the two of them, they decided to change the approach Steve had been taking. They would ask all the involved vendors to submit bids on becoming the enterprise vendor for one or more of the core processes. They would also go outside the existing vendor list to solicit bids from companies that offered SaaS and other cloud solutions. The CIO informed Steve of the change in direction and asked him to prepare the Request for Proposals (RFP’s) and get them out to the vendors.
Steve was royally pissed. He should have been involved in the meeting with the CEO. He knew the challenges the project was facing and could have contributed to the discussion and the chosen outcome. He felt the RFP approach would run into the same issues he was already facing. He told the CIO what he thought. The CIO essentially ignored Steve’s concerns and in effect said “There, there Steve, everything will be OK. Just trust us.” Would you?
So Steve decided to give the RFP approach a try even though he had grave concerns. At least if he could narrow down the vendors, he could start working with his contributors to build a viable implementation plan. The work Steve and his contributors had completed on steps 1 through 3 did come in handy. He was able to put together a comprehensive set of business specific RFP’s that could be used by all vendors for all core processes. However, when he approached his now fifteen contributors with an update on the direction of the project and request for feedback on his draft RFP’s, he ran into a load of turbulence. By and large, the contributors did not like the new approach. They felt that they had little say in the decision-making process and little control over the final outcome. A couple of the contributors actually told Steve that they would no longer be involved in the process. A number of the contributors, who were mostly at the middle management level, went to their bosses with their concerns.
Steve brought the feedback to the CIO and this time included the CEO in the loop. Their response: “Just keep going. Everything will be fine.” So he did. He sent out the RFP’s with a submit-by date four weeks in the future. He offered optional sessions so each vendor could meet with the key stakeholders (the CEO and CIO) to discuss the requirements and opportunities. A number of vendors opted for the meeting so Steve proceeded to set them up. Unfortunately, the CEO and CIO were usually unavailable so Steve became the point man.
While Steve was working with the vendors to get the RFP’s in and assessed, two other critical activities were taking place that Steve was not privy to. Senior executives in the operating units were being made aware of the project, how it was being conducted and the concerns their staffs had about the impact on their organizations. And, vendors were lobbying and politicking at the most senior levels of the organization, including the board of directors, to ensure their offerings were selected.
As Steve was getting set to recommend specific vendors for the core processes, with whatever input he could get from the contributors who were still involved, the CEO resigned. It seems the board had concerns about the CEO’s performance and his direction of the infrastructure rationalization project was the last straw. The project was suspended. Steve returned to his old job.
The new CEO, a senior executive from one of the operating units, took three months to settle in before relaunching the infrastructure rationalization initiative. He met with the CIO to gather some insight and the CIO brought in Steve to provide the details on what went wrong and what needed to happen to make the project successful.
Steve hadn’t been idle since the project was cancelled. He had done his own post mortem. He had done some reading and research. He had chatted at length with a friend who had become a very successful project manager. Here’s the substance he shared with the new CEO and CIO:
- This is a business project with significant impact on business operations. It has a large technology component but it’s not a technology project.
- It didn’t have the enterprise priority it needed to be successful. In most of the operating units, it wasn’t even on their radar as something that needed their attention.
- It didn’t have the commitment of the key business unit decision makers it needed to progress effectively and deliver successfully.
- It was woefully under-resourced in terms of dedicated business process and project management knowledge and skills.
- Establish the priority for the initiative across the enterprise and ensure everyone acted accordingly.
- Identify and engage the key stakeholders – the business and technology decision- makers whose active participation would be essential for a successful outcome.
- Clearly articulate stakeholder roles and responsibilities through the use of a RACI chart or similar tool.
- Complete a business case that focused on the business issues, the expected business outcomes and the associated impact on business operations.
- Complete a project charter that includes a description of the undertaking, the goals and objectives, functional and non-functional requirements in and out of scope, assumptions, constraints, risks, resources and facilities, etc.
- Prioritize the core processes included in the project and plan for a phased and staged implementation. The organization did not have the capacity or capability to accommodate the updating of all core processes concurrently.
- Ensure a highly experienced and successful project manager is in place to guide the undertaking.
The new CEO liked Steve’s recommendations and asked him if he’d like to be involved again and in what capacity. Steve responded that he’d love to be involved and would like to be given the project manager role, but with one proviso – that he be provided with a PM mentor who would guide and direct Steve and provide regular feedback on the project, and Steve’s, performance. The new CEO had Steve present his findings and recommendations to the executive committee and asked for their approval to proceed as recommended. They agreed. Steve had his third chance.
With his mentor in place, the key decision-makers backing him, the priority established and communicated and a new action plan to guide him, he facilitated the prioritization process for the core processes. Financial management and reporting was selected as the most pressing challenge and so he and his team focused exclusively on that as phase 1. The process and infrastructure rationalization was completed under budget but about three months late. That enabled a clean, staged rollout, business unit by business unit. The stakeholders were fully involved in the undertaking and endorsed the late delivery to ensure a pristine implementation. And it was!
The other core processes followed, one by one, with similar staged implementations and similar, highly successful results. The 8th and final phase was completed four years after the start of the third iteration. The whole organization had been involved and they had gotten very good at this. Steve was promoted to Director, Enterprise Project and Change Management about two years into the undertaking in recognition of his stellar leadership and the superb results achieved. Return on Investment: over 60%.
How a Great Leader Changed the Outcome
Steve started on this journey with no formal project management training or experience. Fortunately he possessed an inquiring mind, good problem solving skills, an ability to think outside the box, tenacity and well developed communication skills. He recognized early on that he had two insurmountable challenges – lack of committed contributors and zero control over enterprise priorities. He also recognized that while he reported to the CIO and looked to him for advice and guidance, the CEO seemed to be calling the shots.
He responded by discovering and applying the best practices outlined under Iteration #3 above. So, if you find yourself in a similar situation, leverage all those practices you know have been proven and add value. Marshall the insights and support of your colleagues. Involve the affected stakeholders right up front. Always consider alternatives, both business and technology, regardless of the edict. And, if warranted, restart the project.
Finally, put these points on your checklist of things to do in future endeavours so you too can be a Great Leader. 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
Drew Davison is the owner and principal consultant at Davison Consulting, a senior consultant at Mapador Inc. and a blogger on Project Times. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check – The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at firstname.lastname@example.org