Image: Island Peak, Nepal, by McKay Savage, CC license

“Scope,” or “footprint” in software terms refers to the number of business processes that an application will “cover,” or enable.  The scope of an accounting system is usually: general ledger, accounts payable, accounts receivable, fixed assets, P&L and balance sheet.

The scope has to fit the application, and vice versa, and it has to be feasible for the project team and deliver the benefits expected to pay back the investment in the new system.

Too big a scope can overwhelm the team and the application you select.  It will also cost more.  Too small a scope might not be worth the time and expense, and may not yield the financial benefits expected.  A creeping scope starts out small and feasible, then as the project progresses scope is added in the form of requests for features and functions not originally planned.

Money pits are usually found at the end of projects with too big of a scope or a creeping scope.

How do you find the right scope?

Determine which areas of the business would benefit the most from a new or better application. Can you define the specific problems that are leading your enterprise to consider new software? Where are those problems located – in what functional areas and related to which current (legacy) system? Is the problem that a) a particular application is too limiting; b) a group of applications are islands and that integration of them would yield benefits; c) none of your applications are integrated; or d) something else?

Consider a range of scope options to find the optimal one. In some cases, expanding the scope of a new application beyond “problem areas” can be the optimal choice. The process is iterative, and you should consider several alternatives. For example, implementing a new accounting system may satisfy most of a company’s needs and produce a good ROI on its own. But expanding the application footprint to, say, payroll and purchasing, may result in an even better return because it simplifies integration costs, eliminates more manual work, and may strategically be a better decision.

Set up a framework to evaluate each scope alternative. In a framework (Excel comparison) you can evaluate each scope option according to such factors as cost, complexity, length of time to implement, risk to the business, ROI, required internal resources and strategic value. Then you have a logical basis for your decision.

The scope of an ERP project does not have to be huge. You can be selective in what processes to migrate to an ERP system, and you don’t have to convert everything at once – both of these steps will reduce the overall risk of the project. For example, you can implement demand planning systems first to shake out the bugs in what is traditionally a complex and parameter-sensitive application. The core financial systems of an ERP can also be phased in first before everything else.

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.

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

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.

You’ve seen it before – how projects gain institutional momentum even though the hard reasons for it aren’t clear.

An expensive multi-year project is hatched from the need for some level of management somewhere, to “move the enterprise forward” by technology-enabling new and improved processes.

Ideas – the seeds of projects — have a way of gaining momentum without the right level of rigorous questioning and unbiased analysis. Notice how a project, slim as the specifics might be, gets an impressive name, such as Phoenix, Gemini or Athena, and then almost automatically has credence as a legitimate, important initiative that must be done. Once the project gains notoriety in this way, there is a bias to produce something from it, and often that bias to do something ends up being the purchase of a new system or systems.

Years ago I worked for a company that announced a project to “transform” the company chiefly by “integrating” different departments; we’ll call this project Excalibur. A team was formed, made up of the best and brightest, from a cross-section of functional departments. A lot of full-day meetings were held.

I wasn’t involved in Excalibur, yet, so I didn’t know what the meetings were about. But I do know that the first thing — no, make that the only thing — the Excalibur team set out to do was to evaluate packaged software solutions…for what, it wasn’t immediately clear. But it occurred to me that the team was completely bypassing important steps, like stating a problem and business goals, identifying broken processes or dysfunctional parts of the organization, and defining a desired future state.

Epilogue: the project took nearly five years to complete, and resulted in replacement of four legacy applications with a new, interconnected ERP system. Two years after the completion of Excalibur, a new project was launched to replace everything with another ERP system.  I don’t know how much was spent on Excalibur, but we had a lot of consultants around for four or five years, and they weren’t free.

Yes, there must be a peculiar psychology to the decisions leading to projects that cost a lot of money but don’t produce results.  Maybe it’s just a reflection of human nature: wanting to be part of something big, visible, and important.  That’s risky though, if you look at the percentage likelihood of pure success of large IT projects based on studies to date, and if you plan on telling the truth when it comes to evaluating success at the end.

Recognizing that your enterprise might be in this situation – drinking the Kool-Aid, as it were – is a good first step toward avoiding the ensuing money pit.

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.

Studies over the past 15 years show enterprise software project failure rates ranging between one-third and two-thirds. Failure is defined in various ways – over budget, taking much longer than planned to implement, causing major business disruptions, or simply abandoned. 

The OASIG Study

OASIG, an organizational management group in the UK, commissioned a study in 1995 that involved interviews with 45 experts in management and business who had extensive experience with information technology projects either as consultants or researchers. The in-depth interviews revealed a dismal 20%-30% success rates for IT projects, and the reasons cited for the overall poor track record were:

• Failing to recognize the human and organizational aspects of IT;
• Weak project management; and
• Unclear identification of user requirements. 

The Chaos Report

The Standish Group is a research and advisory firm that in 1995 published The Chaos Report, which found

• Only about 15% of IT projects were completed on time and on budget;
• Thirty-one percent of all projects were canceled before completion;
• Projects completed by the largest American companies had only about 42% of the originally proposed features and functions.

The firm extrapolated the results to estimate that in 1995, eighty thousand projects were canceled, representing approximately $81 billion in wasted spending. 

The KPMG Canada Survey

In 1997 accounting firm KPMG studied why IT projects fail. The top reasons were:

• Weak project management, including insufficient attention to risk management;
• Questionable business case for the project;
• Inadequate support and buy-in from top management. 

The Conference Board Survey

In 2001 The Conference Board surveyed 117 companies that had started or completed ERP software projects. The results showed that:

• Forty percent of the initiatives did not produce the expected benefits within a year of completion;
• On average respondents reported spending 25% more than expected on the implementation and 20% more on annual support costs;
• Only one-third of the respondents said they were satisfied with their results. 

The Robbins-Gioia Survey

In 2001, management consulting firm Robbins-Gioia queried 232 companies across a range of industries about their IT investments, particularly investments in ERP systems. Of the companies that already had an ERP system in place or were in the process of implementing one:

• Fifty-one percent said the implementation of the new system was unsuccessful; and
• Forty-six percent said they believed their organization didn’t know how to use the ERP system to improve business results.

My take on these studies is this: Projects fail for many different reasons, but nearly all of those reasons can be tied back to human factors. The likelihood of success is directly correlated to the decisions you make, the strength of your project team, the way they manage the project, the way you manage the team, and particularly the strength of your project manager (PM).

So many business people (you!) don’t understand why it’s so hard to just get new software to make things happen in a business.

The short answer is: software will do only exactly what you tell it to do, and no more.

By way of illustration, if you could talk to software, a conversation about just one of many business processes might go something like this:

You: “We’re ready to set up the new system to process sales orders.”

Software: “OK. First thing you need to do is upload into my database all of your customers, and all of the products they buy.”

You: “That’ll be easy. I already have a list of customers and products ready.”

Software: “I’ll need to know customer names, addresses, what products they can buy, at what prices, what channel of business they are in, which sales rep gets credit for the sale, whether any commissions are to be calculated and paid to a broker, how to calculate the commissions, where to put that amount so that the broker gets paid, how you want me to pay the broker – check, EFT or other? – the customer’s hours of receiving, their fax and telephone numbers, who to contact with questions, whether you ship to them or they pick up their order, whether they get any discounts and if so for which products, under what conditions, how to calculate the discount and how to categorize the discount whether it is a sales promotion, customer loyalty discount, order size discount, or something else, their credit limits, banking information, tax ID number, how their orders are to be packaged, what the lead time will be from receipt of order to shipping, which warehouse should ship their order, whether sales taxes apply to their purchases, whether customs duties are to be paid, whether I should check their order for errors, what I should check, what constitutes an error, and what to do if I do find an error, whether you want me to send an order acknowledgment back to the customer, where I should send the acknowledgment, how you want me to send it, and how the acknowledgment should look, what information it should have on it, whether you want to be able to print a copy of the sales order, acknowledgment and invoice, how you want the invoice amount to be calculated, how you want the invoice to look and where and how you want it to be sent, what account you want me to post their invoice amount to as sales revenue, how long the customer has to pay the invoice, and for products I will need…”

You: “Wait, what? We don’t need half that stuff!”

Software: “Well, I do, if you want me to process your sales orders accurately.”

You: “But this is going to take forever!”

Software: “Not my problem. It should only take you a few weeks to get your customer data together in an upload file.”

You: “A few weeks just to load customer data?! We’re supposed to have this whole project done in about six months!”

Software: “Ha! What genius came up with that? The project should take about a year, maybe more. Now get going and get me your customer and product data, and make sure it’s perfect, because if it isn’t I won’t let it load into my database…”

Get it?  We don’t have a magic bullet yet so your only option is to slog through all the details, get your best people assigned to the project, make sure your data is pristine, allow lots of time for testing, and have a manual backup plan for when you cut over to the new system.