![]() ![]() |
||||||||||
|
Effective Technology Strategies: The Value Method I see many technology projects defined on the merits of the initial costs of the purchase. I see many deployments decided by the simple factors of immediate economics. I see many solutions extend beyond their budgets. And I see dissatisfied businesses. A technology purchase uses one of two philosophies. It is either a commodity purchase or a value proposition. Let me explain: In a commodity purchase, you buy what is available at the current moment at the best possible price. You get estimates from companies A, B, C, and D. The one with the lowest price capable of delivering the requirements gets the project. You repeat the same process for future projects whether infrastructure, or, albeit more complicated, long-term support, custom software, databases, security, or Internet functions. Here's a simple example: your basic infrastructure requires upgrade. The network is sluggish; servers are non-responsive; workstations are slow; and complaints are abundant. You may write a request for proposal for upgraded servers and workstations and a second for an upgraded Wide Area Network. You find a budget or source for the money, and get a few bids on the "specifics of your request". The vendors present a cost breakdown for hardware, installation and possibly support. You try to compare the information "apples-to-apples". Finally, you pick a couple of vendors and get the systems installed. You are done! The price was great! Well, not quite! There are a number of pitfalls. The installation may be technically correct, but the configuration nuances can drive users "up-the-wall". Despite the simplicity of the change, staff may have difficulty adapting. Data may not reside where they expect it to be. Staff members may abandon their regular functions and turn into extra support technicians. Support costs for the new system can spike. Simple incremental upgrades can be incredibly expensive or difficult and expensive. Inter-vendor coordination may be difficult long-term. Your initial savings are rapidly fading. Not only are you not reaping expected improvements, your costs are also increasing. It turns out sluggish systems were not the heart of the problem, but only symptoms. You need a new project! Let's examine the value purchasing process to win the battle and the war! You are buying the solution to your current needs with its technical commodities. In addition, however, you want the know-how, processes, resources, capabilities, business partners, people factors, and long-term vision from your vendor. You are, in effect, creating a technology partner to look after your interests in the same manner as your lawyer takes care of your legal interests. Despite the promise, the difficulty with this approach is partner evaluation. It is easy to quantify commodities! The value process is not simple and "apples-to-apples" comparisons may be highly misleading. Let me put it this way, did you select your business attorney based on the lowest hourly rates of your prospects? Is this how you select a surgeon, accountant, financial advisor, or even a wedding planner? The evaluation criteria will be different for each business. Similar criteria carry different weights. Some criteria may be completely unique to you while general ones may be totally meaningless. A complete list being relative, here are five general ones to consider. 1. What level of understanding does the prospective partner have of your business and its special nuances? An understanding of your business and staff is just as important as technical knowledge. You can gauge the understanding and willingness to learn through a series of interviews as well as formal and informal meetings. Look for the intangibles. These may be as important as the actual purchase. 2. What is the breadth of capabilities the vendor offers, supports, or consolidates on your behalf? A smaller vendor base simplifies your life. It eliminates the finger pointing ritual. On the other side, the partner has a larger incentive to perform. After all, if you cancel your account, it is a bigger loss to the partner. 3. Does the partner present a process that fits you today, and adjusts to your future needs? The more you grow, the more complex your information systems become, the more expensive they are to operate. The opposite is also true, if your business shrinks or partially transitions operations, you may not need complex systems. Your partner should be able to work with you in both instances. Support agreements must have growth and shrinkage built into them with little overhead associated with change. 4. Does your prospective partner have a good management process in place to handle your current and long-term needs? The top reason for Information Systems project failures is NOT technology. It is inadequate management. Other problems include badly defined objectives, and unrealistic expectations. All related to management. Understand how your prospect plans to manage your work. 5. Do you feel comfortable with the people working with you? Information Systems projects are, often, very different despite similarities. There is always a level of learning as you go. The management team must display a level of adaptability, and let's face it; they must be able to work with you and your staff in a productive way. Let's look back at our infrastructure project. An initial timetable is laid out based on the partner's knowledge of the market and what is doable for your proposed solution. A good partner, however, will not proceed without re-evaluating the problem and solution statements. Early on, you discover that the server and workstations are just fine, and the heart of the problem is the combination of the Wide Area Network, software running on the server, and security adjustments. In fact, you can extend the life of your servers and workstations another 18 months. The project has changed into a software upgrade, reconfiguration, and Wide Area Network upgrade. Without the cost of workstation replacement, you can now afford even better Wide Area lines. The plan and timelines are readjusted. Communication with your staff starts immediately and they are involved in the reassessment of security designs, regulatory compliance (like HIPAA if applicable), prioritization of rollout schedules, and development of acceptable disruption timelines. For all but the simplest projects, a business process continuance plan is included to ensure everybody will be reasonably operational through the changeover. Contingencies cover risky parts of the changes. The implementation ends up solving the real problem. You may even transition the project to your partner's support team. A good support team does not only break-fix, but also helps staff increase their capabilities. You want them to have the car, but it is important to help them get it out of first gear. A good support team proactively prevents breaks from occurring in the first place. And a good support team makes continuous improvements to reposition your systems for meeting ongoing needs with an eye on market direction. Having taken the first step with you, your technologist is now better able to advise, manage, and possibly help implement future moves. Software, Databases, Internet, and Integration projects are even more complex. And I do not want to imply that internal staff is incapable of finding true problems. However, getting a view from an outside trusted source with expertise, not directly involved in your internal political structure, may be beneficial. And by selecting one partner to complete the project and provide ongoing support, you make sure your partner not only consults but also implements and lives with the consequences. |
![]() |
|||||||||
Copyright © The Technology Group, Inc.
All Rights Reserved. |
||||||||||