Developing a Technology Strategy

By Mike Scheuerman

(Back to article)

Developing a technology strategy is not about figuring out what servers or networks to put into place, but rather putting in to place a framework within which a set of business applications can be deployed.


There are three things that you need to know when developing a technology strategy for your company:


       An in-depth understanding of the business strategies the company is pursuing;

       A vision of how technology will add value to business processes; and

       Technology use principles.


Business Strategy


Understanding and being conversant with the business strategy is critical to technology strategy development. Building a technology strategy without understanding the business strategy is like building a dam in a dry gully and hoping it will rain. You might get a lake, but more likely you’ll get a muddy pond.


IT is a large part of the engine that implements and reports on the success (or failure) of the business strategy.


Business Value


For each business process that uses technology (which nowadays is virtually all of them), there has to be some value that IT brings to the table. Whether it’s a more efficient process or a competitive advantage, the value must be defined by the user or business unit. IT is merely the tool that is used to achieve that value.


Business analysts and system analysts can help the business technology user analyze the process and can suggest ways that technology can be used to improve processes. However, those analysts are not there everyday trying to get a job done. The partnership between IT and the business user is crucial to building a solution to a business problem that is both workable and maintainable.


Technology Use Principles


When you’re defining the technology strategy, establishing a set of principles to measure any technology against makes decision making a bit easier. For example, if you want to ensure data consistency, the principle is that there will be a single source of data. You might call this the “enter once, use everywhere” principle. That bumper-sticker slogan is easy to remember. That is what you want if you don’t want to continuously explain why a particular decision was made.


This set of principles should be short and easily understood by both technical and non-technical users. The principles should be focused on reliability, consistency, and maintainability. Given a good set of principles, the decisions that are made by project sponsors, project managers, developers, and end users will almost always align with the general technology strategy.


Some principles that you might want to use are listed below.


Reliability - Measure twice, cut once. This maxim used in the building trades applies just as well to IT projects. Always double check to make sure that what you’re building is what the user wants and needs. Good planning will drastically reduce the number of changes near the end of a project where it gets very expensive to make changes.


Consistency - Enter once, use everywhere. This is a bit like normalizing a database. You only put the data in one place and then reference that as the “system of record.” This principle ensures that reports and information delivered are consistent across the entire organization.

Maintainability - Keep it simple. This principle is one of the hardest to implement. IT people are used to complexity and love the puzzles that complexity brings. Complexity breeds errors and requires resources to maintain. Devoting ever increasing amounts of resource to maintaining systems leads to the famous view that IT is a black hole where money disappears and never returns.


This principle also applies to project management. Don’t try to build a system in one giant project, but rather keep the phases of the project down to 60 to 90 day chunks. That allows you to keep the potential misses to a minimum and gives management the opportunity to review the need for the project on a regular basis. It also gives the project team a chance to celebrate every couple of months which is great for morale.


By now you may have noticed that there is no mention of hardware or software in an article on technology strategy development. That’s because the hardware and software are different for every organization. Trying to provide any advice on those topics any would be fruitless. What you need to take away from this article is that technology strategy depends on your organization’s business strategy. The business value provided by the technology is paramount in ensuring the organization uses and likes the technology you provide.


And finally measuring your projects and systems against a set of easily understood principles will make decisions more consistent. Consistency leads to a technology architecture that supports the technology strategy that the business strategy and value has shaped.


Mike Scheuerman is an independent consultant with more than 25 years experience in strategic business planning and implementation. His experience from the computer room to the boardroom provides a broad spectrum view of how technology can be integrated with and contributes significantly to business strategy. Mike can be reached at mike@scheuerman.org.