Keeping Your Project Sold
Most software development lifecycles start with an initial phase called a feasibility study, an opportunity evaluation, or an investment analysis. Whatever it’s called, the stated purpose of this first step is to determine whether a project is worthy of pursuit by the enterprise. To this end, a cost/benefit analysis is often performed, risks are identified and weighed, alignment with strategy is evaluated, and then some final determination is made: here is the money you requested, proceed with the next phase of the project; or, conversely, your project didn’t make the grade, go back to the drawing board and try again.
Whatever the process followed, many projects assume that, once they have been given the green light, along with their requested funding, they are free to go forth and spend, and need no longer concern themselves with the job of selling their project: the deal has been struck, the bargain made, and the inexorable wheels of system development have been set in motion.
Alas, in my experience, reality is often more complicated than this.
In truth, although you cannot see it, there is always a balance scale in the background, weighing the cost, benefits and risks of your project against those of other potential investments. All it takes is for the scales to tip slightly in the wrong direction before your funding is yanked and you’re left wondering what went wrong.
In order to avoid this fate, you need to keep a few things in mind.
What Your Project Needs Besides Money
The initial funding decision often grants a project some titular authority to proceed, and some amount of initial funding. What more could a project need, right? Well, actually, most projects will need all of the following in order to proceed down the path towards a successful implementation.
Executive Sponsors
Your project will need the active support of one or more well positioned executive sponsors in order to succeed. Note that formal changes in assignments, informal changes in organizational power structures, evolving executive perceptions of your project, and/or competing pet projects can all undermine at any minute the support you thought you had for your particular effort.
Eager Users
You don’t necessarily need all potential users to be eager to start using your new system. But at a minimum you do need some intelligent, influential early adopters who can help to champion the benefits of using your wonderful new solution. If all potential users start to treat your product like a modern outbreak of the bubonic plague, then your project is pretty well doomed.
Stable Business Conditions
Your project received its initial funding based on certain business conditions. When business conditions change — new challenges present themselves, new opportunities beckon, or windows of opportunity close — perceptions of your project may suddenly shift, causing it to be seen as irrelevant or a diversion of resources that could better be used elsewhere.
Organizational Consensus
For large projects requiring changes in behavior by multiple departments, there will often be one or two significant beneficiaries of your project that will be backing it, and other organizations participating with lesser degrees of enthusiasm. This is fine, so long as lack of enthusiasm doesn’t evolve into wholesale resistance. But when one or two impacted organizations begin to perceive themselves as dramatic losers, they can dig in their heels and make it impossible for your project to achieve a successful implementation, even when you have all these other factors working in your favor.
Credibility
All software development efforts require a willing suspension of disbelief: despite all the horror stories everyone has lived through on past projects, people with money actually believe that your project has some reasonable chance of delivering on its promises without going grossly over budget or beyond its schedule. On its face, this seems something of a miracle. Belief in your project’s promise should never be taken for granted, though; all it takes are a few blown deadlines, and perhaps one nasty rumor, before everyone begins to doubt whether your project will ever deliver anything of value, at which point they start looking for better ways to allocate the resources currently committed to your effort.
Willing Developers
Developers often need to be convinced that your project will help them advance their careers in some way. If your project needs developers to exercise what might be considered legacy technical skills, for example, then all the money in the world might not be enough to find capable developers willing to staff your project. Other factors can drive developers away: a perception that your project is doomed to failure, a technical architecture that seems to be a mess, a line manager or project manager known for being difficult to work with: any of these can drive capable developers away from your project in droves.
Keeping It Sold
So what can you do to keep your project sold?
Here are a number of tips that I’ve found useful.
Stay in Touch with Your Executive Sponsors
And don’t just talk to them about your project. Ask them about business conditions, organizational changes, and any dark clouds on the horizon. Keep your ear to the ground for any developments that might impact your effort.
Deliver Business Value Early and Often
Seeing is believing, and regular deliveries of working software that the business can actually use will do more than all the PowerPoint decks in the world to maintain your project’s credibility.
Regularly Reassess Priorities
Meet with your customers to see if new requirements have emerged, or something once deemed vital is now viewed as superfluous, or if priorities have shifted. Be flexible and adaptive enough to modify your schedule to move higher priority items forward, and lower priority items towards the back of your schedule.
Pay Attention to Your Skeptics
Even projects with the brightest of apparent futures will have their skeptics: those who mutter under their breath repeatedly about one or more perceived flaws in your project. Even if these folks seem heavily outnumbered, listen to what they are saying: taking action now to mitigate their concerns could potentially help you avoid crippling roadblocks farther down the path.
Try to Include Something for Everybody
Your executive sponsor may want your project to deliver some important new capability that will empower the business in exciting new ways. But your users may be more interested in improving the usability of some existing functions. And the Finance department may want better reporting. While some people claim you can’t please everyone, it is often possible to include at least a few goodies for each of your important stakeholders. While his or her position on the company org. charts may convince you that the needs and desires of your executive sponsor are all that matters, don’t be fooled by their apparent authority: the complaints of a few disgruntled users can easily grow into a full-scale mutiny, and then even the captain of the vessel may be forced to change course.
The bottom line: the days when huge IT projects could take forever to lumber in a straight line towards their avowed goals have come and gone (if indeed they were ever here). Even the largest, best funded, and apparently most important projects have to be nimble, adaptive and sensitive to changing conditions in order to make it across the goal line.
October 2, 2011