Rick Cook on February 14, 2013
The relationship between a project and its management sponsors is a lot like a romance. It not only takes effort in the beginning, to attract the object of your desire; it also takes constant effort and attention to keep the relationship alive and vital.
In a romance, that includes flowers, chocolates, and sexy negligee. Those aren’t recommended in a business executive’s management/project relationship, but there are project management equivalents. To keep the CEO’s or stakeholders’ support as enthusiastic as the day they agreed to fund your project, you have to pay attention and actively court your sponsors throughout the life of the project.
The fact is: Almost all failed projects had support from the top at the beginning. But for one reason or another they lost that support and the project was doomed as a result.
Keeping management support takes many of the same tools it took to get support in the first place: a solid rationale, a vision of where you’re going, and confidence in the ultimate bottom line. What is different (somewhat) is the tools you need to use to keep management behind you.
Often, there is a rational reason for management withdrawing its support. Businesses change rapidly these days and so do corporate goals and needs. If the project is no longer aligned with the corporate vision or the corporate bottom line, it’s probably not going to make it.
But much of the time, upper management simply loses interest. They become attracted to other things, such as projects that look even more profitable, and they decide to shift resources. This sets off a death spiral; schedules slip because the resources needed are no longer available, and eventually the project fails.
The other common killer is growing doubts about the project’s ability to deliver. Support that was strong when the project was new and shiny dulls and weakens as the inevitable problems arise and expectations are lowered.
While you can’t keep every project viable, every CIO or development manager should use these tactics to keep management behind the project as it wends its way through the development process.
The most important thing you can do is to execute well. If the project is on schedule and within budget, it’s a lot less likely to lose support.
That is, of course, the sine qua non of all project management. However, it is not easy. Being a project manager is a lot like being head chef at a top restaurant. You’re only as good as the last meal sent out the door. You’ve to stay on top of the whole process constantly to ensure that success.
This is why the project manager is, or should be, paid the big bucks.
Another thing that should go without saying, but all too often doesn’t happen, is the need to be honest and candid with management about the state of the project. Most of the time this isn’t outright lying; it’s about spinning the truth to put the best possible face on things.
This is extremely dangerous. Fundamentally, management’s support for your project is built on trust. They must believe you and your reports. If it becomes obvious you’re being overly-optimistic on a regular basis, they’re going to take what you tell them with a grain of salt. Do too much of it and your project is likely to die of halotoxicity.
In project management, no news isn’t good news; it’s the kiss of death. Part of a project manager’s job is to make sure that the management supporters know what’s going on. That means communicating, effectively and often.
(Of course, in order to do that you have to know what’s going on in the project in detail. But then that’s part of execution.)
This is – or should be – more than just passing data and printing out reports. A free flow of information is an important part of building that all-important trust with your supporters.
In this context “communication” means a good deal more than including the management supporters on an e-mail distribution list. In fact that’s likely to be counter-productive because it buries upper management in what is, at their level, trivia. Instead, use personalized communications aimed directly at the managers involved to keep them in the loop and remind them what you are doing – and why it’s so important.
Communicating upward should include a modest amount of blowing your own horn. “Modest,” because too much self-promotion produces a negative reaction. Still, if something positive happens, it helps to make sure the people above you know about it.
One useful tool for communicating upward is a project dashboard that gives managers a high-level view of what’s going on. The same dashboard helps everyone involved in the project – the workers – updated with the view from 10,000 feet. Most modern project management tools have facilities for setting up multiple customized dashboards for providing information for different audiences.
Momentum is one of the most valuable and least tangible assets of any project. Of course you want to keep the project momentum going, for team morale as well as to make sure you stay on schedule.
But visible momentum is also important in keeping management support. If it looks like things are moving right along to the most casual of observers, it’s a lot easier for your supporters to stay behind you.
One way to build momentum is to take a leaf from Agile development: Set lots of small waypoints which are met frequently. Psychologically, this is more useful than having a few major milestones; it provides frequent positive reinforcement for team members and executives alike.
Let’s be honest: At least some prototyping and other show-and-tell type work is done not for the benefit of the developers but to build support among management. That’s not a bad thing. Like everyone else, managers like to see tangible progress. Since it’s often hard to relate to the internal workings of a project as it jells, it helps for upper management to see a demonstration that everyone can understand.
Generally, a management-oriented demonstration should pay careful attention to the tangible parts of the project, such as the user interface, and perhaps less detail given to the internals. Use lots of examples, with storytelling about user scenarios. The idea is to provide a visible, easy-to-understand snapshot of your progress which highlights your (laudatory) accomplishments, acknowledges the challenges to be overcome, and makes it clear what resources Management can provide to do that overcoming (such as the budget for another QA person).
There are, however, a couple of dangers inherent in the Prototype Polka.
First, make sure your supporters don’t confuse the prototype with the product. By their nature, prototypes have limited functionality. You don’t want upper management or the users you support to get the idea that the prototype represents the full state of the project. (For some reason, even if you say, “This page hasn’t been styled yet,” they tend to respond, “Are those the final colors and fonts?”) Such confusion leads to disillusionment and consequent loss of support.
The second problem is that even a quick and dirty prototype or other demonstration consumes resources. Usually the more resources, the better the result. But those resources have to come from somewhere. You must make sure you don’t pull too much off the real project to build the mockup.
It also helps to have tools that let you show progress along the way without having to build new versions of your prototype. With the right tools you can go beyond the prototype and build betas or early versions you can use to demonstrate progress. The best of these software development tools allow you to concentrate on the business problem rather than the infrastructure and hardware details.
Much as we’d like to think so, projects don’t exist in a vacuum within the enterprise. Everything from the state of the stock market to announcements from competitors to shifts on Mahogany Row can have a major impact on your baby.
This is the other half of communicating with your sponsors. You not only need to push information up; you need to take advantage of what flows down.
One vitally important part of this process is listening to and responding quickly to your internal customers. You not only have to move quickly to respond, you have to be seen as responding to customer input promptly and positively. Like any romance, it isn’t enough to simply do it; you have to show the other party that you’re doing it.
Staying aware of management attitudes is complicated by the fact that the people supporting aren’t always completely forthcoming about what’s going on at the top. You need to keep your antennae out and read the tea leaves carefully. Having other sources of information doesn’t hurt either.
One extremely important signal is a diversion of resources from your project. Even a small temporary transfer of person hours or budget to other tasks should be watched carefully and understood as fully as possible. If there’s a major diversion, it’s a clear danger signal; plan how you’re going to react to it.
The worst thing you can do in this case is give the impression that “We can take the hit.” You need to make it clear to those above you, preferably in writing, what this diversion is going to cost the project in schedule slip and budget.
Generally speaking, the longer the project’s duration, the more likely it is to lose support and ultimately be cancelled. This is doubly true if the project won’t produce any deliverables along the way.
Keeping management support doesn’t have to be an all-consuming job. You always need to do the basics, but beyond that how much effort you put into it depends on the circumstances, such as internal resistance and the length of the project.
If this sounds like work for the project manager, it’s because it is. Sometimes it can be a flat pain in the butt to take time away from other jobs to keep management support. But it’s part of project management.
And it’s one of the reasons they pay you those big bucks.
Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.