The slightly facetious signs of a project in trouble.

So I was musing back on a number of large projects (a few in particular) that were abject failures, and I was wondering what advice I would give to someone as to what the early warning signs are and when to jump ship. So it seems every project manager blogger has one of these lists, and they include things like:

Management direction is inconsistent or missing

• Team members don't listen to one another.

• The team is in a state of discord.

• Diversion of resources.

• Milestones not being met.

• Scope changes.

Seriously folks? That covers departments at every place I have ever worked (in some cases the entire organization) and pretty much every project. This is kind of like the list of symptoms that indicate you may be paranoid – “…mistrust, hypervigilence, difficulty with forgiveness, defensive attitude in response to imagined criticism, preoccupation with hidden motives, fear of being deceived or taken advantage of, inability to relax, or are argumentative.” (1) Heck, I have all of those to some extent or other! I certainly know folks who have all of them. (Wait, is he talking about me?)

So what is my list of things to be aware of in established projects that may indicate trouble.

1 – Change your logo and/or motto. Of course every good project has to have a motto and logo. A major project I was working on hit the wall after about two years and decided clearly the top priority in resetting the project was to have a new logo and motto.

The project was about 12 months behind, many millions of dollars over budget, had a TCO that was nonsense, and no one had seen one line of code after 2 years of development, but the answer was to bring someone new in to “fix” it and, damnit, they wanted a new logo and motto. Se we had a competition. Since the project was on track to go live about 5 years after initiation my entry was “Building tomorrow’s legacy today.” Senior management loved it until they were told I was being sarcastic.

2 – Your TCO and budget have huge and consistent holes. So I am not talking servers turned out to cost more than expected. In one case I was asked to look at a budget and there was an entry for a rules engine. This was the early 2000s before the concept was in wide use and whoever developed the budget had no idea what a rules engine was or how to price one. So someone said go talk to Steve (not his real name).

They asked Steve how much he thought an enterprise rules engine would cost. Steve suggested they put in a marker for 200, meaning 200 hundred thousand. They put in $200. Now not only does that not even pass the sniff test for reasonability (MS Office was more expensive), but the process was fatally flawed. One on project I had to take bad news (again) to the program manager that we had missed another item for 300k. She signed a change order without blinking. Enough said.

3 – The project has a walled city philosophy, often based on a faulty TCO. Here’s what happens: huge project, executive management wants a TCO and budget. Problem is to do it well takes 3 months, they need it next week. Everyone knocks together figures based on previous projects with some swag thrown in for good measure, and a 30% contingency. The contingency was not really contingency it was uncertainty, but as a contingency percentage it was way too high, so the project was approved with a more reasonable contingency of 10%.

A month in to the project someone asks if we included numbers for end to end testing and down-stream integrations. The answer (of course) is no, because they pulled together a swag in a week (although that swag is now cast in stone as a budget). The project says that since it’s not in the budget that is not their responsibility, all they have to design is how to get data out, they are not responsible what happens after that.

The problem of course is that end users don’t care whose budget it was in, the system either works or it doesn’t. What is even more inane is that if there was a budget miss, even if the project doesn’t pay for it the institution still will. One PM told me their projects responsibility ended with them sending a message to another system and getting the result back, they were not going to even track what happened in between. The project failed.

4 – The architects who designed the system were not domain experts. That is a nice way of saying technically idiotic decisions have been made. You are replacing a mainframe system with a java system, but no one identified that there were huge batch jobs running nightly on the mainframe that are not suited to be run on the platform you’ve selected. The problem is the TCO and ROI were based on being to sunset the mainframe. Solution – run Java on the mainframe (because all you know how to develop in is Java). I’ll leave this one at that.

A sub-theme of this is having people who should not be making technical decisions driving the architecture. This could be the CIO who feels he should know every technology and makes snap architecture decisions, the CTO who had a relationship with a consulting firm at a previous job and insists on using them (even though they have never operated in your state), the CEO who has a golfing buddy who (…), or the program manager who implemented a data-warehouse in 1998 and doesn’t realize that the world has moved on.

5 – Every technical expert is throwing around red flags and waving their hands in the air but no-one is paying attention. One project I was not personally involved but joined the organization later, was rolling out a very large patient-care system. The system was put through an internal architecture review, and every technical expert warned it would not scale. The vendor insisted they had installed at scale at multiple sites. The business chose to believe the vendor and not the technical experts they paid to protect their interests.

The system was rolled in test and passed with flying colors. Pilot was a grand and self-congratulatory event. Full production was a big bang model (another red flag BTW), and when it was switched on it failed spectacularly. The best of all – the internal IT group who tried to raise the flag was held largely responsible for the debacle. Listen to your people, that’s what you pay them for.

6 – The relationship with the vendor is too cozy. This is possibly number one for me. Having worked for a vendor for 5 years, I can tell you for many companies Nirvana is the client you can persuade is your partner, not your client. Think of all your vendors who have become your friends, you know on Facebook, and you have been to countless (non-compliant) dinners and lunches which they have paid for. They even invited you, at their expense, to tour their facility (with associated benefits). Do you really think that when the project goes south and you are threatening legal action they will still be inviting out?

One project I was on had a partnership with a large consulting firm who also happened to supply about 150 developers to the project. They adopted a waterfall approach, which basically meant (in their world and contractually) not one line of code was to be delivered before 12 months – no quality control. The contract said the deliverable was an installable CD and that alone should have been a red flag considering the development effort was many hundreds of thousands of lines of code. They delivered an installable CD. The installed “product” did nothing – literally. Escalation followed, but since the partnership was so critical we refactored the delivery dates. Gotta love clients who are “partners”.

Vendors are not your friend; they are your supplier. That does not mean you should never enter into a partnership with a vendor; what you should never do is allow the relationship to become overly cozy and obscure your judgement.