In approaching any information technology decision, there are a list of common factors that should always be considered. This paper discusses those common factors, their relevance in various situations, and some common methods of applying the results of their consideration. They are not technical issues and this is not a technical paper; the intended audience is decision makers responsible for signing off on information technology expenditures.
Although it should go without saying that business activities should generally support the focus of the business, it apparently isn't said quite often enough. It is not an uncommon feature in many businesses to find heavily supported activities, which, upon analysis, aren't truly supporting the stated objectives of the organization. As many companies realize this and began to trim out their non-core functions to gain efficiency, IT has generally been spared the chopping block. IT is a special case because many IT processes are too complex for the average manager to understand without extra explanation; and that explanation in and of itself is often a poor use of time and resources.
However, it is critical that information systems be constructed and operated in line with overall organizational objectives. The criticality is not because the organization will then be wasting money on a non-essential system (although this also may be true) but rather because a system that is not in line with overall objectives will tend to fall apart or become under-utilized--resulting in not only a wasted investment, but often with drops in productivity as the system bends staff effort away from more essential business processes.
How is this judgement made, when information technology is so difficult to intuitively understand? First, the organization must have coherent objectives. Again, this should go without saying, but many organizations do not, or do not bother to state their objectives succinctly for the benefit of the people handling the technology (who may or may not have a background in that business environment). The importance of putting IT terminology into plain english for owners and executives is widely accepted; not enough importance is placed on translating business terms into plain, practical terms for IT staff and implementers. Rather than using the broad strokes and business jargon which someone with an accounting background might easily understand, it's important for management to state their objectives to the IT group in succinct functional terms. It's not enough to request a project to implement a new contact tracking system, for instance; the request should include an outline of the steps staff will take to gather, input, and process the information, what exact information will be required, and in what quantities. Any organization that is not capable of putting it's needs in such terms should avoid relying on information technology to implement them.
Second, the information system in question must be broken down into real, objective, measurable terms for the decision makers. More input on this element is offered below, under Measurement. Essentially, the information systems functions must be quantified in hard economic and business terms. Sticking with the example from above, management and IT should put specific dollar values on each distinct function of the contact tracking function--collating all contacts into a centralized storage area should save X amount in storage space, reducing duplicate entry of contacts should save X amount of staff time, and so on.
Third, someone has to compare the objective results with the stated objectives and make a decision as to the relevance of the system. This function is often left to whoever may care about it within the IT department... which is to say, no one, in most cases. In others, it may fall to a single department head with responsibility for IT functions, or the CEO who a CIO/CTO may report to. It's not sufficient to simply leave this job to the IT department, however, although they may play a major role in providing or compiling the data to be analyzed--an independent agent should be making the review. Ideally, an IT steering committee composed of both IT staff and other business stakeholders should fill this function.
Not only should no new initiative be launched without going through this brief check process, but existing systems should be regularly evaluated as well. Environments change, and systems may continue to work but cease to support the business objective.
Not all of these situations automatically violate the rule, but they are all good warning signs that call for a second look.
Another factor endemic to IT is mission creep. Again, due to the complexity of information technology and the "wow" factor it incorporates, information systems have a greater than normal tendency to wander away from their original purpose and attempt to take on other jobs, which they may or may not be well-suited for, but which at any rate they have not been adequately measured against.
This is a self-perpetuating issue in many cases. When dealing with external vendors, it will always be in their best interest to extend the penetration of their product or service into the organization, because information systems require on-going maintenance and the more there is to maintain the more money there is to be made. When working with internal IT groups, there is a tendency for them to attempt to provide additional extended services both because it entrenches their department (and job security) and also allows them to broaden their knowledge and extend their expertise (often a motivating factor for technicians).
However, it should be guarded against. Loss of focus is particularly hazardous in information systems, since computers are best at performing limited, repetetive tasks quickly. Extending systems to handle items they were not originally designed to address limits their efficiency and increases their complexity.
Keeping mission creep in check is best accomplished with a good system of tight revision controls, frequent reviews, rapid turn-around, and well-defined objectives.
All of these practices hinge heavily on the last: well-defined, measurable objectives. As emphasized under "Alignment with Organizational Objectives," a coherent description of function has to exist in order to have anything like a scope to adhere to. Not have a solid, quantifiable goal at the outset renders any endeavour subject to interpretation by the implementors, and this leads to mission creep as various workers place their own emphasis on what the effort should accomplish. Setting a specific and measurable goal for them, and re-emphasizing it, reduces the chance of this happening.
It's also necessary for revision control; how else is anyone to know what is a revision and what was the original concept? Having a good system of revision control in place will ensure that any possible changes in the system's orientation will require some sort of review and approval before coming into play. This allows management better oversight over the process than a more hands-off approach. Stringent rules for introducing changes and having them formally approved need to be emplaced and enforced.
Frequent reviews of system metrics, and their comparison against stated goals, will help to check any slippage that does occur. This ties in closely with the Measurement section of this paper.
Putting strict time limits on staff for accomplishing certain limited goals will also work to focus efforts only on the core components, and reduce opportunities for scope creep to filter into a system through boredom or initiative.
Although all these practices may appear to be exclusively project oriented, they are in fact equally important to apply to overall information systems management in the organization. The process, and the outcomes, can be as effective when used to control technical support functions as to manage a new software project.
None of this is to say that systems cannot or should not handle multiple tasks, only that they should be designed or set up with this in mind and not amended later. Nor is it to suggest that staff or contractors will inevitably and perniciously attempt to derail processes from their original objectives. However, managers must recognize that it's often the best intentions that lead to scope creep; filling a request from a single user that ultimately has little impact on general functionality, the desire to slip in a cool feature that might be better suited to another process... these are the sorts of things which can cost excess time and money to deal with after they are in place. Catch them before they are introduced, track them into other projects or processes if they are genuinely good ideas, but do not allow them to derail the primary objectives.
The ability to have a quantifiable system of measuring system outcomes is arguably the most important of these practices, as without it, there is a considerable amount of difficulty in judging aspects of the other recommended practices.
It is recommended that wherever possible, all processes be tied to an actual dollar amount in terms of both cost and benefit. This is extremely difficult and sometimes completely impossible, for example as with proactive technical support or anti-virus scanning--at best, only estimates can be made of dollar benefits from these processes, yet clearly they are valuable. Nonetheless, even if the amount is arrived at arbitrarily, as long as it is consistent, some measure will be available for comparison to alternatives.
Obviously good financial management and analysis systems must be in place for this to occur. However, it's possible to gain a fair amount of dollar approximation simply by engaging in rudimentary time tracking. The amount of time a specific function takes (or the number of functions that can occur within a specific time period) can often be equated back to a dollar value with a simple analysis of payroll costs. Secondary effects should also be watched for--if, for example, the processing time of a certain function does not go down with the introduction of a new system, but the number of rejections, re-entries, or other types of special-case handling goes down subsequently, the system is still resulting in a gross benefit.
Reducing the amount of time it takes to generate reports on measurements is also of benefit. This tightens the feedback loop between cause and effect, and will allow a more rapid adjustment of costly mechanisms, or a more rapid reinforcement of cost-effective mechanisms.
Despite the best efforts of system designers and software/hardware vendors, there are very few "set it and forget it" systems out there today. Nearly every system will require upkeep of some sort--this may be as simple as a brief review by users from time to time, or as complicated as a contract with the vendor.
Lack of system maintenance is another common cause of degradation in efficiency. Regular evaluation of loading demands and hardware assett tracking may be the primary means dealing with this in most cases. Software programs, of course, do not degrade over time, but the hardware they run on can, and software which is in place for an extended amount of time can be susceptible to the issue of invisibility; that is, it may operate so smoothly for so long as to be transparent, and eventually be used outside its design parameters long after those have been forgotten.
Even if no formal maintenance system is put into place, the use of a simple trouble ticket or issue tracking system can be valuable in determining trends and evaluating candidate systems which may require maintenance service.
Although every component of business requires some sort of forward-thinking, technology is especially frought with peril. The rate at which technology evolves puts most businesses in a two or three year horizon for potentially major systemic changes in their IT infrastructure. Some organizations attempt to minimize this by purchasing the newest and best of whatever is available when they are in a purchasing mode, but this is not necessarily the correct approach. Instead, a well-developed view of likely organizational challenges outside the area of IT is a better indicator of necessary approaches within IT. As a supporting factor, it is only necessary that technology meet the need of the business, not exceed it. For many organizations, the actual need is well below the state of the art.
Since the value of an information system to an organization typically lies in the efficiencies it introduces to an existing business process, there are two truths that are endemic to it:
There is a cost associated to any change in systems, beyond the initial investment--organizational momentum, the need for retraining, adaptation, friction costs associated with learning curves, all will exact some price from any system change, no matter how small. The key, then, to planning ahead, is to not only ensure that systems introduced to your information technology structure will continue to be appropriate to your business environment, but also that they can be adapted to forseeable changes that your business environment may undergo inside the planning horizon.
The first step in keeping your IT plans ahead of the curve is to know the path that your business is taking. If you cannot adequately predict that path to within whatever margins are necessary to define a lasting IT structure, do not build out the IT structure; or, build a structure that is broad enough to be adaptable when your business plans do become concrete.
Make large allowances in the time and cost of implementing IT infrastructure. This is something that you will want in place prior to any business initiatives which may rely upon it. It is a nightmare to be implementing new information systems at the same time as new business practices are being implemented--the kinks being worked out in one will almost invariably result in new kinks in the other, and it is tremendously difficult to smooth operations out in both at the same time.
In terms of infrastructure, you should opt for something flexible and expandable.
It should be noted here that there are other methods of regulating and handling IT planning in less predictable business environments, but further discussion of those is better left to another paper (as yet unwritten).