What if every OSS project was a stretch goal?

What if the objectives of every large OSS project were actually perceived as a stretch goal by internal and external stakeholders of the project?

Sim Sitkin, et al describe a stretch goal as, “We’re not talking about merely challenging goals. We’re talking about management moon shots—goals that appear unattainable given current practices, skills, and knowledge.”

Dymphna Boholt describes it thus:
“The reality is that if everything lands in a project – if every element does what it needs to do when it was supposed to do it, and everything went off without a hitch, that’s actually a stunning success. It’s also incredibly rare.

But we set that impossibly high standard as our benchmark, and then think that everything short of that is a failure.

And in that way, the grading scale should almost be reversed, so that if you put them side by side, it’d look like:

Success = Stunning Success
Partial failure = Total Success
Total Failure = Success
Miserable Failure = Useful learning experience
Total Trainwreck = Failure.”

You know, I’d never, ever looked at OSS projects from this perspective before. I’d always taken the view that if a project I’d worked on didn’t deliver on all expectations (the triple constraint of cost, time, scope/functionality), then it had failed to meet expectations, no matter how big the achievements of the project team may have been.

Dymphna has a really interesting point though. The chances of everything going to plan on a large, complex OSS project are almost zero. There are always challenges to overcome, no matter how skillful the team, how great the planning. It’s why I call it the OctopOSS (just when you think you have all the tentacles tied down, another comes and whacks you on the back of the head).

What if we instead treated the definition of “success” on our OSS projects as an implausibly unlikely stretch goal, to act as a guiding vision for our team? What if we also re-set the expectation benchmark of stakeholders to Dymphna’s right-hand column, not their incumbent expectation at the left?

Would that be letting ourselves off the hook for “failing,” for not meeting our promises, for under-delivering? Or is it fair to resign ourselves to reality rather than delusional benchmarks? Is Dymphna’s right-hand scale effectively like passing an exam only because the bell-curve is used and your classmates have overwhelmingly scored even lower than you?

I’m asking myself, why is it that some of the projects I’m most proud of (of the achievements of my colleagues and I) are also perhaps the biggest failures (on time, cost, scope or customer usability)?

Are you as challenged by Dymphna’s perspective as I am? I’d love to hear your thoughts.