How to Guarantee Software Project Failure 70% of the Time

There are many ways to mess up a software project – What I’d like to discuss here is a common misnomer that fix bidding a project somehow mitigates any risk – in fact, fix bidding only increases it. I realize the organizational theory behind this common practice:

“Control costs by putting some of the risk of completing the project into our vendor’s hands”

In the real world, however, the theory does not hold true. There are several things you should consider before asking your vendor to fix bid a software development project:

It’s impossible to accurately estimate software development
First, we need to agree on one thing. There is no software project that winds up exactly like you had planned it. What I mean is that software development is a series of course corrections – if you were able to see all of the risk, and had everything architected and planned out perfectly – than you would be better than 99.999% of all other technology companies in the world. Microsoft, Adobe, nor Apple commit to release dates for this exact reason – they know that software development is predictably unpredictable.

There are only 2 possible outcomes
When you ask a vendor to fix bid a project, there are 2, and only 2 outcomes.

1. You get the vendor to lose money because they did not accurately estimate the project. This may seem fine to you, but the second and third projects you do with a vendor are always more efficient – if your vendor losses money they will not come back (and you will have lost that second project efficiency) It pays in spades to have a vendor understands how to work with you, that knows your business and that can have open communication and collaboration

2. Your vendor is able to do the bare minimum in order to fulfill on the requirements and they make a killing. Recently I interviewed a sales candidate for a large interactive agency. The individual revealed to me that their most profitable projects were those that were fixed bid. He simply took the project team’s estimates, doubled or tripled them, and never told the project team that they had the additional budget. It forced the team to work in a budget that was great for the agency, and horrible for the client.

Given these 2 outcomes, you have now successfully set up an antagonistic relationship. You are constantly questioning your vendor’s motivation, and they are pushing back on every little change because it effects their bottom line. It’s like putting a sword into 2 people’s hands & telling them “winner take all” – and then being surprised when the 2 people don’t get along.











You lose the ability to make course corrections
If you agree that software development requires course corrections, than you must agree that it is critical to frequently review project objectives, estimates, and timelines. It is also critical to validate the software with end users, to make sure the software is meeting their expectations. In a fixed bid situation, your vendor is heads down and not doing the proper check-ins and validations. Even if they do usability testing, they are incented to look the other way.


Bottom of the Barrel
The high risk of taking on fix bid, from a vendor perspective, means that you will likely get only those vendors that are desperate enough to take on that sort of work. Ironically, you have introduced a ton of risk into the project’s success. You might as well take the money to vegas and put it on “Red” … (actually – your odds are better in vegas – according to forester, 70% of all development projects fail because they are not accepted by the end user of the product)











You may ask: “So, how do I manage my budgets?”
First, understand that services companies are not in a “high risk” business. Asking them to share in the risk and not share and not share in the reward is almost alway inappropriate. Yes, you are (hopefully) paying them a great rate for their services and therefore it is completely appropriate for you to expect them to provide quality people and good-faith estimates. But asking them to “put skin in the game” means that you are asking them to do something that is outside of the philosophy of services businesses – Services companies traditionally make lower profit margins; especially when compared to higher-risk / higher-reward product companies. The shareholders in services companies are in that business because they are less risk-adverse than you. Does that mean it is hopeless to mange outsourcing. Actually, outsourcing can be much more cost effective than bringing development in-house. Usually, service providers have people that are more up-to-date on the latest technologies, and have seen many more projects and obstacles then internal project teams.

So – how do you get the most from your vendor while maintaing a good relationship?

1) Treat your vendor as as a partner
A colleague of mine, Rebecca Flavin, explained to me what a great partnership looks like:

A great partnership is where either party would willing trade places with one another

If you think that you “won” because your vendor lost money on a project, think again … Eventually, you will wind up working with only “bottom of the barrel” companies.

2) Demand accurate estimates, but only for short milestones
Trying to accurately estimate a large software development project is next to impossible. One of my favorite quotes in the world was something John Cleese said when he was discussing the value of creativity:

“If you are absolutely hopeless at something, you lack exactly the skills needed to know that you are absolutely hopeless at it — This explains so many things in life”

This translates into software development perfectly. How can you adequately estimate something if it has never been done before, and that you know things will change along the way? The way to mitigate this undeniable truth is to let everyone know the end goal and allow the team to set short milestones and estimates along the way. This gives you, as the project stakeholder, the ability to course correct before its too late. Demand the data you need to allow you to make the right decisions….

3) Be okay with uncertainty
Be okay with the fact that things will not look like you initially planed them (unless you have unlimited cash and time). Agile development is an excellent model for software development. It accounts for the fact that you will never know everything before you start a project – it is execution focused. Do enough planning an product strategy up front to ensure you are headed in the right direction, but don’t get bogged down into detailed requirements documents – they almost never accurately articulate what the software will do when completed. Allow the requirements to build and modify as the project progresses. This DOES NOT mean “give your vendors a bunch of money and let them figure it out along the way” – Agile processes empower you and your vendor to spend the money more wisely, and to have levers to pull when you hit roadblocks or find out that you are missing the mark during user testing.

4) Be okay with some imperfection
Google’s software is in perpetual Beta. They understand that they have an obligation to provide the right mix of utility and usability while trying to push software out in a timely matter. You can easily spin your wheels trying to fix a minor bug for weeks and months and lose sight of the bigger picture. People will allow a certain number of very minor bugs in software as long as they are getting value from it. I’m using Blogo to write this post. It has an annoying bug that pushes my window off screen every time I change my monitor resolution – Despite the bugs, I use the software (and paid for it) because it still offers me more utility than posting directly in wordpress.

That actually leads me to my last point – we often forget that all of technology is geared for one purpose: to improve the lives of human beings. No matter what vendor you choose, or what process you decide to employ, make sure everyone is hyper-focused on that person that will be using what you are building.


  1. Nice post and this philosophy will probably seperate the winners from losers in creative services business for the coming year. What some folks might infer here (but I know your not saying) is that projects done in this fashion still require excellent project management that provides a level of transparency to keep the partnership strong.

    It sounds trite but some of the best craftsmen I’ve ever hired (be they designers, coders, electricians or painters) frequently did their best work when it was time and materials.

    We’re currently in a ‘beat up the vendor’ mode in our economy and it’s important to focus on principles that don’t enable or foster failure. When you’re doing something new, flat-bidding is probably one of those behaviors.

    Chris Bernard
    User Experience Evangelist

  2. Mamoun J. said:

    Amazingly great article, thanks.

  3. I still have yet to develop an app, maybe it’s writers block, but I’ve been part of the dev group for almost a year and haven’t even opened the SDK yet…
    POS System Software

  4. Hey Anthony. Good article. Lots of excellent points. After having collaborated with numerous services contracts with Consulting orgs in the past; I’ve learned that they (the consulting companies) don’t really like an Agile model. Their profits often are dependent on the customer requesting “change orders”. By low-bidding the original work, they can secure the business with the certainty that the customer will request changes as the product comes together. As we know, no-one really knows for sure what they want up-front – so guaranteed the customer is going to request changes as their understanding and knowledge improves. If they were to adopt an Agile model to services work, they’d have to build that gradual knowledge gain into the pricing. This would be good for the customer, but bad for the consulting orgs. They have a vested business interest in avoiding an Agile approach.

    Chris Ronak

  5. You have successfully articulated my exact feelings on the subject of fixed-price bids. I would add that any reputable software development company will give the vendor their monies worth for each hour charged.

    Matt MacKay
    Metrisoft (

  6. Sergio said:

    А если посмотреть на это с другой точки зрения то не все так гладко получается

    And if you look at it from another point of view it is not so smooth turns

Leave a Reply

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

You are commenting using your 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

%d bloggers like this: