The moment it becomes an IT project...

...you're dead in the water.  Steve Laster, Harvard Business School's CIO, put forward this aphorism at Campus Technology 2010 while describing a major project to investigate, design and implement an online collaboration environment at the Harvard Business School.  The statement resonated with me and speaks to the maturity of the IT culture at HBS. 

Many IT organizations (and I'm not limiting myself to the education sector) would have eagerly jumped into the project.  A short time later, the latest and coolest Web 2.0, social media integrated toolset would have been installed.  And henceforth ignored.  I attended another session at CT 2010 where the IT director described the new ePortfolio system they (i.e. IT) had researched and implemented.  It had all kinds of great features that students and faculty could use.  After the first semester exactly 0 (zero) students and faculty had signed up.  The IT director chalked it up to a lesson learned regarding communication.  Certainly communication and change management would have helped but I'd bet their results would not have been significantly better if all they changed was communication.

HBS approached the challenge of online collaboration quite differently.  Right from inception, they treated the notion as a business question rather than an IT problem.  Instead of jumping right in to a juicy "IT project" or allowing the school to "just let IT solve this problem" Laster pulled together a small group of key stakeholders from different departments of the business (yes, I say "business" rather than "school" although it grates on some faculty).  While the HBS Collaboration group included an IT representative it was comprised of and even lead by representatives of other business units.  It was that team's conclusion that an online collaboration tool was indeed needed.  Furthermore, they worked together to develop requirements and explore options. 

This approach had a number of immediate benefits.  The technology choice had immediate buy-in due to the inclusive method of its selection.  The business units had at least one, and often more than one, knowledgeable member on their team which helped in communication, change management, and rapid adoption.  These knowledgeable members were trained as expert trainers which distributed education and support responsibilities.  The team of experts continued to meet during and after implementation.

Would it surprise anyone that HBS is a Scrum shop?  Those with a background in agile software development methodologies no doubt see the HBS arrangement as perfectly normal.  The cross-functional working group was, in essence, a product owner / customer proxy.  Wouldn't it be great of more IT organizations thought of their projects and potential projects as being owned by the business rather than by IT?