The same tech contractors win over and over. And we’re shocked, shocked, when the outcomes repeat. How to avoid this trap.

There’s 1800 pages of legalese in many large system Federal IT procurement contracts. So it’s no wonder the largest and best known IT contractors win the heftiest  Federal and Fortune 10 contracts because they better understand the procurement process and have the staff overhead to run the gauntlet of writing the RFP for the purchaser, replying to the RFP they wrote, and then jumping through the Procurement hoops to secure the deal.  They’re experts at playing the game, getting additional funds as needed, adept at covering themselves and becoming part of the background.  Same in the private sector since usually it’s the same companies who know how to fit into larger organizations and not rock the boat.

OK, you’re the Business leader on the Project Steering Committee, responsible for an expensive and visible project, such as an ERP, a Mobile Payments app, or a Policy Admin replacement initiative being delivered on time, on budget and fulfilling the underlying investment business case. Now, the technical rep to the Steering Committee, who can be internal or from the contractor, has just launched their PowerPoint showing all the reasons why they will be delivering extremely late, very much over budget, and with reduced scope for Release 1.0.  What do you do now? You ask questions, such as “how did we get here”, and “what do I need to get you to move this back on track”.  The technical rep has two options:

  1. Use the KGB interrogation survival strategy – shrug their shoulders and claim they have no idea how we got here, but they’ll get back with a plan for the next meeting
  2. Launch into a well-rehearsed pitch for more time, more money, more staff, and even more scope reduction for Release 1.0.

You, in turn, have 3 possible responses:

  1. You wait for their plan to be presented at the next Steering Committee and during that inter-meeting period, you start paying increased attention to your LinkedIn relationships
  2. You stop the project; declare victory and move on to something that might actually work out.
  3. You immediately convene, to borrow a technique from Medicine, a Morbidity Mortality Board. Yes, we use that name because it has all the right gravitas.  When we hold such a Board, people understand the project is in critical condition, and we’re trying to figure out why so it does not reoccur or the project will be shut down.

In our experience, only Option #3 will create a positive result, justifying the spend to date and furthering the business goals.

This Morbidity Mortality Board, adapted to IT/Business, determines why any delays or missed milestone is occurring, and it is a formal meeting with written inputs, not a finger pointing session and has a single individual or team assigned to fix the issue. Overall, there are 5 serious investigative paths:

  1. Did a poor judgment call assume the impossible could not happen here – what else is being assumed as an outlier situation or is impossible?  Did someone miss clues or early warnings?  Do all the team members have good judgement or will they just nod their heads?
  2. Is the root-cause a systemic or methodology flaw necessitating improvement before restarting? Use the 4 P’s: People, Place, Policy and Process. The key is not to attack symptoms but to fix the root-causes. This is especially true about key contributors and leaders.  Are they burned out, talking vaguely about how “no one understands what we’re trying to do”, or “we keep trying but we can’t make the users happy”?  These may be indicative of key people being punchy, and it’s best to replace them ASAP.
  3. Poor execution led to higher errors, unstable code, understaffing or requests to redefine scope (usually this means ‘reduce’)
  4. A hand-off either did not occur on time or the hand-off was insufficient, had unexpected elements or was not tested and did not fully function as required
  5. Specify the threshold to shut down the project. What is the last straw, or straws, which can be measured or demonstrated and which would lead to ‘stop the madness’.  This doesn’t have to be an egregious example-we had a situation where an EVP of a stalled, over budget, reduced scope project hit that mark upon seeing he was being charged back for a developer’s Big Mac on a Sunday night (i.e., the contractor was not making even a $6 investment in the project).

How to avoid ever getting to this disaster stage?  Ask tough questions before kickoff:

  1. What will this new system look like in the final-successful state, as described by the Business?  This becomes the guiding document by which all decisions will be based.
  2. What is the minimum set of Business functions we need to deliver to achieve the most important (not the easiest) business goals, and a satisfactory Customer Experience? How do we enhance this baseline release until we have a complete system?
  3. Is the contractor the best fit or the vendor who wrote the RFP in such a way they became the best fit?
  4. Is the winning contractor’s team as deeply experienced in their responsibilities as the Business is on their side? Will they do a bait and switch?
  5. Is this vendor the ‘default’ or ‘preferred’ vendor based primarily on a heavily discounted Rate Card? If they staff at the lowest rates, can they make money?
  6. How are we ensuring quality and avoiding last minute delays due to slightly incompatible code made by different developers or contractors?
  7. Do we have a robust test environment set up; is a comprehensive set of test cases defined, representing the system’s true real-world use (see #1, above)? Hint: if they say they’re performing Continuous Integration and do not have a robust test environment built, pull the cord and stop the assembly line until they have it up and functional.
  8. How is the project organized and timed? If multiple parties are involved, who is one person responsible for signing–off on, and then enforcing, a single set of coding conventions and the end to end solution architecture?  This also applies to comments and code documentation standards and reviews. As for time, what is the exact date needed for go-live? All planning reverse solves to this date.
  9. Has the contractor staffed the project with employees having standalone levels of hands-on experience? It’s not your issue to help a contractor empty their bench of newbies.
  10. Who are the highest managers from the supplier and IT and the Business, all of whom will be involved on a daily basis, and what is their empowerment? On the contractor side, ensure the representative is a technical resource, not an Account Manager/Business Development person.
  11. What is the threshold in terms of time and money when 1 – it’s time to swap out the vendor/contractor or 2 – shut down the project? Clearly state the criteria to all participants, so they know, upfront, failure is not an option, and this is not an exercise in perpetual billing.

Large and complex systems, especially those with multiple data feeds and integration touch points, are hard to design and then develop successfully even under the best of circumstances.  Having a weekly or monthly meeting and then assuming all will fall into place between meetings is as unhealthy as pretending if you don’t ask, it must be Ok.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC, , focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at, and followed on Twitter, @RDEgrowroe