68% of All Software Projects Fail…

Failure(credit to unsoundtransient on Flickr for this pic)

Yes, you read that right. Only 32% of projects made it on time, on budget. 68%  of all projects failed in some way or the other. What was the number 1 reason for failure?


Requirements that are incomplete in some way…

Poor requirements gathering

Poor requirements analysis

Failure to understand what the customer or user (or both) really want from the onset (and now it’s too late)

No KPIs (Key Performance Indicators). On second thought, if you don’t know what will make it successful, you won’t know it failed either! 😉

Shocking eh? I think so too.

Now let’s look at how do we avoid this.

1. Know Thy User

This should be simple right? Know who you are working hard for. Who is the ultimate audience? A client? A user? Both a client and a customer? Surprisingly, an immense amount of hard work and $ are spent without knowing who is it that is really going to be using your product.

Knowing this is immensely important. If you do not know your audience, you will have none.

Once you do know, conduct some requirement gathering sessions with them. It could be as simple as 1 – 1 interviews or a phone conversation or as complex as a contextual inquiry. The key is this:

a. Identify with their pain (or unmet needs) once you discover and document
b. Ask “What can we do to solve this?” or “How would you figure this out if you were me?”
c. Document and discuss with your project team

2. Know Thy Plan

Once you document and discuss, engage with your business stakeholders and Project Manager to chart out a plan. What’s in? What’s out? When? Agree. Disagree. Play the game again. Freeze your plan once there is an agreement.

Don’t discuss the “How” yet. Users don’t care about how well you code anyway 🙂

3. Know when to say “No”

I know it’s hard. It makes you unpopular. Life happens. Scope creep happens.

You get accused of not being flexible.  The only way to get out of this is to consult others, chart out an estimate for this new bell/whistle that has made its way in and really weigh how valuable this new feature will be. Go back to Step 1. Hopefully, your documentation will guide you. Talk to your friends – the programmers. Ask them how long will it take to build it. Bring your PM in.

Let’s also be real. You will get trumped. Someone who has been there longer or who plays golf with someone who is more influential  is demanding it. You? You don’t even like golf.

So be open to the possibility that the sky is not always blue… and you always have proof that you said “No”.

I hope this helped some. See Usability.gov for more info on requirements and use cases.

Here’s hoping your project will NOT be a statistic.  And remember, don’t let anyone define you.

Neither success nor failure.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s