Imagine you are setting off on a long journey. In charting your course, you’re off by one degree. In the short term, the difference will be minimal: traveling 100 yards, you’ll miss your destination by about 5 feet.

But the one-degree error compounds from there. If you are going across the country, you’ll be 40+ miles off. If you are headed to the moon, you’ll be 4000+ miles off. If you are headed to the sun, you’ll be off by 1.6 million miles.

Collaborative partnerships — those relationships with vendors, partner organizations, suppliers, and so on that permeate our work lives — operate the same way. Fractional differences in how they’re set up can be overcome relatively easily, as long as the scope of the endeavor is small. But if you’re shooting for the moon, you’ll wind up somewhere else.

The most pivotal moments can happen right as they begin.

Many partnerships are in those early stages now. Companies are quickly teaming up with other companies to help them change. Somewhere, people are getting together on Zoom to start the next Zoom. Some of these are marriages of convenience and will have trouble down the road. Others will stand the test of time. What’s the difference?

Space graphic with a hand holding a mouse. It reads "Experienced teams. More impact. Less boring. Let's talk." in white text.

What works

In 2019, a team of experts looked at this question from a governmental perspective, resulting in the wonderfully informative guide called “De-risking custom technology projects,” which we’ve name-checked in a previous newsletter.

I found a couple of their recommendations widely applicable to all:

  • Plan for change: “The RFP should … acknowledge there will be constant change to the work based on shifting priorities and ongoing user research; change is expected.”
  • Use a statement of objectives: “The RFP should use a Statement of Objectives rather than a Statement of Work — that is, it should state the objectives of the project, rather than the specifics of a product that the vendor should produce.”


There were so many interesting tidbits in their findings, but what stuck with me was the importance of forgoing the impulse to define every aspect of the project before the partnership begins.

While we are hoping to protect the project from risk, we’re also protecting it from opportunity — new ways we can work together to make the thing better, faster, and more impactful.

After all, only 13% of large government software projects are successful. Which leads us to the next section.

Simple, illustrated graphic of business partners sitting at a table and talking. The main colors are Blue, Red, and Orange. There is a plant illustration at the bottom of the graphic.

Why partnerships fail

In a poll of executives about the risks of strategic partnerships, three reasons for failure rose above all others: lack of alignment on core objectives; lack of internal trust; and partners’ inability to identify and quickly make the changes needed for the relationship to succeed.

The most successful partnerships, then, begin by embracing what they know at the outset, and just as importantly, acknowledging what they don’t.

What we can do about it

What we know at the outset of a partnership is often simple:

  • We want to do something great together
  • We have a vision for it
  • We know it’s going to require nimbleness, unforeseen changes, and grind to get there
  • We’re looking for somebody we believe in, who agrees on the vision, and who is willing to embrace the challenge of doing this with us


What we don’t know is also simple: 

  • Almost everything else

By acknowledging the scale of that challenge, we also acknowledge the opportunity. “This might get tricky. And we’re looking for somebody we trust enough to do that kind of work with.”

We should vet our partners, to be sure — but the focus should be on the most core principles. By making that one-degree change in how our partnership is structured, we’re more likely to be headed to our destination.

Clique Denver CLIQUE UNIVERSITY • CLIQUE UNIVERSITY •
  • Derek Nelson

  • 4 min read

  • Derek Nelson

  • 4 min read