Prioritizing IT Projects Increases Productivity

After years in I.T., Niel Nickolaisen believes IT projects fail in such high percentages because both IT and business executives spend too much time and energy debating systems that ultimately don’t generate a single dollar of ROI or the slightest increase in market share. And then they devote too many resources to developing technology to support those projects.

Nickolaisen joined Deseret Book, a book publisher, distributor and retailer based in Salt Lake City, as its first ever CIO in March 2003. He found an IT department in chaos. “They had a highly customized homegrown system. The IT development staff spent its time responding to every imaginable request,” Nickolaisen says. “They didn’t have a CIO, IT reported to finance, and there were business processes embedded in their legacy systems that actually got in the way of people getting things done.” So Nickolaisen, who was then a business turnaround specialist at a venture capital firm, was brought in to overhaul Deseret Book’s 20-year-old technology infrastructure and bring order to a random IT project prioritization process.

The goals of his approach are to help Deseret Book make more effective IT project decisions and to bring a sharper focus and rigid analysis to IT project decision making. This method helps Nickolaisen and his executive colleagues identify business priorities around each decision and allocate the appropriate amount of resources?staffing, capital investment and time?to each project. By prioritizing and classifying these decisions, the CIO and business unit leaders can examine them more objectively. They avoid squandering intellectual and financial capital on processes that, while important to the business, would not help the company generate additional revenue or secure greater market share.

Using this mode of classifying projects has yielded tangible benefits, according to Nickolaisen and has greatly simplified the company’s project strategy. He estimates that using this decision model has reduced IT project time lines, costs and resource requirements by 40 percent to 70 percent.

Rewriting the Rules

One of the first major processes that Nickolaisen classified with his model was a project overhauling the Deseret Book system for shipping customer orders. The rules the company had encoded into its legacy systems for shipping products exemplifies the ad hoc manner in which the company had historically made IT and process decisions. Besides its 36 retail stores in the western United States, Deseret Book sells directly to customers through three channels: catalog orders, Internet orders and its book club. Since those three channels evolved at different times, each channel used different shipping rules and fees.

That resulted in doing extra work when processing orders and calculating shipping rates that simply didn’t make sense, says Nickolaisen. So the company decided to apply a single shipping rule to all orders regardless of channel, but which one should it use? Shipping products to customers is clearly a critical process for the continued success of Deseret Book; however, it does not set the company apart in the market. The manner in which products are shipped to customers, as long as it lives up to market best practices, will not win additional customers or increase market share, says Nickolaisen. The goal for the shipping process therefore was to be at market parity. “We don’t have to be better than everyone else,” he says. “We just can’t be worse.”

Filtering that decision through Nickolaisen’s model helped Deseret Book executives realize that how they ship products doesn’t need to be unique. It also helped them decide on a single shipping process?flat fees for standard and priority shipping?in just 15 minutes. They didn’t waste time agonizing over a process that wouldn’t gain the company any additional revenue or market share, and they were able to streamline how they ship products.

The new shipping rules were then encoded into the Oracle ERP system that is replacing Deseret Book’s legacy systems. “All of the ’experts’ we brought in told me it would take three years to implement the new system at a cost of $3 million to $5 million,” says Sheri Dew, Deseret Book’s CEO. “I also heard for years that our company was so unique that it demanded a unique system. Niel came in and in a matter of days completely dashed those assumptions.” This month, Deseret Book will complete implementation of its Oracle ERP system, plus a new point-of-sale system in its retail stores. Implementation will have taken less than a year at roughly half of the previously estimated cost.

Decisions Made Simple

Nickolaisen developed this decision-making model based on his experiences at previous companies and conversations with numerous CIO colleagues. He found that the value generated by most IT projects was often greatly reduced because they grew overly complicated and then exceeded their original budgets and schedules.

When Nickolaisen was the CIO at Franklin Covey, a publisher of planning materials also based in Salt Lake City, the business unit leaders wanted to change the order of certain data-entry fields to record customers’ telephone numbers before their addresses. So Nickolaisen started the ERP customization project, which proved costly and time-consuming.

He realized the time and effort spent customizing the order-entry screens to change the order of data input did nothing to help acquire additional customers or even improve customer service. It cost $100,000 and was, in his view, a waste of the company’s time and resources.

So Nickolaisen’s goal in developing this decision-making framework was to bring sharper focus to the IT project process. He believes projects can generate the greatest value when no time or energy is wasted developing unique and innovative systems if their intent is simply to match industry best practices. Examples of these types of systems include how a company ships products, generates invoices and maintains its general ledger. These processes must be done well, but they don’t need to be distinctive.

This appropriate use of resources helps projects generate value. “Time and cost savings are large when you consider the amount of capital wasted on nonmission-critical projects or projects that do not improve the organization’s value proposition in the marketplace,” says Jeff Yates, Deseret Book’s vice president and CFO.

Since developing this model and applying it to every IT project decision with which he has been involved, Nickolaisen says, he has not had a single failed project.

The Project Types

Nickolaisen’s model places a project in four general categories based on whether it provides an outcome that is imperative and whether it will make the company stand out in the marketplace. Depending on how each system fits into both those criteria, they are classified as Type 1 through Type 4.

1 Mission-Critical: Yes Differentiating: Yes

Type 1 processes are mission-critical and they differentiate a company within the marketplace. This means performing these functions is essential for the company to remain in business. They also help facilitate a unique service or product that the company needs to remain competitive. Product research and development is one example of this type of process. For Nickolaisen and Deseret Book, it is the ability to determine and fulfill needs within their publishing market that give them an edge over their competition.

2 Mission-Critical: Yes Differentiating: No

Type 2 processes are mission-critical. They have to be done well or the business is at risk. They do not differentiate a company within the marketplace, however. Examples of these types of processes include billing, shipping products and maintaining finances. These are all necessary for the company’s success, but investing heavily in inventive ways to generate invoices or balance the company finances will not gain customers or increase market share, even though both of those tasks are indeed vital. The mechanics of purchasing and distributing the third-party titles Deseret Book sells in its retail stores and processing invoices for those purchases do not need to be unique or exceptional and are therefore other examples of Type 2 processes. When Nickolaisen arrived at Deseret Book, there was a convoluted process for setting up suppliers, making purchases, and processing invoices and returns. Once the management team, retail buyers and finance agreed that purchasing was a Type 2 process, Nickolaisen says, they were able to reengineer the process in about 15 minutes.

3 Mission-Critical: NoDifferentiating: Yes

Type 3 processes are not essential, but they can provide competitive advantage by differentiating the company. Such projects include partnerships or collaborations where each company focuses on its core strength, yet the combined result is more than either could accomplish individually.

4 Mission-Critical: NoDifferentiating: No

Type 4 processes are the least critical to the business. They can be important, but if interrupted somehow, the business would survive. These processes, such as cleaning and maintaining office space, typically do not benefit from IT investments.

The Model at Work

When making IT project decisions at Deseret Book, a business unit sponsor first identifies a business need. Nickolaisen and his IT staff then work with the business sponsor to quantify that need. This is when IT and business filter the project through Nickolaisen’s model. Once they have classified the project components as mission-critical, differentiating or both, IT and the business leaders can build an appropriately weighted business case for the project.

Once the project and process types are classified with the costs and benefits specified, both IT and the business unit leader present the project proposal to the IT steering committee, which includes the executive management team, for approval.

Nickolaisen contends that most processes are Type 2: mission-critical but not differentiating. When CIOs and their colleagues in finance and business leadership understand this concept, they can help save the money and effort that is better spent on the more significant and demanding Type 1 projects.

“You really should be spending your brainpower thinking about that 10 to 20 percent of things that are Type 1,” Nickolaisen says. For Deseret Book, product development and product selection are the most significant processes that are both mission-critical and differentiating. “We have to do them better than our competitors,” Nickolaisen says.

Communicate and Reassure

One of the most critical factors to successfully applying this model to IT project decisions is to thoroughly communicate the importance of Type 2 processes to their respective business unit owners. Just because they are not unique does not mean they are less important, says Nickolaisen.

He says that process owners may take it personally when they hear that a project does not create a competitive advantage, even though it is still important to the well-being of the enterprise. Reassuring executives of the importance of those critical functions keeps them thinking within the parameters of this model and prevents them from insisting on allocating excessive resources to a project that won’t differentiate a company in its industry.

When he used his model to classify the processes related to upgrading Deseret Book’s legacy financial systems with Oracle ERP, Nickolaisen had to reassure his CFO and other executives of the importance of processes like maintaining the general ledger. “Do our financials matter? Yes, but do you go out to a customer and say, ’You should see our general ledger design?’” Nickolaisen says. Any process that is not customer-facing is most likely a Type 2, he adds.

A CIO needs to establish credibility with the business leaders to get them to comfortably consider decisions within this framework and to see it for the objective assessment that it is. “You have to be able to make the case that it’s really about optimizing business value and not easing the CIO’s workload,” Nickolaisen says.

The two most important relationships the CIO has in working through this process are with the CEO and the CFO. “Implementing [this model] is improving our communication with IT in every respect,” says Dew. “It is streamlining essentially all of the processes related to IT as well as supply chain management. We are refining our internal processes, and the result is savings in overhead dollars, personnel and time.”

Nickolaisen says his model has saved Deseret Book in implementation costs and overhead, and made the decision-making process more efficient. He has found that prioritizing and allocating the right resources generates value.