The role of the sponsor is an attentive one. Sponsors need to invest closely in identifying the problem, understanding and addressing what the organization needs, managing the change and supporting the project. There’s a lot to that. When the role is done well, the sponsor stays close to the project, providing guidance, making decisions and offering support.
As I mentioned last week, while that kind of attention is rare, it is what can make the difference between success and failure. Most of the time. Lack of sponsor attention can be a virtual guarantee of failure. But sometimes bad things happen to good projects, good project teams and really good sponsors. It’s sad to say. And frustrating.
We’d like to know that there is a clear path to success. The obsession with ‘best practices’ is a by-product of the misplaced hope that there is one right way of doing things, that if we do what we are supposed to do then the desired results will magically be delivered. Managed well and sponsored effectively, the odds of success are most assuredly enhanced. But in projects as in life, there are no guarantees.
I would suggest that it’s safe to assert that at some point in their careers, every sponsor and every project manager will be confronted with situations where bad things happen to good projects. To frame what I mean by “bad” here, I’m not talking about risks arising, or issues being encountered. Every project deals with those, regardless of how well planned, managed or supported they are. I’m talking instead about colossal, cosmic, catastrophic problems. Sink holes, not speed bumps.
These kind of dilemmas are the worst nightmare of every project sponsor, and every project manager. And to be honest, it’s not that much fun for the project team, either. Very often they’ve not been considered as part of the risk plan (or if they have, they’ve been ruled as too remote and ridiculous to even consider, which makes for an excruciating instance of “I told you so.”)
So what kind of crises am I referencing here? There are many possibilities. A critical supplier could go bankrupt, or out of business completely, or just abandon the work. The requirements of the business could significantly shift in response to a corresponding change in strategic direction. The economy could substantively change and with it, the cost structure, revenues and profitability of the organization (and the willingness to pay for the project). Collective bargaining could derail change management efforts and willingness to encourage the change. The organization could wake up and realize that it didn’t actually need—or want—the results of the project.
I’ve seen all of these, and more. Worse, I’ve been on the receiving end of several of them on different projects. And while the reasons for them vary, the consequences are incredibly similar. The project becomes threatened, the project team panics and the project sponsor gets very anxious indeed.
A case in point was an organization I encountered early in my career. The firm in question was a regulated entity in the financial sector, responding to significant changes in rules, regulations and oversight requirements. In addition to bringing themselves into alignment with the new regulatory regime, the organization was also attempting to establish several new lines of business as a way of increasing market and customer share. This required their ability to function, deliver service and—not unimportantly—invoice their customers in very new ways.
Some ways into a number of their strategic projects, several of them were experiencing challenges. Some of this was related to poor project definition, some due to poor project management and some was a consequence of absentee project sponsorship. A comprehensive review of all of the projects underway was undertaken, which was around the time that I found myself in the orbit of the organization.
Reviewing the intent, desired outcomes and defined scope of each project, a couple of significant surprises emerged. One of the key projects—and one of the more challenged ones—was trying to establish a new invoicing capability, in order to accommodate the new lines of business. Given the fact that they were interacting with their clients in new ways, the logic of this was pretty inescapable.
At the same time, one of the other struggling projects was creating the capability to support and deliver solutions within one of the new lines of business. Again, strategically important; from the perspective of the organization, the initiative was critical to the sustainability and success of the organization. What emerged quickly in the review, however, was that in response to a need to get money from clients, this project had been developing their own billing and invoice management capability.
The consequences here are significant: two strategic initiatives had fundamentally overlapping—and completely redundant—scopes of work. That this was even possible was more than a little disturbing. The fact that each project was nearly a year-and-a-half down the road without realizing that they were substantively duplicating efforts was both astonishing and tragic. What become the most significant question was what to actually do about the projects.
Dealing with imperilled projects is challenging. Firstly, it requires acknowledging that—to phrase it euphemistically—mistakes have been made. More importantly, it requires addressing what mistakes have been made, why and exactly what to do about them. This is where things get very messy indeed.
Part of what makes things messy is about how projects get started in the first place. While there might be a business case—which is a theoretically decision making tool—these are more often sales tools rather than objective means of analysis. Rather than a comprehensive analysis of costs and potential opportunities to assess whether a project makes sense, they are post-hoc rationalizations of decisions that the organization has already made. They’re not designed to ask questions; they are designed to make the desired project look good.
At the same time, as we’ve already discussed, the project sponsor is responsible for supporting, advocating and championing the project. They are demonstrating the critical need for the initiative in supporting organizational success, and encouraging the organization to embrace the change that the project represents. In other words, they are selling how essential the project is, and highlighting the consequences and potential for organizational failure if the change isn’t embraced.
The result is that project sponsors wind up—to put not too fine a point on it—smoking their own dope. The consequence of selling the project to the organization means first that they sell it to themselves. They internalize its essential nature. They accept and embrace the project as critical. Failure is not an option.
This means that when significant challenges emerge, sponsors struggle with how to react. The stages of grief—denial, anger and grief among them—are at the forefront. Whether they get to acceptance is an entirely open question, in part because the act of selling the essential nature of the project means that allowing for its possible demise seems inordinately unpalatable and unacceptable.
There is also political capital in play. As we highlighted last week, an essential part of the project sponsor role is extending their political influence in support of the project. They are committed. Which means they are also exposed. Dealing with problems requires acknowledging the challenge, and walking that back if a different path—and a different outcome—is to be realized. Even for executives with power to spare, that’s a challenging concept to contemplate. For a sponsor that feels in any way vulnerable, doing so is borderline unthinkable.
And yet, sometimes, that’s what we need to do. Doing so requires, in many instances, stepping into uncharted territory. There isn’t a great deal of guidance on how to proceed. And yet, that’s not to say that there is no guidance.
To return to our case study, the challenge that had emerged was significant: two projects were creating duplicate functionality. The results of one would be redundant. The fundamental question was what to do about it. There were several possible solutions. Which approach was most meaningful and relevant depended entirely upon who you asked. More importantly, it depended on the perspective you took.
One of the challenges—and the factors that led to the duplication going as long as it had—was that the projects had two completely different sponsors. One was focussed on building billing functionality that directly and specifically supported the new line of business that the project was enabling. The other billing-specific project was focussed on creating a broader corporate capability that could ultimately be leveraged to support several business lines over time.
Theoretically, the corporate project should have had an edge; not only was it being built to support the immediate product launch, but it was being designed to support future growth and expansion. It didn’t help that it was the project that was experiencing the most challenge. Part of that was a product of complexity. Part of it was that the project was trying to support current needs while anticipating future ones, where those hadn’t been fully thought through. And partly it was because the project that it thought it was supporting—the project actually creating the systems to launch the business line—wasn’t cooperating very well.
In retrospect, the reasons for that were entirely obvious. The business project thought of itself as a self-contained entity. It was building its own billing capability, based upon its specific requirements. There was no attempt at collaboration and cooperation, and very little incentive to support a corporate initiative that its sponsor saw as being irrelevant.
It also didn’t help that the two project sponsors didn’t like each other very much. Their’s was a rivalry that had been manifesting itself for several years, and each executive delighted in any situation where they got a leg up on the other one. And they weren’t subtle about it. That meant that everyone else on the executive team was acutely aware of the rivalry. It also meant that many of them kept their heads down, and tried not to get involved when animosity surfaced.
How to proceed was a fundamental question. Neither sponsor wanted to back down. Both viewed their project as essential to corporate success. And only one was going to win. In this particular case, it was the business line project that was sustained. The corporate project was cancelled, and the team disbanded. The executive that had served as project sponsor left the organization soon after.
While that was probably not the best outcome for the future, it was the choice that the organization made, and had to live with. There were a couple of reasons for making the choice that they did. The executive viewed the business line project as being more successful and less challenged (even though many of the problems with the corporate project were largely a result of lack of cooperation from the business line project). As well, the other possible business lines the corporate project was trying to support didn’t exist yet. There was a level of complexity being created that didn’t respond to immediate organizational needs.
In favour of short term expedience, then, the business line project was given free reign to continue forward. And it ultimately did deliver a solution, although it too was late and over budget. At the same time, the lack of corporate capacity meant that limitations in the project results emerged quite quickly. With a couple of years, a new corporate initiative was launched to revive what the cancelled project had been trying to deliver.
My choosing this scenario was deliberate, in highlighting the complexity of decisions that organizations face and the challenges of making good ones. At times, there isn’t a good choice—or there isn’t obviously a good choice. And sometimes the good choice is also the politically dangerous one. All of which creates fundamental challenges for executives, and for the project managers that support them.
Difficult decisions need to be made with imperfect information, and without a view of exactly how the future will play out. Except in the most straightforward of circumstances, we don’t know how our choices will play out. This means it’s hard to know we are making a good decisions. Worse, even when we know what a good decision might be, we may lack the political capital or organizational support to make it happen. It’s an important reality to acknowledge. It’s an even more important situation to develop solutions for.
For insights on what those solutions might look like, you’re going to need to come back next week.