Dealing With Projects That Just Won’t Die

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

There are some projects that just won’t die. A friend of mine who is a fine consultant calls these projects “The Undead.” No matter how you try to kill them, they keep on going.

An example: You spend tens or even hundreds of hours on a database, only to watch it balloon into a full-blown app at the client’s request. Or you invest a good deal of your own money in a small network that becomes, little by little, a major piece of your infrastructure. Either way, you’ve spent more time and energy than you can afford.

Of course, this is no problem for Accenture or IBM. They have thousands of workers to drop on a problem, and they can afford to waste a little time here and there. (Consider the fact that IBM’s Global Services division, with its acquisition of PricewaterhouseCoopers, mushroomed to more than 150,000 consultants.) But in a one-, two- or 10-man shop like yours, a single project that goes on for months can destroy your ability to pay the rent.

So how do you stop an unstoppable project? Believe it or not, it can be done—and it’s not hard.

First, Know Why
It helps to know why projects drag on, sometimes ad infinitum. By and large there are three main reasons:

 

 

  • To keep a failure from being a failure. “Never say die.” “Keep on going.” “Don’t quit.” We’ve heard it all before, and as entrepreneurs we’re loath to call a project a failure, even when it’s clear that it’s as cold as a cadaver. Sometimes we pour time and money into a failure to keep it from being a failure, to get one more day—or week, or month—to turn a project around and wring something good from it. Clients are much the same: They’ve sunk hundreds (or thousands, or tens of thousands) of dollars into a project, and they won’t quit until they see it work, even when it’s clear that it can’t.
  • Politics, plain and simple. In a corporation or any large enterprise, people stake their reputations on the success or failure of projects. A vice president may have his Christmas bonus invested in the success of a new piece of software. Much the same, the CEO may have promised the board of directors a miracle with the new CRM app. And when it doesn’t work out—when the project runs over budget and chews up time—they refuse to let it go, or merely reconsider.
  • Unethical vendors. There are consultants—not you, of course—who keep a dead project going in order to keep on billing. Not only is this unethical, but it’s also a poor business strategy. Sooner or later the client will find out and boot the vendor out of the building. The problem is, large projects involve multiple vendors, and another shop may be trying to breathe life into a corpse of a project that you and your company are involved with.

 

Each of these problems can be solved with a single, frank discussion. Just muster your tact and marshal your patience, then head into the client’s office with the intent of talking straight. It’s the fourth problem—“scope creep”—that’s hard to kill, so we’ll devote the next section to it in its entirety.

Scope Creep
A project’s scope is another way of saying its size or extent, what will and won’t be done under its rubric. For example, you may have two Web sites to build, one whose scope is five times the size of the other on account of its back-end database.

Clients have a way of increasing the scope of a project little by little. Let’s say you build a palmtop app for a company’s growing sales force, and the CEO, impressed with your work, invites you to teach him (and his wife, and his daughter) how to use their iPaqs to read the news, get their e-mail, sync their schedules and so on. You can’t say no—you need the check—and it’s only a few hours of time. But at $150 an hour, that’s $450 you’ve given in non-billable service. Good luck paying the rent.

A statement of scope can help. Simply put, a statement of scope is nothing but a document that outlines, in some measure of detail, what you will and won’t do for your fee. If you’re building a database, you list all of its features, down to the last search algorithm. If you’re building a network, you stipulate the number of servers, clients and so on, and be sure to state the size and type of backup, the level of remote access and the nature of the documentation you’ll provide when you’re done. The more detail you give, the better.

But just as important as what you’ll do is what you won’t. Use the statement of scope to mention what your fee does not include. That way, clients know what’s verboten to ask for, or they know that asking for it will increase the fee.

Last, be sure to have your clients read, sign and date the statement of scope, then reference it in the contract itself. Thus, you’ll have a legal agreement that cuts off scope creep before it can start.

More Paper
There are other documents you can use to save projects from reaching the kill zone.

The first is a mission statement, a simple paragraph or two (and in some cases, no more than a few sentences), that outlines your goals, time frame and rationale for doing the project. Remember, it’s not the prose that’s important; it’s the decision process you start with the client. It makes him consider his goals in depth and ensures that both of you have the same vision for your work. As with the statement of scope, you can attach a copy to the contract and ask the client to sign and date it.

Yet another piece of paper to keep handy is the project schedule, with a twist. Most schedules say what you’ll do and when. That much is obvious. But a good project can hinge on what the client does and, just as important, when she’s supposed to do it. For example, if you’re building some back-end software for customer service, say, a database that tracks complaints and sends letters to angry customers, the client will have to furnish you with the text of those letters at some point in time. But chances are, your client will give you the text a week or two late—then expect you to deliver the software on time. You can use a project schedule to set deadlines not only for you but for your client as well, to make sure he meets them and lets you do your work unobstructed.

When All Else Fails
Even the best-laid plans, as the proverb goes, are prone to fail. Like we said before, there are some projects that just won’t die, no matter what you do or how well you’ve planned them. And letting them go unrestrained can bankrupt your company.

When you’re faced with a project that threatens the life of your firm, you have few options to choose from. The first? Show the client the bill. If they’ve asked for change upon change or piled on new features, explain that your fee is growing daily. And don’t merely say it: Show them a log of billable hours, carefully annotated with time, date and task, along with a running tally of fees. When they see the net result of their endless requests, clients will cave in, and more often than not, they’ll agree to call it quits.

On this note, you should remember to write your contract in a way that provides for partial payments, either by time or project milestones. This way you have a down payment and one, two or three interim payments, as well. Just as good, you won’t have to submit a final invoice that gives the client sticker shock.

The next silver bullet is the direct meeting with the project sponsor. This is often a senior executive at the company you work for. Sit down with her and explain the predicament: where the project’s at, why it’s late, when it might be done (or why it can’t be done) and what stopped it. Whatever you do, don’t lay the blame at someone’s feet. Be tactful and use your schedule, statement of scope and mission statement as backups to show where things derailed. Make sure to explain why it’s smart for the client, and not merely for you, to get the project under control.

And last, of course, is biting the bull

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
cmadmin

ABOUT THE AUTHOR

Posted in Archive|

Comment:

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>