Like most organizations out there, Westminster College relies pretty heavily on software from Microsoft to run our operations.  Unlike some organizations, however, we generally look forward to Microsoft’s new wares and we evaluate and deploy a lot of the company’s products relatively early on.  From a cost perspective, we generally look at the Microsoft option before looking at others; with the Microsoft Campus Agreement that we have in place, licensing costs for Microsoft products are quite attractive and our very MS-centric infrastructure makes integrating new services pretty easy.

When Microsoft releases something new, we, at the very least, give the product a look to see if it will meet a need or enhance a process.  Twice in the past couple of years, I’ve gotten the distinct impression that, for some of its products, Microsoft might intentionally hobble “version 1” of the new product.  I’ll use two examples in this column, but there could be others.  There are some lessons to be learned from the Microsoft approach.

In particular, let’s look at the original release of Exchange 2007 and the original release of Office Communications Server 2007, both products that Westminster either considered or deployed very early in the product lifecycle.  While both products were upgrades from existing Microsoft products, both were also revolutionary upgrades in a number of different ways. For example, Exchange 2007 turned the Exchange paradigm upside down with a major architectural overhaul and OCS 2007 was Microsoft’s first significant foray territory formerly under the firm control of the PBX.

In both products, there were missing features that were key to many serious deployments.  Let’s look at Exchange 2007 RTM, which was missing a GUI-based method for managing public folders.  Although this could have been a simple architectural decision based on the fact that Exchange 2007’s internal reliance on public folders is gone, the conspiracy theorist side of me thinks that Microsoft made the intentional decision to exclude complete public folder support from Exchange 2007 RTM.  Why would the company do this?  Personally, since Exchange 2007 was such a major departure from Exchange 2003, I think the company wanted to control the release a bit.  By excluding reasonable public folder support, Exchange 2003-based organizations would think twice about deploying Exchange 2007 RTM and might wait for SP1, at which point Microsoft would have a much better understanding of customer support needs and scenarios and be able to better react to issues.  In short, by eliminating what many organizations considered a “must-have” feature from the initial release, Microsoft could still have a successful product on their hands, but with deployment happening in a more phased approach.  Of course, there were ways to work around the lack of real public folder support, but may organizations would rather wait for “official” support.  Another way to look at it: Obviously, most organizations don’t deploy release candidate software into production, opting instead to wait for the RTM.  Maybe the Exchange 2007 initial release was a way for Microsoft to extend the real-world testing cycle while at the same time giving early adopters the comfort that they were deploying production quality software.

It’s important to note that Microsoft went out of their way to say that the RTM release of Office Communications Server 2007 was not an attempt to displace the PBX, but rather to supplement it.  It’s a good thing, too, because OCS 2007 RTM was missing so many critical features that it could really only reasonably be used as a supplement.  Of course, with the release of OCS 2007 R2, many PBX-centric features have made their way into the product and it’s conceivable now that an organization could possibly rip out their PBX and replace it with OCS.  Again, if Microsoft has built the original OCS 2007 in the way that the current R2 is built, it’s more likely that initial OCS uptake would have been a lot higher (not that it was really bad anyway).  Further, if Microsoft had included such features as E911 location information, hunt groups, and traditional conference calling, Microsoft may have had a lot more trouble finding those initial OCS partners.  Again, some of these features, such as hunt groups, are so basic that not including them in the product release was a real head scratcher, so my theory is that the company made the intentional decision to hobble the product as a strategy to release the product while still being able to work on direction and support structure.

So what does this have to do with you?  When you think about it, what Microsoft has done, if these decisions were truly intentional, was to control the release of new products in a way that made them supportable, helped to refine future direction and avoided alienating partners.  This intentionally phased approach can make sense in a lot of IT projects, too, and is really a pretty common project development model in which projects are broken down into phases, but with working, usable deliverables at the end of each phase.  By breaking projects down like this, IT can deliver to customers the most critical aspects of a project while still being able to commit to other organizational priorities.  Rather than being tied down to a single project from start to finish, IT is tied down from start to finish of a single phase after which priorities can once again be assessed to determine if the next project should be Phase 2 or something else altogether.  Further, by deploying projects in this phased approach, the IT developer can then analyze user usage patterns and support requests to inform future development.  For example, if users are constantly calling the help desk about a particular item in a project, perhaps that item can be addressed in phase 2.  Of course, the difference between Microsoft’s approach and an internal IT approach would be the fact that your own development team would not be likely to omit a key feature, but every organization has its own ways to do things.

What do you think?  Does Microsoft intentionally omit key features?  Does your organization use a phased approach to project completion or do you opt to do one large project from start to finish?