Pig in a Poke

I’ve seen numerous occasions where software is sold based on an unrealistic contract. The contract includes all one could ever dream of. Fast schedule. Cheap price. And all the killer features listed in the requirements. The dream come true is hard to believe, so the contract contains also penalties. The penalties calm everyone down; a dream come true is possible, because otherwise someone is theoretically being punished.
If a deal looks too good to be true, it probably is.
– Michael Douglas (FBI Public Service Announcement)
In reality, the contract paper is just being used as a catalyst to get the project started. When the project hits the deadline, there are no other options that just keep going. The business owner wants results. The project is almost there. A few extra bucks and the project will be finished. You can’t really use the penalties, because they would just slow things down. In the worst case the subcontractor would end up bankrupt. That would definitely kill the velocity.
All this can be avoided by transparency. The transparent win-win attitude starts from the first steps of the negotiations. Win-win culture and honest transparency are tools to succeed in software projects. If the negotiations are run in an old-school mode, where the doubt is tangible, the project will fail.

Picture: You don’t want your project to hit a deadline

Procurement Process

Software purchase follows a process: top management comes up with a new business vision, middle management creates a list of killer requirements and the procurement department sends RfQs to a few software companies they know. At the sales end: a sales person forwards the list of requirements to a project manager, who ends up with a work amount estimate. The sales person sets a price for the work and returns a quotation. Finally, the buyer chooses the cheapest quotation. Being a project manager, I see three different paths for the sales process.

1. Sell Cheap & Bargain for Extension

This is the classic tailboard (deadline) trick. It will leave everyone disappointed. This model starts with an offer the buyer can’t refuse.
I’m gonna make him an offer he can’t refuse.
– Marlon Brando (The Godfather)
When the project starts, everyone writes a lot of code using low maturity ways of working. Because the schedule is so challenging, the documentation, integration and testing is postponed until the main killer features are being launched. The project hits the deadline when it is 80% ready. Quite a few features are still under the development. All the money and time is spent. The system is “not quite yet” up and running.
Now starts the most strenuous cycle. Everyone searches for a scapegoat. Usually the project manager gets the blame. The next step is to bargain for extension; just a short and cheap extension, during which the last 20% of the work will be finalized. “It doesn’t make sense to flush all the expensive code we have already written!”. Yet another offer one cannot refuse.
The cycle of blaming and bargaining extension projects until the functionality reaches reasonable level or the project is courageously killed. The final price and schedule will be huge compared to the original offer.

Picture: Fixed price often results low quality high cost

2. Sell Buffer

Quality software houses seldom make cheap offers. Instead they make realistic offers. The requests usually contain only a partial set of requirements needed for a fully working system. Functional requirements are forgotten. Crucial user groups are totally missing from the requirements, because the top management has described only the new killer features. Nobody has thought about the non-functional requirements.
You can’t handle the truth!
– Jack Nicholson (A Few Good Men)
Therefore, a quality software house adds plenty of buffer into the fixed offer to cover all the unknowns. This sounds like a reasonable approach. However, nobody knows how this model would work, because the realistic offer never wins.

Picture: An honest man never wins

3.  Sell Agile

Mobile, agile, hostile!
– Denzel Washington (Remember the Titans)
The agile mindset assumes that nobody understands requirements up front, so the project is split into short sprints. During the sprints developers work in tight co-operation with customer representatives. Each sprint ends with a working demo. Methods of high maturity are followed; everything is documented and tested. Mostly automated. The cost and output of each sprint are transparent for all the parties. The velocity is transparent for everyone. If a sprint doesn’t demonstrate the new features, velocity is 0. No excuses. The sprint is the heart rate of the project. The customer can stop the project at any moment. The customer can transfer the work to another subcontractor at any moment.

Picture: Agile is transparent
The advantages of an agile mindset can be exploited even while buying a fixed project. The offer can be divided into a prioritized list of must have, should have, could have features. The few first sprints will foretell the velocity, which helps to fine tune priorities. Transparent communication regarding priorities and velocity is crucial.

Everything Starts with The Procurement Process

The bidding process defines project success. The process determines whether the buyer buys the right things. The process must not bind such variables that will derail the project later. The process must consider variables vital for project success. Not a single person obtains all the needed knowledge for a successful purchase. Success always requires co-operation. Co-operation inside the target organization and co-operation with subcontractor candidates.

Summary

Aim of the text was to encourage the agile mindset. The best way to reach a successful software project is to spar the project objectives openly with subcontractor candidates. Transparent communication increases knowledge of all the parties regarding objectives, needs and implementation options. The fastest way to sink a project is to start with a shoddy purchase process. The easiest way to make a quality purchase is to use an external consultant to run the process. Someone who has a long track record of successful project purchases. The external consultant has the guts to challenge both buyer and seller. Both on mindset and content.
Finally, numerous saved software projects exist. Projects where the work has been bravely transferred to another contractor at the event of deadline. Transparent and fact based agile decision making is the corner stone of modern management.