How to Avoid Common Problems in Software Contracting

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?

Tags: , , , , , , , , , ,

Hi, I’m Dylan Cornelius.
I was passed over for promotions four times in three years, every time passed over by a peer. My marriage was a wreck. I was obese and my doctor threatened to medicate me if I didn’t lose weight.
When I calculated the per-hour value of my overtime at work, the additional money in my bonus didn’t justify the costs to my health, relationships, and personal satisfaction.
After five years of hearing me complain, my brother told me to stop complaining or do something about it. I was stunned that it had been so long.
After a long and expensive search, I realized the quality of my relationships was poor and I wasn’t taking care of other people or myself.
When I committed to creating fantastic relationships and high-performing teams in every area of my life that mattered, my life transformed.
I was promoted. Now I’m picked to lead teams and frequently thanked for my contribution.
While my marriage didn’t survive, I met an amazing woman who trained me for my first two marathons, and now I do triathlons for fun. I lost 50 pounds and controlled my diet, allergies, and autoimmunity.
Now my “Honey Bunny” and I tour for weeks at a time on a tandem bike. Soon, we’ll cross countries and continents.
I created a Team Acceleration Blueprint based on my personal development journey and decades of education and experience building and leading teams at some of the best universities and companies on the planet.
I believe the world can work for everyone. It starts with clarity of purpose, fantastic relationships, and high-performing teams. I intend to help 10,000 people create an unfair advantage and achieve results they didn’t believe were possible too.

This site uses Akismet to reduce spam. Learn how your comment data is processed.