10 Ways to Avoid Screwing Everything Up

Information technology has been a part of our lives for almost four decades. While we’ve seen dramatic decreases in cost and increases in capabilities, we are still faced with fragmented architectures, failed investments and consistently delayed projects. What have we learned from our successes and what have we learned from our mistakes? How can your organization better structure its processes for developing and updating information technology strategy?

Those who do not learn from history are destined to repeat it, said George Santayana, many years before the development of technology strategy. With that in mind, here are some of the most common mistakes that wise CIOs and IT managers can learn from:

Mistake 1: Identifying new technology and trying to develop ways to apply it to your organization – Experience shows us that projects succeed or fail based on their alignment with business requirements. Many times organizations have tried to “back-end” technology plans by attempting to match them with elusive prospective business gains. Hardware and software vendors are notorious in their encouragement of this. While technology often presents opportunities for altering business capabilities, linkages must be carefully analyzed and pilot business metrics defined.

Mistake 2: Assuming that project costs include hardware and/or software only – Many projects run over budget as a result of incomplete estimation. Ensure that any proposed project includes all the costs through project implementation and maintenance, including those that are both direct and indirect. Estimates of project cost range from 7-10 times the cost of the software or hardware alone.

Typical project costs often include supporting system and application software and hardware as well as training. Don’t forget software maintenance (frequently 15 % of product cost) as well as the human costs of implementing new programs. A frequently forgotten cost is the loss of productivity during the learning curve of system implementation.

Mistake 3: Considering only the technological implications of proposed initiatives – The IT implementation landscape is littered with failed projects that underestimated the impact of technology projects on organizational processes, metrics, reporting structures, customer perceptions and employee morale. Technology is best considered as a component of the strategic triumvirate of process and culture. Attempting to implement a new technology without considering the implications to supporting mechanisms often dooms an initiative to failure.

Mistake 4: Not identifying and implementing risk mitigation scenarios -New projects, like new relationships, often begin with rosy scenarios only minimally infused with cognizance of potential risks. While this enthusiasm can help drive the momentum of project success, it often does not prepare the organization for the risks likely to be encountered along a project route.

A good project implementation plan should try to identify the risks to project success; making sure to include non-technical risks such as vendor viability, process target resistance, and potential changes to organizational strategic variables such as competitive pressures and reduction of resources.

Mistake 5: Not learning from (and continuing to fund) poorly performing projects – Many organizations have two kinds of metrics: stringent metrics about project outcome expectations that precede project funding and project efficiency metrics that commence after project funding. Without active efforts to compare expected to actual business results, the organization’s project selection process remains stagnant.

Almost all project selection methodologies can benefit from post-project audits that improve future selection efforts by actively incorporating lessons learned. This helps the organization prune efficient but not effective projects as it improves future project selections. It’s crucial that this effort be managed in a fault-free environment. Blame-gaming discourages frank assessments and attributions of project success.

Mistake 6: Inadequate communication with business staff – Technicians often have a limited view of communication targets to include only other technicians and organizational management. It’s often necessary to appeal to a wider audience in order to build support (and minimize resistance) for the new project. Often forgotten constituencies include functional management, functional staff and indirectly impacted staff.

Business-directed communication should include the expected business results of the project, impact matrices including schedule of expected changes for all relevant stakeholders, and summary project status. Communications should be targeted for each stakeholder class with technical jargon kept to a minimum for all but technical audiences.

Mistake 7: Failing to integrate new systems, processes and technologies with existing investments – Print off a comprehensive systems and software list from any fairly large organization and you will see a hodge-podge of architectures, languages, databases and telecommunication protocols. This is most likely the result of development efforts undertaken at different points in time when different generations of technologies were available.

While it is impossible to perfectly anticipate the future, a modular architecture that provides flexible integration of these systems together with an adaptable growth path for future technologies is crucial. This architecture should be updated on a regular basis as new architectural tools and technologies become available.

Mistake 8: Inadequate documentation and knowledge management – There are often two kinds of project documentation: business focused pre-funding documentation and technically focused post funding documentation.

Technology strategy would be improved by reworking both types.

Project nomination documentation should include measurable business metrics that can be audited and updated based upon results. Post-funding documentation should include detailed records of all changes to processes, related applications, and databases so that those people not actively involved in the project are able to easily track the sources of failures that may occur long after project implementation is complete. Technology strategy knowledge often leaves an organization in the head (or the files) of the person in charge of a specific project selection or implementation.