Contracting for new product development is risky business.

There I was at my customer’s desk while he ran late from a meeting. It was my first time there. Tacked to his cubicle wall was a letter from his company’s legal department to mine. It declared a breach of contract. It demanded remedies, including assignment of a full-time professional project manager.

What A Way To Get A Promotion!

As I onboarded to that project, I learned that my company had acquired a company. The acquired company had contracted to deliver a custom software product to our customer. After a year, we still hadn’t delivered that product. Nor had either party begun the work to integrate the product into the customer’s technology ecosystem. B

Both technology teams were in a corporate game of ‘chicken’ to see who would do their part of the integration first. The customer’s CIO wasn’t authorizing the work on his side because they had no clear, compelling evidence it was a good use of resources — and they had many other priorities that demanded immediate attention.

Soon, I found that the product was nowhere near completion. This is why our team hadn’t bothered to begin their part of the integration work. It seems the founders of that small company were better at sales than software delivery. Seeing my company’s lack of definitive progress, our customer had been wise not to invest further.

The Real Loser Was The Customer.

Ultimately, the product wasn’t delivered, installed, or commercialized. At least two people lost their jobs. Business plans weren’t executed successfully. Investments and opportunities were lost.

Despite — or because of — this experience and others like it, I’ve concluded the leaders involved in arranging these types of situations are usually doing the right thing. They’re well-trained, have decades of experience, hundreds of employees, and millions of dollars in financial authority:

• This project was clearly not business critical,
• The value of resources deployed was not material, and
• The perceived ROI was too low to invest further, relative to other commitments.

At the same time, my company had prevented competitors from acquiring the acquired business and product. We had created the impression we were entering that market space, and we’d prevented a competitor from selling a competing solution to that customer. This got our company noticed, and ultimately acquired. The CEO, investors, and unvested 401k accounts all received windfalls.

New Product Development Doesn’t Have To Be So Hard.

Unfortunately, this kind of situation is the result of common problems in new product development. These stories have been in the news since the 1970s.

Even assuming this product development initiative was little more than a lottery ticket to all parties, delivery of any of the following would have required very little additional cost (or even just a reallocation of existing resources). Each would have improved probability of project and product success:

1. Detailed functional requirements in the form of user stories
2. Detailed user acceptance criteria
3. Frequent demonstrations of software functionality — weekly, no less frequent than monthly 
4. Pay only for progress against explicit functional milestones

Of course, given the resources at stake (in the larger context) and the failure to manage for success, it’s possible to make the case that neither party actually wanted this situation to succeed.

Don’t Be A Loser Too.

When you contract for a custom solution, ask for and implement project and business controls to make sure your lottery ticket pays. Too often, companies rely on outside technology experts, then exercise poor vendor due diligence, poor contracting practices, and poor project oversight. They transfer execution risk to a party that is not very good at execution, then fail to actively manage the relationship or the initiative. This is like hiring a junior employee, then failing to supervise them. You wouldn’t do that, would you? Your company wouldn’t let you do that, would it?