Follow the Leader
Who should be leading your project: business or IT?
When a well intentioned project has failed or hit a few bumps in the road, one of the oft-cited reasons for the failure is leadership. There are thousands of books on leadership and what makes great or poor leaders, all penned by someone smarter than I, so rather than investigate what kind of leader should be captaining your ship, let's investigate which internal organization should be leading your projects.
There is clearly a good case to be made that many projects should be led by your company's IT organization. Things like software upgrades, enhancements or optimizations to existing IT systems and the like are generally deferred to the IT department without a second thought. Much as switching your firm's accountants from Number 2 to Number 3 pencils should not require much input from the larger organization, there are a percentage of projects that can and should remain completely within the IT organization of most companies.
Where many organizations make a mistake is in assuming that anything involving IT should be managed by corporate IT. A perfect example is Enterprise Resources Planning or Customer Relationship Management applications. A company writes a large check to a software company to purchase these applications, and therefore assumes they have bought a piece of software that should be managed and installed by IT. This assumption is nearly always wrong, and often fatal.
Package software really is not just software. As the vendor's sales people are quick to mention, processes and purported "best practices" are a key component of any package. In addition, most packages offer quite a bit of leeway for individual customizations to the delivered business processes. Although your IT department is certainly capable of installing Excel, you would not have them design the chart of accounts to be used with Excel, nor should IT be solely responsible for implementing package software and redesigning business processes and procedures.
Too many organizations involve business decision makers and end users of the product late in the process, assuming a cursory "requirements gathering" session and some involvement later in testing will be an appropriate way to complete the implementation. However the opposite approach will result in vastly improved results. The business users affected by the implementation should drive any project involving changes to existing processes or additions of new ones from the beginning, only involving IT when there are specific IT-related tasks to be completed, such as developing enhancements or building a hardware environment.
When building a house it would be foolhardy to bring a group of expert contractors on site on the first day, and begin experimenting with different plumbing schemes or drywall placements before any semblance of a blueprint has been completed. Rather architects and general contractors plan and drive the work of the builders only when the systems of the house have been designed and planned appropriately. In a systems implementation, business users and key stakeholders should run and actively manage the project, rather than deferring those efforts to an IT organization.
Leaving the shop to the IT folks often creates a battle weeks or even days before go-live, as business users suddenly realize the new system that has been implemented does not fully meet their needs, or key requirements may have been overlooked. All too often an IT-managed project will deliver a technically sound solution that misses many central business and strategic requirements. Only through the painful process of involving key resources and subject matter experts in the project from the beginning, and maintaining their involvement will the end result accurately reflect what the larger business community expects and requires.