The train is leaving the station

My career is moving on, beyond the software industry where I have worked for the past 25+ years, but every once in a while I find a tidbit out of that world that catches my interest.  Some are applicable to people in other industries - I think this is one.  Ed Sims on his BeyondVC blog has an interesting post on date-driven vs. content-driven strategies for software release management.  The same dilemma and solutions can apply in many other industries.

Link: BeyondVC: The train is leaving the station.

As Ed explains:

There are a couple of different ways to manage engineering releases. One engineering release is date driven, the other is content driven. In a date driven release, the team knows when the next release is out but does not know exactly what will be in it.  The release runs like a train schedule, whoever makes it to the station on time is part of the release.  The other release is content driven; the team knows what is in the next release, but does not know the exact ship date. The release runs more like an airplane shuttle, it takes off only when full.

Ed has a strong preference for date-driven releases - and I do too.  In my days in the software business, I spent 20 years or so going through the debate over whether to adopt a date-driven or a content-driven strategy roughly every six months or so.  I had the challenge a couple of times of being dropped into grossly behind schedule releases to try and rescue them and get them out the door - every time, it was a content-driven project that had to be rescued.  So give me a date-driven release philosophy every time.  In my last three companies we actually explicitly used the train analogy that Ed refers to.  We used to plan to have the "trains" (a new release) leave the station on a regular interval (six or nine or twelve months, depending on the product).  A feature that missed the cut-off for one train would simply catch a seat on the next train.  But read Ed's post because to make a date-driven model work you have to sync up your product management approach with how you run sales and marketing. 

However, there is another side to the story.

Two of the very large and very, very late content-driven releases that I had to try and get put to bed were what I would call "next generation" releases.  One was of a database management system which included a tightly integrated application development facility.  The old generation had been a world-class environment for building character-based applications (you know, back before GUIs, back in the 80s) and there were literally hundreds (maybe even thousands) of commercially available applications written using this environment.  But, it was the early 90s and guess what - every one of those application developers wanted to to be able to convert their apps to a GUI in the same environment that they already knew cold from having built the character-based version of the app.

So my company, quite some time before I joined it, embarked on a very ambitious effort to create a GUI version of it's development tools: GUI both for the developer's environment and support for building applications with a GUI interface.  That's actually two very large, complex projects that don't have a lot to do with each other.  It necessitated a real big-bang project - creating an almost entirely new code base that allowed existing customer applications to be upward compatible while supporting an entirely new development model, etc.  But what was the alternative? 

In hindsight, there was an alternative to the big bang approach.  But at generational boundaries (e.g. in software when we went from mainframe architectures to client-server, or from client-server to internet, or now as we're going from internet to service-oriented architectures) sometimes it is very difficult to see a way to make the leap without such a big-bang effort.  For those who read Clayton Christensen, that's one of the things that he talks about in the Innovator's Dilemma and Innovator's Solution.  Generational boundaries are at points of disruptive innovation.  Today at least we have a theoretical framework from Christensen to use to analyze these problems.  But that doesn't make the decision any easier.  In hindsight, should we have built a separate GUI product for all the reasons that Christensen talks about?  Would there have been a way to bridge the gap without the big bang?  Probably, but that course is in many ways just as fraught with peril as swallowing hard and stepping up to the Big bang second generation product.  Which (coming back to Ed Sim's post) because it is by definition a content-driven project, and one ususally undertaken without the necessary knowledge to estimate scale, scope, and complexity, will be a project that runs grossly late. 

In any situation other than that of dealing with a disruptive innovation/second generation product trust me, you'll be a lot better off adopting a date-driven approach to release planning and management.  The engineers won't always like it, the sales guys won't always like it, but overall everyone will like it a lot better than the alternative. 

And in the case of disruptive innovation where you have to confront the second generation problem, I can tell you that the big-bang second generation project essentially always fails (the few exceptions only prove the rule).  So what do you do?  There are a couple of options:  a) acquire a disruptive innovator and make their product your second generation, b) dust off your resume and go to work for the disruptive innovator, c) disrupt yourself (see Christensen) with a separate new internally developed product.  For those who are paying attention, options a and c are the same, it's just a question of build vs. buy.  But it you get stuck as the first project manager for a content-driven next generation project, just keep your resume up to date, because someone like me will be coming along to take your job - you've been set up to fail.