Image by Nicolas Will, CC license

Behind every idea is a set of assumptions.  These assumptions can be exposed by simply by asking “why”?

When it comes to good technology management, it’s your job to test these assumptions, to kill the losing propositions or to make them more viable as sound investments.  Sometimes these assumptions are wrong – and a lot of them need to be right in order for a project to succeed.

Many people don’t realize the number of assumptions they make when a technology project is launched. Among them:

• what they saw in the demo or pilot will work in the real world;
• the software will meet all the business requirements that were specified before the project started;
• the team won’t have to make any customizations other than what was already identified;
• users will quickly learn and accept the new system;
• the project will be completed on the promised date.

In my book I described a hypothetical conversation between a manager and a CIO/CEO.  The manager was explaining that “the new system will give us real-time visibility of our vendor inventories and plant inventories, and instead of waiting for reports we’ll see our inventory positions and planned production and receipts real-time.”

Taken at face value, this statement implies acceptance of the following assumptions:

1. The way we think of “real-time visibility” of inventories, production and receipts is the same as what the system can provide.
2. The view of said data will be in a useful format and will provide all the data we need to make better/faster decisions.
3. These better/faster decisions will enable us to let our customers order within a shorter lead- time window and will reduce our on-hand inventories.
4. The savings from lower inventories and the additional sales from our late-order customers will more than pay for the cost of this new system.
5. A change in business process (i.e., how we manage inventories and production) would not produce these same benefits.
6. Out of all of the possible system solutions this one is the best choice from an IT strategy, cost and ongoing support standpoint.

A pause for a minute to question these six assumptions may well be the most valuable minute ever spent on the proposed project.  All kinds of havoc and wasted money can be avoided just by testing these assumptions.

And as you can see you don’t have to be an IT expert to successfully manage technology.  You just have to use common sense, by testing the logic that if we do X, then we will receive Y benefits.  If you are going to invest in technology, you may as well do it the right way.

The short answer to why corporate software costs so much is that implementing it takes so long, even if everything goes perfectly, which happens exactly as often as Haley’s Comet passing through our skies. It’s expensive for one reason: specialized, and therefore expensive, skills. It takes expensive skills to:

• write the software in the first place;
• modify it to your precise business needs; and
• install and test it and fix problems before you can use it.

The three biggest cost buckets of a software investment are implementation, software modifications, and the cost of delays or disruption to the business.

What is “implementation”? It is the process of making your business function using the new software, or “integrating” the software into your business, however you choose to look at it. Companies have different philosophies about this; some insist the software must be modified to accommodate the way the business functions; others believe in keeping the software as “vanilla” as possible by changing processes to fit the way the software was designed to work.

There is probably a happy medium.  I think the more you modify a program the more trouble you can expect.  It is not unusual to spend a (low) percentage of the project cost on modifications.

“Implementation” is also the process of matching each step in your business process to corresponding steps in the software. A business “process” is usually something like “ship a customer order” or “receive a shipment from a supplier.”

There might be 100 or so distinct business processes in a company, each with five to eight steps or transactions involved, so a software implementation could involve matching all of those 500 to 800 steps or transactions to the new software, and that takes time, knowledge of your business, and knowledge of the new software.

That’s why implementations are expensive: high cost per hour multiplied by many hours.

But if a perfect project is expensive, imagine how expensive a delayed or failed project can be. Failure is the norm, according to some studies, defined as over budget, not meeting implementation dates, or not delivering functionality as expected.

I would add to that list, from personal experience, failure also includes unexpected business disruption, like temporarily shutting down a manufacturing plant or shipping to your customers a day late. So the fact that software implementations are perceived to be wildly expensive is not just because software implementations are wildly expensive anyway – they also have a high failure rate, which only adds to the cost.

A Nike Factory store in Atlantic City, NJ.  Photo by Shabai Liu, CC license.

Background

In February 2001 Nike, Inc. announced that it would miss sales and profit targets for the quarter due to problems with supply chain software it had begun to implement the previous year. The company said that it had experienced unforeseen complications with the demand and supply planning software that would result in $100 million in lost sales.

Nike was trying to put in a system that would cut its response time to changing sales demand. These types of systems rely on algorithms and models that use historical sales data combined with human input to generate a sales forecast, which is then converted to a manufacturing plan and orders for raw materials from suppliers. It’s not easy to set up and successfully run these applications to produce optimal results. The process demands a lot of trial and error, testing, and running in parallel with the old system to shake out bugs.

As reported by CNET News’ Melanie Austria Farmer and Erich Leuning, SAP spokesman Bill Wohl, reflecting on Nike’s dilemma, said at the time, “What we know about a software implementation project is that it’s just not about turning on the software. These projects often involve really wrenching changes in a company’s business process…It involves changes in the way employees work, and anytime you make changes in the way employees are used to working, it can get difficult.”

Nike is in the apparel business, where styles come and go, and where advertising and promotional programs can spike demand, requiring the supply chain to react just in time, delivering to the market just the right amount of each style. An oversupply of shoes or other apparel will lead to discounting and reduced profits, and an undersupply will lead to lost sales. Nike ran into both of these scenarios, and its profit dropped while sales declined, resulting in the $100 million unfavorable financial impact to the company.

Inside the logic of the software Nike chose, parameters and settings must be optimally set for the most efficient quantities to be produced and distributed to the market. It’s very easy to get it wrong, and companies launching this type of application usually run a pilot for several months before they are satisfied with the recommended production and distribution plans generated by the software.

Much has been written about Nike’s experience, and much of it is valuable for any enterprise thinking about a similar project. Keep in mind, though, that this was a public spat, and both the software firm and Nike told their own version of the story for the public record. That means we don’t have all the facts. Nonetheless, I think there are valuable lessons in the Nike story, and at the risk of not getting all the facts right, I present my conclusions more to help you learn and succeed than to cast blame on any of the Nike project participants.

Key Points

Here is what I think were the main issues in the Nike project:

Complexity of the application without commensurate resources applied to making it work. Christopher Koch, writing in CIO Magazine at the time, said “If there was a strategic failure in Nike’s supply chain project, it was that Nike had bought in to software designed to crystal ball demand. Throwing a bunch of historical sales numbers into a program and waiting for a magic number to emerge from the algorithm — the basic concept behind demand-planning software — doesn’t work well anywhere, and in this case didn’t even support Nike’s business model. Nike depends upon tightly controlling the athletic footwear supply chain and getting retailers to commit to orders far in advance. There’s not much room for a crystal ball in that scenario.”

I don’t fully agree with this assessment; I think demand forecasting systems are critical to modern businesses, and if configured and used correctly, bring many benefits. Other reports said Nike didn’t use the software firm’s methodology, and if true, this would greatly contribute to its troubles. I have implemented these systems and they require precise attention to dozens of settings and flags, pristinely accurate data, and the flawless sequential overnight execution of sometimes 30 or more heuristic calculations in order to produce a demand forecast and a recommended production and raw material supply plan.

It’s also critical with these types of applications to have the right subject matter experts and the best system users in your company on the team dedicated to making the system work the right way for your business. This is where, if published reports are true, I believe Nike may have failed. It is possible Nike simply needed more in-house, user-driven expertise, and more time to master the intricacies of the demand planning application.

In 2003 I ran an ERP project that included an overhaul of supply chain systems. The suite included demand and supply planning solution software, which we would use to forecast demand, generate a production and raw materials supply plan, and determine the plan for supplying product from plants to distribution centers. Unfortunately the best system users declined to be part of the team due to heavy travel requirements, and we had multiple problems getting the parameters right. The supply chain suffered after launch as incorrect production and distribution plans disrupted the business for several months.

Combining a maintenance-heavy, complex application with an organization unwilling or unable to meet the challenge is one way to find the money pit.

A ‘big bang’ approach to the launch without sufficient testing. Despite prevailing wisdom and suggestions by veterans that Nike phase in the new application, Nike chose to implement it all at once. This immediately put at risk a large portion of the Nike business. A phased approach would have limited the potential damage if things went wrong.

A case study of the project published by Pearson Education discusses this point: “Jennifer Tejada, i2’s vice president of marketing, said her company always urges its customers to deploy the system in stages, but Nike went live to thousands of suppliers and distributors simultaneously”

The study also quotes Lee Geishecker, an analyst at Gartner, Inc., who said “Nike went live a little more than a year after launching the project, yet this large a project customarily takes two years, and the system is often deployed in stages.”

Brent Thrill, an analyst at Credit Suisse First Boston, sent a note to his clients saying that because of the complexities he would not have been surprised if to test the system Nike had run it for three years while keeping the older system running. According to Larry Lapide, a research analyst at AMR and a supply chain expert, “whenever you put software in, you don’t go big-bang and you don’t go into production right away. Usually you get these bugs worked out . . . before it goes live across the whole business.”

I can understand that Nike would want to convert a large portion of its business and supplier base at the same time. It reduces the length of the implementation and therefore the cost of maintaining consultants and support staff, and it eliminates the need for temporary interfaces to existing systems.

But a smart move might have been to launch and stabilize the demand planning portion of the software first. It’s easy for me to second guess, but Nike could have taken the forecast generated by the new system and entered it manually into their existing, or ‘legacy’ systems. After all, if the forecast is wrong, then everything downstream – the production, raw material, and distribution plan – are also wrong. I did this on two projects, and it significantly reduced risk. On both projects we launched the demand planning (DP) application and ran it in parallel with our legacy system until we were satisfied with the results, then we disengaged the legacy DP application and began manually keying the new system’s DP forecast into our legacy production, raw material, and distribution planning software.

Software-as-a-Service is challenging the paradigm that software is a thing you buy, take back to your office and install. Looking back some day, we might shake our heads and wonder why any enterprise ever thought it had to purchase and physically install a copy of millions of lines of code that ran on a computer within its premises, just to transact day to day business.

On-premise going the way of cassette tapes……?

The market is receptive to more and more SaaS solutions, and software firms are positioning themselves to offer those products. Most of the big, traditionally on-premise software providers now offer at least some of their applications in SaaS form. For you, this will mean more choices.

But remember this: SaaS applications do not guarantee perfect performance and 100% uptime. They are still computer programs running on a server somewhere, and if those programs are buggy, unstable, corrupted, or lack proper expert support you will land in the money pit just as sure as if you bought that same buggy and unstable application and installed it in your own data center.

Are there any good reasons why you would want a traditional on-premise application?

Yes: security is one reason, in certain circumstances. No matter how demonstrably secure a third party may seem, you simply may not want to entrust your data security to a third party, period.

Your customers, particularly, may want the relative or perceived assurance of your own firewall surrounding your applications and their data. Their business relationship is with you, not the company hosting your applications.

You may already have economies of scale suited to on-premise hosting – plenty of server capacity, a built-in support staff, and developers on your team who are capable of building out the application the way you want it.

If you are positioning the application to be used by several divisions within your company, you may also want central on-premise hosting. You may want to tightly control modifications to the “core” system and also manage access permission levels among users, as well as the total number of users. These actions can significantly reduce per-user costs.

With SaaS applications, you still need to do the same due diligence you would do with a traditional on-premise application. The fit analysis, testing, and project management are largely the same, as are the same precautions to avoid the money pit. You can still spend a fortune modifying a SaaS application, as well as integrating it to your other systems and pulling data out of it for analysis purposes.

Photo: astronaut Eugene Cernan salutes American flag on the surface of the moon, December 1972, Goddard Space Flight Center, CC license.

Our team felt pretty good one day in early March, 2012, when we went live on an SAP system — manufacturing, inventory, order processing, MRP, demand planning, purchasing, shipping and receiving, and finance – with no business disruption, in 90 business days, and 30% under budget

We arrived at this happy conclusion because of (good) decisions made early in the project — decisions about strategy, scope, preparation, technology selected, and the makeup of the team.

How do you drive success — especially if you’re not savvy to enterprise software in the first place?

1. Can you, in a three minute speech to your CEO, sell the project: why you need $2 million and 15 people for nine months, and how your company strategy and your customers demand this kind of investment? If not, start over.
2. Only pursue projects with an unambiguous and demonstrably positive ROI based on realistic assumptions. Leave the great ideas, dreams and wish lists behind.
3. Leave no room for surprise costs. You’ll find them in these categories: additional user, site, or department licenses, support fees, custom programming, server, network, PC and operating system upgrades, future version upgrades, project consultants, and backup staff and travel for the team.
4. Use only your best people for the team. Nothing is more powerful than an experienced, focused, and motivated team with a mandate from top management and a simple, clear objective. If you can’t afford to free up your best people, you can’t afford the project.
5. Decide what is included in the project and what is not, clearly and as simply as possible. Ruthlessly prevent any changes to the scope.
6. The software you choose: prove that it works in other enterprises, preferably companies like yours. It should be familiar to consultants or programmers you may need, now and in the future.
7. Pick technology your company’s users can easily master. You can do lots of damage with people who don’t understand the new systems they have to use.
8. Insist on a full under-the-hood evaluation of the fit of the system with the business. Have the software vendor prove that it meets your requirements by piloting your business scenarios in the application.
9. Protect as much of the business as possible from the inevitable problems of a new system. Break up the “go-live” into manageable parts and have a manual backup plan to keep the business running.
10. Remember this quote from software legend Frederick P. Brooks: “How does a software project come in six months late? One day at a time.”

The welling up of excitement around the idea of acquiring new systems is palpable in companies; the feeling is that action is being taken to move the enterprise forward.  And it’s hard to be the skeptic in the room, but you must, if you are to be a successful manager of technology.

One of your main roles as an official or unofficial manager of technology is to keep asking questions. This has the effect of exposing and testing the initial rationale for a project. For example, in the scenario below let’s say you are the CIO or CEO.

CIO/CEO: What exactly are the benefits of this investment?

Manager: We’ll be able to cut customer order lead time and reduce our on-hand inventory.

CIO/CEO: Great. How?

Manager: The new system will give us real-time visibility of our vendor inventories and plant inventories, and instead of waiting for reports we’ll see our inventory positions and planned production and receipts real-time.

CIO/CEO: So people will be monitoring inventories, planned and actual production 24×7?

Manager: Well, that’s possible, but might not be necessary…

CIO/CEO: How exactly will the order fulfillment and material buying change after the new system is put in?

Manager: As I said, we’ll be able to see the real-time situation, and be able to make better decisions…

CIO/CEO: Yes, but exactly what will change, in terms of process, compared to today, to give us these benefits?

Manager: We’ll be making smarter decisions because of the real-time information and ….

Does this dialogue ring true in terms of how projects are justified? The problem in this hypothetical conversation is that the manager hasn’t thought beyond the basic headline argument that real- time views will make everything better. This should be a danger signal – people have bought into an imagined benefit without proving out to themselves exactly how this benefit will be achieved.

Some other relevant questions in this scenario would be: “Is lack of real-time visibility the only constraint to lower inventories…how will lower inventories translate into real savings besides reducing cash flow…how will you change your decisions about production and will the company be able to execute these changes in production scheduling…when customers miss the order cutoff do they order anyway and take delivery later…?

Asking questions, especially specific ones, quickly changes the conversation from one of vague potential to real-world feasibility.  You will be viewed as a wet blanket, a naysayer, a stick-in-the mud cranky old fashioned Resister to Inevitable Change.

But in positioning yourself in this way you have taken the first steps to successfully managing technology.  Your questions will initiate pragmatic thinking.  They will cause people to stop and consider the realities of what they are proposing.  Reality is a good thing.  You will set in motion a different but important conversation.  Your questions are in effect defining the requirements that the proposal must meet before it can be considered a worthwhile endeavor.

How do software projects get started anyway? Someone went to a conference. A department manager wants to “streamline workflow.” A sales VP says his team is wasting time with old and slow systems. A “transformational” project is launched. A new plant or warehouse is being planned. Customers start asking for things your company cannot do with existing systems.

In each case a person or group of people claims that, with a new system, all kinds of benefits are possible. But anyone can create a list of benefits; with some creativity you can build an attractive ROI for anything.

How can you tell your project might have to be stopped before it fails?

• Having spent weeks evaluating software demos by different providers, your VP of Sales and her team is convinced the company should purchase and implement vendor B’s solution.
• The technology demos well and looks cool, but the ROI is unclear and seems contrived.
• No one has documented a thorough summary of how a new system will be used to run your business.
• Even though the vendor has quoted implementation, license, and maintenance costs, other costs like integration with existing systems are unknown.
• No one in your enterprise is familiar with the vendor’s products or reputation.
• It’s not clear what kind of internal team you will need, and how you will free up those people for the project.
• There are many parts of the solution that will have to be custom-developed (invented).

There is always a possibility out there, imagined by someone or everyone, that a particular technology investment could produce different processes, eliminate waste, inspire minds, please customers.  But a sober clear-eyed assessment is what is needed before grand project aspirations can begin.