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.
Like this:
Like Loading...
Anthony's Blog 