Rules for Managing Your Technology Investment

It's my sad observation that

most retailers and wholesalers do not get their money's worth from their investment in technology. Most of these failures occur because the company fails to apply some basic rules of business to these technology investments. This month I'll be sharing with you seven rules that every company should use in determining how to make investments in technology, and in managing the development and implementation process. Many of these concepts were presented by Kevin Turner, Wal-Mart's vice president of information systems during a recent industry conference.

Rule No. 1: Every project must have a sponsor.

The sponsor is the ranking company executive who is responsible for this project. The sponsor must develop a benefit value for the project that he or she is willing to commit to management. These values must be measurable, and the system itself must be able to report these values on a regular basis. The IS department is almost never the sponsor of a project.

Rule No. 2: Every project must have an ROI.

Measuring ROI is not an exact process, but every project can have an ROI. Your company should not invest in a new project if it can't change an existing process. If you can create this change, then the change is observable. If it's observable, then it can be measured. And when the project is done, expect to measure and re-measure that ROI.

For those who are regular readers of my column, this emphasis on ROI is another approach to establishing the definition of success. While an ROI is a quantifiable object, if quantification does not appear to apply you must have a written management statement that defines the objective of the project and how that definition of success can be measured.

Ultimately, the project sponsor is the person accountable for achieving this definition of success and its associated ROI. Your CEO should meet at least twice a year with every corporate sponsor to review his or her progress. This progress should be graded, i.e., "A" for a project that exceeds objectives by a significant amount, "C" for a project that meets its objectives and "F" for a project that is being killed because the goals can never be met.

Rule No. 3: Every project must be aligned with your business goals.

There are too many good ideas about things you could be doing with technology. The only way to be sure you're doing the right ones is to align your IS priorities with your corporate strategic goals. Hopefully, these goals are committed to writing on a regular basis, and they must be reviewed annually to make sure they still apply. Too often, projects run on forever because management never reassesses beliefs or priorities to see if they still fit their corporate objectives.

If you have a statement of your strategic goals, are these goals shared with the company's management, including IS? They should be, and you should have at least one meeting a year at which the focus is on how technology could be used to achieve these objectives.

Rule No. 4: The people working on the project must understand the process before they attempt to change it.

This means that IS employees must work in the department targeted for change before they can begin to identify how to change it. That means that if your project is in the stores, the IS team must work in that store area before they begin to develop a new approach. As a guideline, before this team decides to change a process, their first goal should be to try to eliminate it.

When a solution strategy has been established, the first priority should then be to try to find an existing program product that accomplishes those goals. The biggest waste of time in companies is when talented people take the time to solve a problem that already has a solution! Today almost every company, with the possible exception of industry giants like Wal-Mart, is looking to buy solutions, not to build them. Internal technical staff resources are used to integrate off-the-shelf solutions, with any modifications held to the absolute minimum.

I would look very, very carefully at any project that cannot be satisfied with generally available software. Generally, these conclusions are biased by a staff desire to achieve perfection or to replace an existing application with one that looks just like it in every detail to avoid incurring organizational and procedural change.

Rule No. 5: Every project must be adequately funded.

Funding includes adequate staff and technology to develop and sustain the project. Supporting this process must be a commitment to its success from the highest levels of the company. Lastly, funding goes beyond providing an adequate staff to assure the operational viability of the project; it extends to making sure that the corporate organizational structure has been reviewed and changed if necessary.

A good example of a project with an organizational issue is customer-specific marketing. The head of this effort predictably will have conflicts with the company's category management organization. The category managers typically control all corporate promotional funds, and they will be reluctant to share these funds with another effort. Management must resolve this conflict as part of the "adequate funding" issue. It is both a funds issue and an organizational issue.

There is another corporate conflict in the time periods used by each of these efforts to measure success. Typically, all category management efforts are measured in time slices that coincide with corporate fiscal periods. Customer-specific programs typically take longer to implement, and achievements tend to be measured in time frames that cross fiscal periods.

Funding a project is based upon a premise of when the project will be completed. This leads to a continuing issue in all technology projects: When are they completed? From my perspective, a project is done when it is completely implemented in all stores or all departments or all divisions. A project is not done when the programming is completed nor when the pilot test is over. As part of managing a project everyone on the project must have a commonly shared understanding of what "done" means.

Rule No. 6: Make sure your business partners are as committed to the project as you are.

Every contract with a seller of a product or a service must have either a penalty clause or a cancellation clause that is invoked if goals are not achieved. At a recent conference, I was discussing the recent retirement of a long-time CIO. The gossip is that he was retired because his major project was exceeding its budget by over 60 percent. While this may well be appropriate, it makes me wonder what is happening to the company's vendor partner, who swore that the budget was realistic. It sounded as if the partner wins by failing, i.e., it was being paid more than its original proposal said was necessary. That doesn't make sense to me.

Yet I understand the argument that the developer of software wants to be accountable only for failures of its (program) code. If it is not party to the budget and planning process, that argument might be valid. However, the vendor crosses over the line (into responsibility and accountability) if it recommends a budget and a timetable that are used to justify the project to management. Negotiating vendor responsibility is never easy. Perhaps this is why Wal-Mart has a rule that every contract, no matter how small, must be negotiated by three different people before it is signed.

Rule No. 7: Try to anticipate change, and make sure that any new project fits the character and priorities of your business before you embark on it.

Projects must fit your company's operating style. If your style is to keep headcount at headquarters to the absolute minimum, then perhaps you should not plan to implement a frequent shopper program with an emphasis on customer-specific marketing. CSM implies that your company is going to spend time analyzing customer purchase data, and that requires dedicated staff resources, not part-time efforts by people in your organization who already have other full-time jobs.

The other dimension of this rule is anticipating change. Some people are futurists and are quite skilled at anticipating the future by studying the present. For those who don't have these skills, the trick is to read a lot, and watch what is happening in other industries and what industry leaders are doing. Some retailers have realized great insights by benchmarking their companies against others whom they consider industry leaders. In benchmarking you try to measure your company's performance and facilities with those of another company. The trick is to select a company of comparable size and operating style. For a retailer with five conventional stores to try to benchmark itself against Wegmans would be foolish.

A retailer should think twice or perhaps three times before committing to a project that places it on the leading edge of technology. Too many vendors are selling vapor ware, and the cost of technical failure can be very high. Whenever I've worked with retail clients on the selection of technology, almost every one of them will err on the side of selecting the solution that represents the least risk to the corporation. I agree with this position. Most retailers are better served leaving technical risk to those who can better afford it, or who desperately need the new technology to sustain a fundamental business objective.

Will following these rules guarantee success? Of course not! But it will guarantee fewer failures, project overruns and out-of-control projects. It could be the difference between being a leader in your marketplace or an also-ran.