Project Manager's Dilemma: To Share or Not To Share?

There are essentially two approaches to sharing the software you've developed with stakeholders. You've got the Masterpiece method and you've got the Chicago method.

With the Masterpiece approach, you sit your stakeholders down and show them, well, your masterpiece. That is, you essentially wait until the software is completed and then wow them with the finished product.

The Chicago approach, so named because the dubious political phrase Vote Early and Vote Often, involves sharing every phase of the software with your stakeholder. From the very first blank screen with the name of the software in the title, to the finished product, you share it all.

The Masterpiece method is tempting for a number of reasons. First, which programmer or project manager doesn't live for the day when they can wow their bosses or the board of directors? Secondly, over-sharing leaves room for lots of questions ("why doesn't this button work? How come search doesn't find X? and so on), which increases project overhead and may damage expectations. And finally, showing each phase of the project is practically inviting scope-creep.

In my experience practicing the Chicago method, those possibilities for conflict are typically critical advantages. All those questions are really an opportunity to bring stakeholders on board and give them ownership in the project. And scope-creep? More often then not, the changes are important course corrections. Sure, they may deviate from the original plan, but they often make for a much better product.

Finally, the Chicago method counteracts the biggest issue with the Masterpiece approach: the possibility of catastrophic disappointment. What happens when you've worked for months on a product and finally sit the stake holders down, only to have them walk away unimpressed, disappointed, or flat out angry? At a minimum, the stakeholders are going to provide feed. Like, say, "excellent start, now just re-arrange the order process so it's 4 steps instead of 16," From a project management perspective, you've walked into this meeting assuming you're wrapping things up, but you leave with hours of re-work and re-testing ahead of you.

In many respects, it's this catastrophic disappointment we're seeing right now with healthcare.gov. One report I'm hard pressed to believe suggests that 20% of the 500 million lines of code need to be rewritten. I don't know how you arrive at that sort of estimate. But I know that if you're over-sharing with the right folks, then you're a lot less likely to get into such a broken state in the first place.

I've also seen attempts by folks to try a middle-of-the-road approach. They want to wait until the software is at some milestone, and then start sharing it. Like the Masterpiece method, I think you're setting yourself up for failure. All you're doing is raising expectations to a place that's often had to meet.

Bottom line: when it comes to software, Share Early and Share Often.