I expect most of us have had a project experience or two where considerable extra time and effort were required to deliver our change successfully. Where we pulled all-nighters, where teammates crashed on conference tables and chairs for a couple of much needed winks. On the occasional project, that extra time and effort is fine, even celebrated if things go well. But, there are organizations and situations where the expectation of that extra time and effort is the norm not the exception, where heroic efforts are commonplace, the only way to have any chance of success. These are the lessons from heroic projects!
What causes this situation to arise? Is it always the most appropriate response? Is there any way to instill a more rational approach? Read on to learn what one contract Project Manager concluded from his experience in a deliver-at-all-cost organization.
Thanks to G.D. for his contributions to this post.
This national retailer had a number of critical projects in progress, and in trouble. One project in particular, a web based marketplace venture, was experiencing all kinds of difficulty. The various parties to the design couldn’t agree, the quality of the code delivered to that point was terrible, the technology infrastructure acquired to support the service wasn’t performing acceptably and the project manager who had taken the initiative from inception to the current state resigned in disgust. He complained about lack of management support. He wasn’t able to get the needed human resources and facilities. The scope kept expanding and the sponsor was obsessed with an unachievable target date.
The PMO Director was charged by the Marketing VP with finding another PM to address the problems and guide the project to a successful conclusion. The Marketing VP’s exact words: “Find someone to clean up this mess or heads will roll!”
The PMO Director presented the PM candidates he interviewed with an unbiased assessment of the project’s current state. The original goal for the project had been to deliver the Marketplace service offering five hundred or more of its top products in fourteen months. That target was still in place, but with only seven months to go, there were a number of issues that had to be addressed to deliver successfully.
The PMO Director managed to bring on a seasoned PM with great qualifications, an excellent track record and terrific references. The PMO Director hoped that the new PM could work the necessary magic to deliver the project by the target date and get the Marketing VP off his back. He certainly paid a premium price to get the new PM on board.
The new PM jumped in with both feet and fourteen hour days six days a week for the first three weeks. His project was a quagmire, as advertised! He also checked with a number of fellow PM’s to get a read on the organization’s culture and practices. He found an alarming parallel to his own project. His key findings:
- Under Resourced and Over Committed – Most teams were lacking adequate resources, missing key skill sets and averaging ten or more hours a day, often six and even seven days a week. His team was no exception. The staff had already been going hard for seven months. The wear was starting to show: quality issues, increased absenteeism, more conflict, declining morale and, he expected, lower productivity.
- Minimal Key Stakeholder Involvement – In many of the projects, the key decision makers acted like judge and jury in their monthly steering committee “courts”, rather than the leaders and change owners who needed to be engaged and actively involved in the conduct of the change.
- Lack of Fully Documented Business Cases – The approach to business cases was as varied as the executives involved. Some projects were blessed based on an undocumented conversation, others based on a couple of PowerPoint slides, still others on an email chain. Benefits were almost always unquantified (more sales, lower costs, better service, etc.), costs were usually “ballpark” numbers, almost never supported with explanatory details (and not tracked anyway) and risks were seldom included.
- No Understanding of Enterprise Priorities – Projects were launched based on their sponsoring executive’s ability to make the sale. Once approved, they scrambled for resources and facilities in competition with other projects. There were no established enterprise priorities and no understanding of potential conflicts and dependencies. It was a demolition derby.
- Irrational Target Dates – In many of the projects, the target dates were completely arbitrary. It seemed they were a reflection of the size of the originator’s ego. The dictated target dates were seen by the executives as a way of controlling costs by limiting time. However, there were seldom any sound business or technology reasons to justify their pursuit. Yet pursued they were, at the cost of individual and team health and organizational sanity.
- No Clear Statement of Worth – Pork barreling was alive and well. Minimally involved managers and hangers on would add their own pet requirements. PM’s had limited ability to say no, to push back. There was no organizational effort to ensure incremental value for money spent. Consequently, effort increased but with no managed return on that investment. And, of course, the target dates never changed and were rarely met.
- No Agreement on Quality Goals – In most of the projects he looked at, including his own, there was an almost complete absence of defined targets for key quality factors such as usability, continuity, scalability, flexibility, portability, security, service levels, etc. Yet, addressing these factors appropriately was a key requirement for project success.
- Lack of Core Best Practices – A consistent and rigorous application of fundamental project management best practices was mostly absent. There was little in the way of effective change or issue management. Only time was tracked, not costs. Risk management was mostly reactive. There was no prototyping to prove new concepts or test new approaches. Implementations were largely big bang. Phasing and staging were rarely used. The typical response to resourcing issues, human and other, was to work longer, to work harder, to put up with conflicts and contention and suffer the consequences.
The PM’s first priority was to meet with the Marketing VP, the project’s sponsor. Unfortunately, the meeting took two weeks to arrange. The PM reviewed his preliminary findings and asked the sponsor to get more involved and help plug some of the critical gaps. The sponsor’s response: “I’m busy. You’re the PM. Fix it.” When the PM tried to explain why the sponsor’s active involvement was vital, the sponsor ended the meeting.
What to do? The PM realized the project would likely not achieve its target date even if all the gaps were addressed. Without the sponsor’s active involvement, the risks were significantly greater. The PM decided to try the surrogate sponsor route. He would make the decisions on all the non-business questions and seek consensus on business matters from the other business folks involved.
The PM imposed some standard best practices that his team would apply going forward. He formed a business operating group comprised of the product managers, the sales director, IT software manager and infrastructure director. He appointed one product manager as the team leader and challenged the group to address the outstanding business related issues. He attempted to schedule individual meetings with the steering committee members (Marketing, Product and Sales VP’s and the CIO) to keep them up to date but was rebuffed so he kept them posted by email.
In two weeks, the business operating group had drafted a business case and established quality goals for all the relevant factors. Unfortunately, key targets were still unquantified. At the PM’s request they had also developed a phasing strategy including prioritization of the service’s planned functions and features. His team put together a plan that would deliver the service incrementally using the operating group’s phasing strategy. The total plan would take twenty months but they would get a good chunk implemented by the fourteen month target. Things were looking up! Morale was up. His team and their business partners were getting enthused. Again he kept the steering committee members updated via email.
And then the steering committee happened. Six weeks after his start on the project, he reviewed the project’s progress at his first steering committee. The Marketing VP ripped him to shreds. He trashed the work done by the operating group. He insisted some requested changes rejected by the PM’s new change management process had to be included. And, of course, the entire project had to be implemented by the original date. The other steering committee members sat by mutely and let the Marketing VP continue his tirade. When the PM responded that there was no way the project could be fully implemented in the six months remaining to the original target date, the Marketing VP gritted his teeth, reiterated his demand and left the meeting. The PM appealed to the remaining steering committee members, to no avail.
The PM informed the PMO Director of the results of the steering committee meeting. And then he handed in his resignation.
Under pressure from the Marketing VP, the PMO Director contracted with one of the big consulting firms to run the whole project. The final release was implemented three years after the firm was brought in, more than two and a half years beyond the original target date. While the organization didn’t track the project costs to the point the consulting firm took over, those in the know suggested that the final cost was probably more than four times the phased in approach the contract PM proposed.
How a Great Leader Could Have Improved the Outcome
The contract PM knew the project was in trouble when it took two weeks to arrange a meeting with the sponsor. He knew he was in trouble when he looked at the state of his project and the organization’s project management culture. He knew he was in trouble when he realized his sponsor was a bully. Given these realizations, is there anything he could have done differently to achieve a more successful outcome?
I did a similar post a while back, You Can’t Always Get What You Want, about a project which ended in a similar fashion. In that post, I suggested the PM could have cultivated the stakeholder group more effectively over the course of the project and leveraged its power and influence when the sponsor proved incapable.
Unfortunately, in this case, the PM never really formed a stakeholder group. He reported to the sponsor, his team reported to him. The other members of the steering committee were essentially bystanders. The business operating group included committed business folks but they weren’t at a high enough level in the organization to bring any kind of pressure on the sponsor. When the PM decided to play the “surrogate sponsor” role, the dye was cast. His goose was cooked!
When the PM initially sought a meeting with the sponsor, he should have also booked meetings with the Product and Sales VP’s and the CIO. They all had significant stakes in the project. He needed to find out what they thought about the progress to date, to discuss their concerns and expectations for the project and confirm their willingness to get involved to shape the planned change. That investment in relationship-building could have changed the project’s power balance in significant and positive ways.
Once in a while, an heroic project effort may be necessary, and even exhilarating. But when it becomes the norm rather than the rare exception, things have gone too far. So, if you find yourself in a similar situation, on a project, or in an organization, that requires unrelenting heroic performances to be successful, take a step back. Apply the lessons from heroic projects! Think about how you’re going to transform the culture to a rational, best practice based experience that will deliver successfully without laying waste to people’s lives and the company’s aspirations. Put these points on your checklist of things to do in future endeavours so you too can be a Great Leader. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors.
Finally, 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, don’t be shy! Send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, we’ll post it so others can learn from your experiences. Thanks
Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. 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 email@example.com.