There’s the human factor to consider.  Photo: Workers at the Jamaica Plain Post Office, 71 Green Street, Boston, 1920.  Boston Public Library, CC license

Have you ever spent, say, half a million dollars and nine months of effort with new software or changes to existing systems for purposes of automating processes, only to discover that afterwards the processes are just as inefficient as they were when you started?

I’ve worked on several of these projects.  People claim they can save hundreds of people-hours per week if only …. Usually these projects require custom development of existing software or additional software to eliminate process steps.  Why do these efforts fail to deliver promised benefits?

A ‘soft’ or hard-to-prove ROI .  Frequently labor savings from automation do not result in actual reductions in labor cost; instead the argument is made that the work force can engage in more “value-added” work.  Consequently, if you had 30 people processing customer orders before the automation project and 30 people after, it’s still possible to call the project a success, because you can say that now the customer service team is pursuing more “value-added” work.  But is it?How do you know?

A tendency to stick to comfortable work routines .  When people have been using the same systems to do their work for 10 years, it’s very hard to change their routines and not to do certain steps inside those systems because the steps are no longer necessary.  People are going to do what is comfortable for them, especially when they see only a marginal benefit to changing.  You need a big change management campaign to ensure new more efficient practices are followed.

Higher than expected  costs to modify software .  It is also a human tendency to underestimate costs of making changes to existing software.  In the case of ERP systems this cost can be astronomical – not so much because a lot of hours are needed to modify the software – but because the original code was never intended to be changed in the way we want it to change.  You can only do so much change before the entire program has to be overhauled.  Everything inside a complex software program is interconnected.

So what do you do? 

Avoid big and expensive modifications to software as a way to automate business processes.  The people who created the software had a specific purpose in mind; that purpose may or may not be compatible with what you imagine to be a more efficient business process.

If you want true automation, outsource the process altogether .  Taking pieces of a process and eliminating them through software modifications might be minimally helpful, but it’s not a big enough change to modify behavior.  Yes, to make a process more efficient you may have to remove it from those people currently performing it.  The adage about teaching an old dog new tricks is true.

Outsourcing the process does not mean you can – or want to — eliminate whole departments.  But it does ensure that certain activities – non value-added processes – no longer exist within your organization, for anyone to waste any more time on.

Photo by Official GDC

A packaged application is not ready-to-use, in any sense of the word. The word “packaged” is kind of a misnomer. You won’t find a warehouse management system in a shrink-wrapped box on the shelf at Best Buy. A packaged application is simply one whose features and functions match in general terms what you want the software to do, but which still needs to be configured for your business. Configuration (also called setup) involves a lot of work.

Some important guidelines:

Stick with a software vendor’s competencies. If you have defined your scope as one or two specific functional areas, look for applications that best fit those purposes. It’s always interesting to look at a program’s other features and functions, but unless you see hard returns in expanding beyond the package’s main mission, stay within your scope.

The biggest risk in overspending with packaged applications is during the implementation phase. A single implementation of, say, a system to manage order processing, can cost $2 million to $3 million or more. Why? Two main reasons: a) you don’t know exactly what modifications are needed to make the program work the way you want; and b) you don’t know what delays you might encounter; each delay prolongs the project and adds billable hours to your cost from either the application vendor or other people you have hired to help with the project.

Plan the life-cycle costs of a packaged application. The life of a packaged application can span many years. The main costs will be annual support fees and any enhancement (custom development) work you might need as your business requirements change. Your vendor will also be releasing upgrades to the software, sometimes as frequently as every six or nine months, and you will need to stay current with those upgrades in order to get the best performing software and to continue your support contract.

Understand that software is an annuity business. In simple terms a software company survives in the long run because it is able to collect annual maintenance and support fees from its customers while providing custom development services and a stream of version upgrades. The support fees are 20% to 25% of the original cost of the software license, so to the software firm, it’s like selling a new system to the same customer every four or five years.

Packaged applications generally can’t be implemented by without people who know the app. So the software vendor is not just selling you the application but a team of people to implement it for you. One expert on a project for one year can cost you $300,000 – $500,000.

Photo: Data Center, by Bob Mical, CC license

Early in my career I couldn’t stand anyone talking to me about master data. It just wasn’t interesting, and seemed to be just a minor detail in how systems run.
I have since learned that (incorrect or inconsistent) master data can stop in its tracks the coolest, most sophisticated and expensive enterprise software anywhere, which means it can stop all kinds of transactions in your business.

Master data is data that should have a consistent definition and format across your organization.

For example, a ‘finished good’ (product ready to sell) in a manufacturing company should have the same spelling, Universal Product Code (UPC) and internal product number whether it is listed in a sales report or a manufacturing report.

A gallon of Sherwin-Williams paint, for example, might have the following pieces of master data:

For applications to exchange data with one another, regardless of method, they have to use the same definitions of data. If the sales application uses “lbs.” as part of the description, and the finance application uses “pounds,” some type of translation (more software code) will have to be built between the two applications.

If your master data is not standard across your enterprise, the extra code necessary to translate incongruous data will add to the complexity and cost of integration. These custom integration algorithms will be specific to your enterprise and therefore make your whole application structure more difficult for a IT new hire or a contractor to understand.

To further control costs and complexity of integration:

• Use a hub structure if multiple applications need the same data. This could be an “exchange” where pieces of data are posted then retrieved when needed by applications plugged into the exchange. This avoids creating spaghetti (your application maps look like spaghetti).
• Document everything clearly and insist that all documentation be kept current. Otherwise, you will end up with a complicated setup that is mission critical to your business but that only one person is familiar with.
• Let your ERP system define your master data standards, and keep those standards consistent in all systems. If you have an ERP system, most likely it required you to define and set up master data. Since ERP systems usually span multiple functions, the master data setup is shared among functions and therefore common to departments like sales, finance and manufacturing. Keep these standards in place and use them to define the data transfer with any new application.

Photo: Denver Airport pano, by Doug Waldron, CC license

“Denver Airport” has become synonymous with epic technology failure for those who remember the colossal breakdown of that airport’s ambitious new automated baggage handling system in 1995. Just two numbers explain the magnitude of the failure: 16 months — the delay in opening Denver’s new airport – and $560 million – the extra cost of building the new airport – both a direct result of the baggage system debacle.

Denver Airport has huge lessons for us that can be applied to any software endeavor.

In 1993 a brilliant plan was hatched to fully automate baggage handling at Denver’s new state of the art airport. The key to the automated system was software that would control the movement of thousands of carts moving along miles of track throughout the airport’s three main terminals. The software would direct the movement of the carts to collect or deposit bags at precisely the right time. It was to be a highly orchestrated activity that depended on software that would continuously process complex algorithms. After more than a decade of trying to make the system work, the airport went back to the traditional manual bar code tug and trolley system.

Key Points

Hubris can lead to very bad decisions. The airport’s new system was to be state of the art, the most automated passenger baggage system in the world. Through 26 miles of underground track, bags would move from plane to carousel or gate to plane without human handling. Tours were given to the public to show how advanced the new system would be.

BAE Systems, the company hired to design and build the baggage system, had built several traditional systems at airports throughout the world, but none were as advanced as the Denver project’s design. A sign of early trouble came when the airport bid the design out for construction, and several companies either declined to make a bid or responded that construction of the complicated system within the airport’s stated timeline was impossible. The Denver team was proud of its futuristic design and even these clear signals of danger ahead did not dissuade them from their plan.

Complexity greatly increases risk of failure. All along the miles of track of the new system, thousands of small carts would deposit or pick up baggage at precise points in the network, ostensibly at just the right time. This required complex algorithms that had to account for travel distance, expected flight arrivals and departures, sorting rules and routings, and canceled flights. Scanning devices positioned at just the right locations would read bar code labels applied to bags and route them to the appropriate conveyor. This type of technology, while standard today, still isn’t perfect; you can imagine its relative immaturity in the 1990s.

A ‘Big Bang’ launch of a new system adds to likelihood of failure. Denver’s airport authority had a great opportunity to start small and prove out its advanced system design. The team could have sliced the project into digestible parts in two ways: An end-to-end prototype system on a small portion of the airport’s baggage traffic, or a fully functional piece of the envisioned architecture, such as the bar code label and scanning functionality. Small pieces are easier to focus resources on. Best of all, had the Denver team phased in the system gradually and still faced failures, it wouldn’t have shut down the entire airport. Being able to continue business as normal if the new system fails is an essential but sometimes forgotten aspect of all software projects. Building in pieces or parts allows new learning to be incorporated into the design. Instead, the team gambled on launching the whole system at once.

No backup plan = nasty outcome. Once the Denver team realized that it may take awhile to make the new system work, they rushed to put in place a more traditional trolley system using baggage handlers. But this alone took many months and an extra $70 million before it was completed. In the end, the original advanced-design system was only ever used for outbound baggage at one terminal. Large parts of the airport’s new system simply never worked. But a failure or cost overrun on the original ambitious project is one thing. Because there was no backup, the project was squarely in the critical path of the new airport’s opening. If you’re going to fall out of the boat, don’t drag everyone with you.

OK, you say, your organization isn’t launching anything nearly as ambitious as the Denver Airport baggage system. And of course you would never make the dumb mistakes they made, right? Yes, you would, because every human being makes mistakes; the Denver team just put a lot more at stake. It’s not so much that their software design failed, it’s that they placed a huge bet on their system working – the opening of a new $3 billion airport.

If you visit OmPrompt in the UK you can stay in the nearby dreamy, historic, and beautiful town of Oxford. Photo by Tejvan Pettinger, CC license.

What if you want to make sure all of the data on a customer’s order is correct before it is processed in your systems?  Or if you want to stop orders that you can’t fill based on time constraints?  Many firms at first apply humans to these tasks (customer service), but what if you process 55,000 orders per year?  There must be some way to automate this screening process, right?

There are at least three ways to handle this problem with software.

The first is to modify your ERP system, to incorporate the rules you will apply to every order that is received.  Not only will the ERP system apply the rules and identify exceptions but alert you to those orders that must be stopped and changed before proceeding through the order cycle.

This is certainly a viable option, but you’ll find yourself pouring lots of money into it, with no end in sight, because as soon as you successfully incorporate a set of order checks, the business will come up with a new set of checks based on a new logistics or pricing strategy.  Most ERP systems are not built with user-configurable parameters; changes require programming by expensive resources.

The second is to build some type of middleware filter.  This is a custom application that every order would pass through before entering your ERP system.  The middleware would catch and hold up non-compliant orders.  A lot of firms adopt this route, because it is so much less expensive and much more flexible that tearing into the guts of an expensive ERP system.  And there is no shortage of eager programmers, within company IT departments, who want to build such a tool, in the language they know best on the computing platform they know best.

This second option is better than the first, but barely.  The second option makes you dependent on the genius that builds and maintains that middleware tool, and that is almost as bad as being dependent on an ABAP (SAP code) programmer.  And there will be instances where no matter how brilliant your middleware architect, certain business requirements will be beyond the capabilities of him/her and/or the software they have created.

The third option is to outsource your order capture, partially or entirely, to a firm that has the systems agile enough to handle the ever changing order filters your business may want to apply.  The advantage of these firms is that they serve as adapters: the incoming order is converted to a standard computer script where all of your rules can be applied; the script is then converted to the digital code (such as EDI) needed by your ERP system.

One firm that does this is UK-based OmPrompt, which specializes in automating business processes for large firms all around the world.  Their services are based on transaction volume and are very inexpensive relative to software modifications or building your own system.

I favor outsourcing the job not so much because someone else can do it better (although that is true) but because you cannot predict what is coming down the road in terms of new business requirements.  You need an open system, an infinitely-adjustable capability, if that is possible.  And firms that make their living on being adaptable to requirements like yours will always have more value to offer.

If you don’t know where you are going, you will wind up somewhere else.
– Yogi Berra

IT strategy is not a topic reserved for lofty white papers. It is something you see in action (or not in action) every day and every time you have a decision to make about your company’s enterprise software.

Why would a non-IT executive care about IT strategy? Because whatever your function as an executive, your success will depend on having the right technology tools for your company’s strategy, customers, profit goals, and future aspirations. And you or your department might be responsible for launching a big new system that could really hurt your business if it isn’t done right.

The most important thing about your IT strategy in the 21st century is not how impressive or savvy it is, but whether it fits who you are and what you want to be as a company.

Here are some choices:

The complete outsourcing strategy

Your company outsources all IT and software needs. It does not own any applications; it just uses them as a service. It pays these service providers to upgrade or further customize the applications it uses on an as-needed basis.

The strategy fits you because you want to devote your internal resources to the core business. Your firm is too small to afford a large in-house group of people watching over servers and networks and applications.

The pure ROI-based strategy

You evaluate and select software and IT investments according to strict financial hurdles. Every investment has to pay back within 24 months, and you include all external and internal costs in that ROI model. All projects are reviewed post-implementation to confirm the expected ROI was actually achieved. In-house vs. external solutions are selected according to the best ROI.

This strategy fits your firm because its culture is bottom-line oriented, and has many other attractive investment choices available. Investments in IT have to compete with other promising ventures.

The anticipated growth strategy

Your organization heavily weighs anticipated future needs in decisions about new systems. It looks ahead three to five years to anticipate what customers, suppliers and competitors might be doing. It might end up making a new application investment for purely strategic reasons.

This strategy fits your firm because its success hinges on having the most up to date information systems possible. A large portion of your revenue and profits are dependent on technology that enables you to create new revenues and control costs.

The complete in-house strategy

Your company’s business model is so unique, and its processes and competitive advantage so specialized, that it never finds what it needs in commercially available software packages, other than software for basic support functions like HR, payroll and accounting. It uses software programming languages that are well-known and well-established in the industry so that it has a large pool of talent available for its growing needs.

This strategy fits you because for your company the right software is a strategic necessity and an area in which it invests heavily. You need software solutions that are tightly aligned with your specialized business processes.

A stable, 30-employee company with no significant growth plans can do just fine with many off-the-shelf applications or one of the many SaaS providers now coming onto the market.

A vertically integrated auto parts maker with 3,500 SKUs and contracts with large auto companies probably needs top-of-the-line supply chain and distribution applications capable of strong integration with supplier and customer systems.

A credit card company with 4 million customers needs very secure applications with redundant backup capabilities and rich data mining software to analyze customer transactions.

Invest in applications that help you do excellently those things that are critical to your business. Go light on or buy generic applications for functions that you consider support, and not central to your business strengths, unless you see a clear, hard ROI for one of those areas. But get or develop the best possible applications for those functions that make or break the success of your business.

There is no general rule of thumb for these decisions, just common sense. A company with $10 million in revenue simply won’t be able to afford an application that will cost $2 million to launch and another $500,000 a year to support. The logic of aligning your software tools with who you are as an enterprise is just one more ingredient in staying out of the software money pit.

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.”

Image: open source code for InvoicePlane, by Kovah, CC license

The overhaul of North Carolina’s Medicaid claims system started in 2008. It relied on custom programming and has so far cost the state $480 million. Since its launch earlier this year, no one has been happy. Doctors, hospitals, insurance companies and patients have heaped complaints and scorn on government officials.

All 50 states process Medicaid claims. Several software applications are available for medical claim processing, posing the question of why the state chose to build its own solution.

Understand what you are getting into with custom development. In The Mythical Man-Month, computer programming legend Frederick P. Brooks likens software development to the struggles of prehistoric beasts in the tar pits:

“Large system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it. Most have emerged with running systems – few have met goals, schedules, and budgets. Large and small, massive or wiry, team after team has become entangled in the tar. No one thing seems to cause the difficulty – any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion. Everyone seems to have been surprised by the stickiness of the problem, and it is hard to discern the nature of it.”

Custom projects are especially hard to estimate and manage. Brooks argues that software development projects often fail to meet goals because:

• Estimating techniques are poor, and reflect the pervasive optimism among programmers that everything will proceed according to plan.
• Using estimated man-months to determine cost and length of a project is a “dangerous and deceptive myth, for it presumes that men and months are interchangeable.”
• Project status monitoring is not rigorous enough to prevent slippage, and when projects miss milestones, the natural tendency is to add more people, which, counter-intuitively, will delay the project even more.

The commercial software industry is about 60 years old, yet we haven’t figured out how to convert human thought to computer instructions without spending months or years at it, along with horrific amounts of money. That the software industry has grown so much in spite of these hurdles is amazing in itself.

In the meantime we have to live with the shortcomings of custom programming, as deeply embedded as they seem. We can at least control our exposure to the risks of custom applications by not going there in the first place, at least on a large scale, and limiting the use of custom code to small discrete components such as integration or data capture.

Image by Nick Ayres, CC license

Big software project failures can frequently be tied back to decisions made at the very beginning of the project.

As the government struggles to launch healthcare.gov after the expenditure of several hundred million dollars, it’s logical to question the original decision to build from scratch software programs that may in part have already existed.

In 2001, Nike made the decision to big-bang its launch of new supply chain planning software with thousands of suppliers and distributors all at once, resulting in a massive disruption to its business and $100 million in lost sales.

An overly complex design and an urge to impress the public were two big reasons – made very early in the project — for the colossal breakdown of Denver Airport’s $560 million baggage handling system.

In each of these cases, the main reasons for failure could have been nipped in the bud at the very beginning.

How to avoid failure from dumb decisions at the start? To illustrate, I’ll describe what not to do. I’ve seen every one of these decisions made at some point in some project I’ve worked on over the years.

Launch the project for the wrong reasons. Believe that new software will fix a broken or inefficient process.
Fool yourself about the ROI. Show the CFO numbers you know are a fantasy, just to get approval for your new system.
Make the scope bigger than necessary. Launch a big ERP project when all you really need is a sales planning and trade promotion system, or an updated financials and payroll application.
Develop the software yourself, even though there are reasonably good packaged applications available on the market.
Assign the project to people who are already swamped and who live in different time zones. Run most of the project via conference calls to save money on travel.
Put your weakest people on the project team. Select a project manager who is leading a project for the first time, or who logically should run it based on the organization chart. Don’t free up the critical subject matter experts that will be needed; they’ll find the time somehow. Just empower the team and everything will run fine.
Ensure the application is fully modified to match every nuance of your business so people are comfortable with it. Don’t worry if the solution becomes too complex – it’s software so everything can be programmed.
Don’t place a fixed deadline or budget for project completion; plans need to be flexible to account for unforeseen difficulties, or opportunities for expansion of the solution to satisfy more of your company’s needs.
Ensure everything is launched all at the same time. Why drag out the project in phases?
Don’t try to manage the project with a structured methodology. Doing so will unduly restrict the free flow of ideas and creativity that are essential. Most project methodologies are a waste of time and only serve to increase the workload on the project team.