How To Fail Your Next Project

Have you read or noticed how many IT projects fail? They fail in all kinds of ways; budget blowouts; failure to achieve the business goals; lack of business uptake or just plain old crummy software. I have to admit that I’ve been on board on some “Titanic” projects myself; they could not possibly fail and yet we all ended up scrambling for the life rafts. I started to jot down a list of reasons I could see for project failure. I guess I could have been scribbling disaster reasons until they closed the café. Here’s hoping these selections help you on your next project.

Think You Are Smarter Than Your Customers

“All customers are stupid!” This is an actual quote from a developer on one of my projects. Hard to see how a person who feels that way can ever effectively consult to clients, let alone have a good time doing it. I remembered the shock I had on hearing the remark. My “holier than thou” attitude lasted about a minute. It was then that I discovered a terrible secret: I thought the same thing! Sure I never said it but it existed as a thought pattern somewhere deep inside.

Guess what; customers can tell what you really think about them. They know when you’re pretending to attribute intelligence to them, while at the same time sniggering up your sleeve. You may, in spite of your attitude, dazzle them with your technical brilliance. Scoring points of your customer is always so satisfying, right? It comes with a cost, though.

You’re attitude has created a wall between the customer and you.

How can you get through a wall like this? You’re going to need a whole lot of trust to understand what the customer really wants. If you don’t have communication flowing throughout your project; you’re never going to supply the solution the customer wants.

The catch is; you can never truly succeed in the long-term of you think your superior to your clients. You may meet deadlines, complete the project and receive payment but don’t expect any more “dates”. You are destined to have a series of one-time client engagements. Even if you seem to succeed in the short term; you’ve actually failed.

By the way, if your customer is stupid; why did they hire you? Don’t get me started on that one!

Bottom Line: Check your arrogance at the door.

Don’t Involve The PM From The Start Of The Project

Think about a typical sales cycle for a minute. The account manager, salesman, business development manager or whatever they are called in your neck of the woods; sells a wonderful solution to a customer. Statements of Work are drawn-up, contracts signed and the project starts. If you’re the project manager there is a good chance that you enter the engagement at project initiation. The problem is that there is a lot of water under the bridge between that first meeting and project kick-off.

If the project manager isn’t involved from the start they miss out on crucial and often, unwritten, communication. The project manager doesn’t have a firm idea of who are the players involved; the real power sources and agendas.

I’ve been bitten by this “late arrival” problem a few times. Typically, I get called in after the project falters at the start or is simply running off track. In one case we were implementing Microsoft Active Directory. For a number of reasons we were not getting any traction and the project was stalled. Mr Fixit (that’s me) was called in as the project manager. I wasn’t involved in the sales cycle and had no direct contact with the project sponsor until after we had started.

After a few tweaks here and there, the project seemed to be back on track. We had completed scoping and requirements documents. It was around then I began to get a nagging feeling that the client and our engineers were not on the same page. I called a meeting with all stakeholders in which I asked the client to state explicitly what they thought we were doing. Sure enough even though documents had been signed, meetings had and whiteboards filled; we had completely missed what the customer wanted.

I traced the problem back to the initial meeting with the sponsor. His direction to us on the project and the vision I was handed were quite different. If I was involved at the start, I would have picked-up both the written and verbal communication. In this case we wasted three weeks; you might see your project drift over the edge with a problem like this.

Bottom line : The project manager has to be involved on the project as soon as possible. The alternative is miscommunication, trust breakdown and project derailment.

Tell The Customer The Project Is Finished When Its Not

I laughed out loud when a developer claimed they finished a project on time when I knew it was a completely false assertion. “Come on! You gave the client a box of half finished bits and then spent 8 weeks making it work!” He sheepishly admitted this was the case. I pointed out that the client knew it wasn’t finished and just as much as the development team.

You may get away with throwing the project over wall to the customer and running away. You can rest assured that you wont be called back. You’ve broken trust and implied the client is stupid enough to believe the lie of false completion.

You budgeted 1 week for implementation and find yourself spending the next month in cleanup. The client knows that you’re not fixing deployment issues; you’re finishing the project! A side effect of this is that if we fool ourselves about project completion; we don’t learn from our estimation and control mistakes.


Bottom line : Call it finished when it’s finished. If you’re over time at least have the guts to admit.

Let The Developers Add Lots Of Cool Features

How many times have you heard developers complain about the dreaded “feature creep”. “The customers have changed their minds again”. “They want to add more functionality!”. I use to shake my head at the seemingly, fickle customers, too. Then I caught myself doing it! Feature creep, I mean.

Funny how subtle the “adding extra bits” disease can get you. One minute you’re casually constructing a component, design in hand and then you have (another) neat idea. It makes such sense to add an extra piece of functionality while you have “the hood up”. “They will just love this!” is what you’re thinking. Almost without knowing you’ve deviated from scope; the scary thing is that nobody may every find out.

My advice to developers is take a long, hard look in the mirror. You’re looking at possibly, the worst offender at feature creep. Not the customer; you.

I was project managing a Web development project recently. We were using prototypes and use cases to derive requirements. The prototype had just been frozen and work on development was beginning. I offered to develop a couple of minor pages to help the team. Things were going swimmingly. I was cranking out ASP code like the wild thing I am. After a while, I came across a question on the interface; I pulled-up the prototype to confirm. Whoa! It had changed! Luckily I had instigated the shared room approach and so could call out to the prototyper (or should I say perpetrator); “what has happened to the mock-up!”. You’ll never guess what she said; “Well, I had this great idea last night…”


The annoying thing was; it was a great idea! So, I did what any sane project manager would do; I told her I loved the idea but take it out. The customer had not asked for it; we are not going to deliver it. It was so small, so minor. Why not squeeze in this itty bitty feature?

“How does a project get late? The answer is one day at time”.

Bottom Line : If you want to make your deadline; watch the development team and rigorously reign-in changes. Or should I say; cool ideas.

Make Developers Work Long Hours

This is one of my favorite ways to send a project into oblivion. Don’t get me wrong; there are times in the project lifecycle where a few long hours can be expected. The final dash to the finish line, the panic session to fix the broken build. Sometimes it does make sense to work long hours.

The expectation of long hours can become part of the development team’s culture. How late you worked is an index to your dedication. Pull an all-nighter and you’re elevated to the ranks of the immortal. Hard work, dedication what could be wrong with that?

The continual long hours wears down the project team. The result is error rates increase; documentation is discarded and quality deteriorates. There are two main challenges in development; listening to the client and building the software to meet their requirements. How can you listen effectively to team members and customers when you’re exhausted from a regime of long hours?

The law of diminishing returns come into play as rework is increased: resolving defects and redevelopment of functional misteps consume the teams time.

If you find the team is living in death march syndrome, better stop and figure what is wrong with your project. You have fundamental issues to deal with. Adding more resources will slow down development and sidetrack you from fixing the core problems.

Bottom line : Work smarter not harder. Go home. Take the dog for a walk. Kiss your kids. Rebuild your self and see your quality go through the roof.

Don’t Listen To The Customer

There are so many ways of gathering requirements; the process of discovering what the customer wants. Some approaches, like use cases, seem to work quite well. We have tools that support UML techniques and that also integrate with development tools. The issue I have with any methodology or framework is that can deflect from the crucial development skill; listening.

Have you noticed how the more experienced developers become the worse their listening skills are? Maybe the problem is that we have so many ideas in our heads, so many ways of solving problems; we can’t help applying them to situations. We’re forgetting that customers are, well, people. Their problems don’t seem that unique, what harm can there be in jumping to conclusions? After all, we’re just filing in the blanks.

What would happen if; we stop, listen and put an end to the developing based on assumptions? One thing is for sure; we’d have less rework and so-called feature creep. The argument about what is in and out of scope often comes down to the interpretation of words. Who mean what. You can have all of the diagrams, use cases, documents and slides you want; these wont work in the end of you don’t listen.

Bottom Line: If you’re not listening to the customer what are you building; it’s probably not what they want.

Conclusion

There are lots of ways to guide your project to safe harbour. We’ve talked about only a few. Try these on your next project before its too late:

Check your arrogance at the door.
Get the project manager involved from day one.
It’s finished when it’s finished.
Control development team feature creep.
Work smarter not harder.
Listen to the customer.