Many business writers and thinkers talk about the need for speed - to speed up supply chains, work more closely with the customer, to get ahead of the trends and business cycles. I think speed, like any other attribute of a business, can be a valuable feature or a killer.
However, I do want to point out the need for speed in creating change in an organization, especially process and information systems change. An unfortunate outgrowth of the ERP and CRM implementations of the mid to late 90s has led to what I call kitchen sink thinking when it comes to information technology systems. That is, while we are going to replace system "X", why not also bring system "Y" in and change system "Z"? We've become accustomed to large, unwieldy projects with lots of moving parts.
The problem unfolds in several ways - in time, resources and risk. I was trying to explain to a potential customer the reason our estimates increased more dramatically as the project she suggested lengthened. I have a rule of thumb when it comes to system implementation - time increases incrementally, resources required increase arithmetically and risk increases exponentially. Why? In the long run, everything changes. Given the pace of our businesses and trends in the environment, talking today about what systems we'l implement in eight to ten months from now is fraught with peril, since in that time so much could change. Management teams are more fluid, customer tastes and demands more fickle, Wall Street more interested in mergers and acquisitions than steady growth.
Where possible, we need to administer short, sharp shocks to the day to day process infrastructure. Make process and information system changes, but try to contain the scope and timeframe of the project at all costs. To be frank, some of the biggest challenges to long projects are simply short attention spans. After a while, hearing about the same project makes anyone wonder - when will they get done? Are they STILL working on that? And inevitably, once you've opened the cookie jar of software, some one from senior management will have a bright idea about adding a new set of features that was not planned for initially. You had the code opened up anyway, right?
After a while IT fatigue sets in and there are new and interesting projects and trends which attract people's attention. The longer a project goes, the more likely it is to fail.
OK, so what's my recommendation? Reduce and manage these risks by tightly controlling the scope of a project, and attempting to accomplish as much as possible in as short a time as possible. Delivering many short wins that can be identified as wins - even incremental wins - builds excitement and lets the team know that there is always an end in sight. I think many IT managers will look at this approach with either excitement - since their teams want to work this way, or disappointment - since its harder to build an empire on smaller, shorter projects.
When implementing process or information system changes, slow and steady doesn't necessarily win the race. You have the need for speed.