I’ve been hearing a lot lately about keys to successful IT project implementation. Opinions about what makes a project successful vary greatly. Some of the more common strategies for success include:
- Implementing leading-edge technology,
- Implementing tried and true technology,
- Relying on outside experts to help implement whatever technology is selected,
- Relying on in-house personnel to implement whatever technology is selected, and
- Preparing for implementation by clearly and completely defining the project scope.
There is no doubt that any one, or a combination of several of these strategies will certainly improve the odds of successful project implementation. When you read the article on page 34 in this issue titled, “Older and Wiser-SAP’s Customer Care and Service Solution Gets Better with Time,” you’ll see that being one of the first to implement leading-edge technology can have its drawbacks. The article shows that experience and customer feedback have not only improved CCS’s implementation process, but they have also prompted SAP to improve the product to better meet its utility customers’ needs. So, at least in this case, there is definitely some advantage for those utilities that chose not to be the first implementers.
Similar arguments favoring each of the other strategies can be made. Of course, arguments that are not so favorable can also be made. One strategy that I don’t favor strongly is preparing for implementation by clearly and completely defining the project scope. It is true that implementation will most likely go much smoother if all goals and objectives are defined upfront, all implementation procedures are developed based on these well-defined goals and objectives, and, once implementation begins, no changes in these goals and objectives are allowed. However, such a strategy is impractical, if not impossible.
When one considers the pace at which technology is changing, not to mention the uncertainty most utilities in this country are facing, it is foolish to try to define a project and expect the technology and process requirements to remain stagnant for months, or even years. Things are going to change, maybe even dramatically, before project implementation is complete. Unfortunately, this inevitable fact is often ignored during the planning stage, and, once implementation begins and changes are necessary, management often views the project as suspect. If scope and process changes result in a project that is over budget and/or behind scheduled, management almost always labels the project as a failure. So, I’m adding another strategy to the list-preparing for implementation by understanding the project scope is going to change.
While it is important and necessary to narrow down a project’s scope and its goals, it is equally important to make sure that allowances are made to reflect the project’s dynamic aspects and the fact that it is being managed by people. Needs will change, technology will change, and more than likely people will come and go throughout the project. Any utility that enters into an IT project locked into a set of rigid goals and objectives is likely to find itself in the midst of a failure.