Leadership optimize

Four signs your consulting project will fail

Project failures can happen to good consultants. IT consultant Chip Camden shares four red flags that he says should have clued him in that one of his projects was doomed.

Several years ago, I took on a project from a client who had given me pretty steady work for 10 years preceding. The idea of the project was to create a framework for the client's future software development, bridging between their existing technology and the platform to which they wanted to move: Microsoft's .NET Framework. We laid out a strategy, and I started work on prototyping and designing.

Since then, at least two generalized alternatives to this problem have emerged (both of which I helped develop), but at that time we were breaking new ground. Scoping the project was difficult, and it dragged on and on. Several months into it, we identified performance issues that added more time to address. Eventually, the client decided that the effort and expense wasn't going to yield the result they wanted, and they scrapped the project.

My relationship with the client remained friendly, but they haven't used me for anything since. I can't say that I blame them, if they were half as disgusted by that project as I was. I still feel a little sick in my stomach when I recall it. But a greater tragedy would result if I committed it to the depths of Lethe, because failures can teach us more than successes, if we're willing to learn from them.

This project exhibited these four signs of imminent failure that I should have noticed.

1: The project is running longer than a year.

Except in rare cases, if a project extends over more than a year, it has already failed. What's so magical about that year boundary? Funding usually follows an annual cycle, so it may be difficult to keep resources dedicated for longer than a year without delivering something. But it's mostly psychological. Project success depends more on human factors than on anything else. When the calendar rolls around to the same place where you began the project, and it's not even close to being finished, few of the participants can avoid thinking "This project will last forever." Their focus begins to shift from "How do we get this done right?" to "How do we get out of this?" (or worse, "How do I get out of this?"). Once people start looking for the exits, you can count on a rout ensuing.

2. The project is monolithic.

You can more easily avoid failure if your definition of success is easier to achieve. When a project must accomplish every one of several difficult objectives, it's set up for failure. Rather than adopting a pass/fail mentality, organize the project into discrete objectives, each of which may stand alone as a successful operation. By eliminating interdependencies, you can reap the benefit of five successes out of six attempts, instead of losing everything because of one failure. You can also decide in advance to drop one or more of those objectives if you get into a pinch, without sacrificing the entire project. Furthermore, if you deliver early and often, the client can provide feedback that may result in course corrections before you get too far along to change directions.

3: The project is not unified.

At first, this may seem to contradict reason number two, but what I mean here is that the project needs one team working together. Multiple teams, especially if they're in different locations, require extra attention to coordination and communication. I do almost all of my work remotely, so that arrangement certainly can work, but the connection to the rest of the team is often the weakest link in my projects. Of the failed projects in my history, lack of adequate communication and coordination has always played a significant role in their demise.

4: The project is not the #1 priority.

A successful project may start out as a "when you have time to look at this" activity, but at some point it has to become your primary focus or it will never get done. A project doesn't become a #1 priority for a consultant until it also becomes a #1 priority for the client; if that doesn't happen, then eventually the client will decide to stop pouring money into it and divert those funds towards more pressing needs.

For the project in question, I should have insisted on breaking it down into smaller chunks that could have been delivered no more than two months apart -- preferably less than a month apart. I should have hounded the client for feedback on those deliverables, and I should have refused to put more time into the project until I received it.

This experience made me a better consultant, but I still regret disappointing my client. Memories of that project have often haunted my occasional relapses into the Impostor Syndrome. I have to remind myself that even the most successful people must endure occasional failure.

Have you ever experienced any spectacular project failures? What did you learn from them?

Additional resources about project failures on TechRepublic

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

33 comments
Ian Thurston
Ian Thurston

My experience has been that projects that have failed have been ones where the CEO sat in the tower and had nothing to do with the task. I no longer will take on a client where that's the case.

apotheon
apotheon

Deleted; the end-of-thread input box is not sufficiently differentiated from the input box for the last comment in a thread.

WorkflowGuru
WorkflowGuru

First: Redefine Failure. While the Chaos Report shows a welcome trend toward fewer project failures, we can help it along by rethinking what constitutes a "failed" project. In my mind, canceling a project that is *badly* off-track is much more a success than "completing" the project with little value to show at the end; much better to restart with a better plan. Second: Think Agile. All four of the signs cited get handled -- by design! Before some of you launch salvoes, no, I'm not saying Agile can be applied unmodified to every project. As has been discussed ad nauseum on this and other forums, no one methodology will be universally applicable -- granted. P.S. Revisiting Sign #3, I submit to you that the biggest, most intractable issue on any project has been and will continue to be the lack of adequate communication. That is another opportunity for using Agile, as I've done for clients. Thanks, Chip!

oldbaritone
oldbaritone

New management, new priorities, new cronies. It's just a fact of life in the real world.

unconditionalliving
unconditionalliving

I've been on several very large, multi-million dollar, multi-year projects that required the completion of each and every one of several very difficult goals ... and all were completely successful in achieve all stated goals. Why? Because #3 and #4 were both totally in place. When #3 and #4 are totally solid, you can take on huge projects with very difficult goals and completely kick it. Without #3 and #4, yeah, I think there's very little chance for success.

LewSauder
LewSauder

Although there are exceptions for all of your rules, this is good advice to watch for. The most important is making the project a priority. It may not be the top priority for the whole company, but it must be a priority for someone who has authority. Otherwise, higher priority tasks and projecs will turn the project into an unecessary distraction. Lew Sauder, Author, Consulting 101: 101 Tips For Success in Consulting

Tony Hopkinson
Tony Hopkinson

Seen examples of all of them. I did manage one where the timeline was more than a year, but that was well known before hand and 2,3 & 4 didn't exist. I'd put monolithic as reason number 1 always, unless the timeline is negligible.

Sterling chip Camden
Sterling chip Camden

... that some projects just take more than a year to do. My counter is that those project will fail. If you want to keep them from failing, you must break them up into smaller projects.

Tony Hopkinson
Tony Hopkinson

Happy CEO, seems to be the front ruinner... Selling an abject failure as a success, is a necessary skill in corporateville Clue, telling the CEO it's their fault is not going to put a smile on their face. Well not until they sack you...

Sterling chip Camden
Sterling chip Camden

Some of them you'd like to keep as far away as possible. But if the CEO really leads the company, then you are correct.

apotheon
apotheon

> I'm not saying Agile can be applied unmodified to every project. I'm not sure how you'd apply "Agile" "unmodified" anyway. Agile software development is a philosophy -- not a methodology. Methodologies that follow the agile philosophy include things like eXtreme Programming and Scrum.

apotheon
apotheon

I have never really considered corporate bureaucracy to be "the real world". It looks more like some bizarre, soul-sucking fantasy world from the imagination of HR Geiger, from where I'm sitting.

Sterling chip Camden
Sterling chip Camden

... and one way to make the exceptional more abundant is to have an exceptional team. I would suggest, however, that paying attention to nos. 1 & 2 would still help you to avoid unnecessary risk.

Tony Hopkinson
Tony Hopkinson

Course when it comes to the version 2 project, kiss success goodbye from day one

brandon.barends
brandon.barends

The sponsor should sell the benefits of the project and the reasons why it is a priority to ALL stakeholders. Quite often day-to-day operaional activities are assumed to be more important than the projet since the operational business function needs to get its work done, quite often at the expense of the project deliverables if the project is not seen to be as inportant. Comes down to the selling job done by the sponsor.

Tony Hopkinson
Tony Hopkinson

A lengthy monolithic project will fail , all the priority will do is make the failure far more public...

Sterling chip Camden
Sterling chip Camden

... there are exceptions. I've had several highly successful projects that stretched the year boundary by a few weeks, and to be honest if you counted all the preliminaries and supplemental work they were probably closer to 18 months or so. I think it's particularly important not to have the implementation phase drag on and on. A lot has to do with setting the right expectation, though.

apotheon
apotheon

. . . and then there's failure. I think a lot of people believe projects longer than a year can succeed. I think they're defining project time and/or success differently from you, however: 1. They may be including time that is not actually spent on the project in project development time. For instance, if you plan a project out to some nontrivial degree, then set it aside for three months (maybe making improvements to the plan here and there in "free" time), and finally come back to it to start working on it in earnest, I wouldn't call the totality of those three months part of the project timeline for determining likely failure rate (though some minority percentage of that time should probably be counted -- a ratio that looks hopelessly heuristic from where I'm sitting). 2. Some people consider project completion synonymous with project success -- even if the end result manages to achieve the basic project plan requirements, but utterly fails to actually provide any value. A lot of long-term projects meet this description, declared successful by their developers and managers, though in terms of actual return on investment they are among the worst abject failures. Even more interesting for me (who mostly hasn't had to deal with the situation described in my list item number 2, personally) is the fact that I think the rule-of-thumb limit on project length that can succeed is getting shorter. Further, I believe it will continue to get shorter at an increasingly rapid pace, at least for a while. As we develop new tools of automation that pertain to the development process itself, much of the scut-work will be obviated, and we can focus on the important stuff. This will reduce necessary project time, showing us the truth; it's not time that is the limiting factor, but project development complexity, which contributes to the time we spend (though some factors arising from time spent may come into play as well).

Tony Hopkinson
Tony Hopkinson

Added a reply. Refreshed the page to see if it was my lucky day and reply worked. It did, but my subject line was ALSO in the join conversation box....

Tony Hopkinson
Tony Hopkinson

bastardised, and more often that not the methodologies that are supposed to meet the philisophy are being modified to throw away the entire idea.

Tony Hopkinson
Tony Hopkinson

priority = urgency in business think. Always time to do it over, never time to do it right....

mikewor
mikewor

A priority project is one that will bring in revenue when it succeeds or lose revenue when it fails. The project champion will move heaven and earth to make sure his bottom line does not get a smack. If no one has identified revenue (even long term revenue as in infrastructure projects) as one of the success factors, then itwill fail. And if, a project has priority merely because someone out a 1 in the priority column, that's not real priority. This project will fail, well before the year is up

Sterling chip Camden
Sterling chip Camden

I'd have to agree that complexity is more of an issue than simple elapsed time. That sort of feeds into the "monolithic" item as well. Too many interdependencies means that the whole thing floats or sinks, and there's a lot that has to go right to make it float. Your note about success is also salient. Conversely, something useful can sometimes be saved from even the most spectacular failures.

Sterling chip Camden
Sterling chip Camden

... both the cynical exploiters and the zealots pull it from its true path.

Tony Hopkinson
Tony Hopkinson

to count the number of times it gets done right do you? Basic problem is design and code quality are only indirectly linked to product quality in business land. That's why those of us who got left with version 1 instead of being promoted on the back of it's "success", put things like monolithic at the top of our list. Can't blame them really, after all they are playing by the rules corporates judge themselves by... P1sses me off when they tell me I'm wrong though, never done a version 2 , or simply ignore their people.... Or I suppose they could have only worked on successful projects by our definition, the lucky b'stards. Generally we get called in, when that hasn't happened.

Sterling chip Camden
Sterling chip Camden

If all you do is fight fires, then all you end up with is a sodden mess of partially burned remnants.

Sterling chip Camden
Sterling chip Camden

The champion may wish to do so with all his might, but some projects are simply too heavy. Will can work wonders, but it has its limits.

Tony Hopkinson
Tony Hopkinson

High priority doesn't mean do it right does it? A project with no business priority isn't a project, should even start never mind end up failing. It might have had one but then something changed, in which case STOP. You have too narrow a definition of sucess.