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.

In the time is takes to purchase and implement a company’s software systems, an infant can become a first grader. Degrees can be earned. And a lot of money can be spent. This is one more reason why people find software so maddening.

The classic ERP implementation, which many companies dove into in the 1990s, is a huge endeavor that can last years for even the most tech-savvy companies. As Cynthia Rettig wrote in an October 2007 MIT Sloan Management Review article, ERP systems are “massive programs, with millions of lines of code, thousands of installation options and countless interrelated pieces….they introduce so many complex, difficult technical and business issues that just making it to the finish line with one’s shirt on is considered a win.”

More often than not, studies have found that the original scope is not achieved, and it may take years to optimize the solution so that it delivers real value.

Lengthy implementations have become a sore point for software buyers. Companies and governments often see large software projects as a nuisance. There has been a backlash against the big, interconnected, and costly-to- implement applications. Executives no longer readily accept big dedicated teams working on a project.

A few years ago, you may have seen the cartoonish billboards that say “Down with big ERP.” The ads are part of a campaign begun in 2009 by, ironically, one of the largest ERP software companies, Infor. Sensing the negative turn against large software implementations, the company sought to differentiate itself from its large competitors SAP and Oracle.

In launching the campaign in November 2009, Infor’s then-CEO Jim Schaper said: “Obviously our industry hasn’t done the greatest job serving their customers. Software implementations have become disruptive. They’ve become known for over-budget and seemingly never-ending implementations, increasing maintenance costs every year, and forcing customers to upgrade or exchange software when it wasn’t advantageous or economical to do so. In many cases, the ‘software experience’ has been anything but a good experience.”

Why does it take so long? Software is the result of converting information – human thought — into computer instructions. The “information” could be as simple as a mathematical formula, or as complex as the mind’s sequential thoughts and logic. Much of the time is spent understanding what the user wants and how to convert it into business rules that a computer can apply. Large blocks of time are also spent testing the software code to make sure it does what it was intended to do.

Another reason that projects take so long is that the software must fit hand-in-glove to your business process. Remember, the software knows nothing about your business. It is told by its lines of code to perform certain calculations and transactions using data you provide.

So in a sense, you are building a bridge.  On one side is what your enterprise knows about its processes, data, and transactions.  On the other side is software code — some of it is ready to take what you have and run with it, some of it is at odds with or irrelevant to your needs.  Success will depend on maximizing the former and minimizing the latter.

You need to understand the way software firms, consultants and advisory services interact with one another.

In the process of thoroughly confusing yourself trying to scan the software market for something resembling a solution to your problem, you will at some point realize that there aren’t many places to go for an objective appraisal of applications or vendors.

That’s because, in my view, all the players in the software market — the firms themselves, consulting companies, advisory services, user groups, associations and conference organizations, and hardware and network providers — act in a way that is (shocking!) mostly designed to perpetuate and increase spending on software and related products and services.

Yes, firms strive to be competitive and earn your business, and will tell you why their solutions are better than others. But few players in the software market — even subscription advisory services — will solidly endorse or, alternately, steer you clear of, a particular software or consulting organization or its products and services.

[pullquote]There’s just very little clear-cut information to be had. Advisory firms don’t want to dismiss anyone because they rely on all players to provide them information, buy their services, and attend their conferences.[/pullquote] IBM Consulting Services is not going to advise you that SAP or Oracle would be a terrible choice — their consulting revenues depend on a stream of projects implementing those same applications.

There are several well-respected organizations providing in-depth research and advisory services related to the entire IT industry. Their services and publications are indeed excellent, thorough and detailed, but only directionally conclusive and even then in a rather general and not exactly plain-spoken way, and accompanied by caveats.

Consider this summary statement from one such respected research firm, in a publication reviewing software for analyzing product assortment: “Use DemandTec if optimizing your assortment in a collaborative retailer and manufacturer environment, the ability to leverage localized incrementality and demand transfer analytics or leveraging your shopper insights is a key priority for your company.” Got it?

Adding to the noise are industry associations and a slew of online newsletters that seem to multiply over time…there’s CIO Magazine, CIO Research, IT Whitepapers, IT Whitepapers Business Intelligence, Enterprise Business Alert, Business Management Alert, Mobile Alert, Networking Alert, InfoWorld, Supply Chain Technology Bulletin, BI Technology Bulletin, and on and on…a flood of information, discussion, interviews, blogs, announcements, conference invitations and webinars.

All of it contributes to a general feeling of being in the woods, having no idea what the forest looks like. But one thing is sure: every topic is urgently important and deserving of weighty consideration equal to that given the most pressing and critical questions of our time.

Now hitting your inbox: “New survey – High performance analytics: Are you ready?” and “7 Best Practices for Developing in the Hybrid Cloud.” These digital marketing efforts are fueled by advertising for IT products and services — again, the self-perpetuating nature of the market.

It’s marketing, OK?  Just view it as that.  As I’ve said before, change the conversation.  Ask questions that come from deep within your understanding of your own situation and business, and insist that your vendor speak to those needs.

Software vendors have lots of value to offer.  Most are selling valuable solutions.  There is an intersection between your needs and the software; that is what you need to find, and understand completely.

Two years ago I began exploring “cloud” software for integrating our company with its trading partners. This is how one company explains the benefits of its cloud software solution:

“Cloud supply chain platforms invert the traditional EDI (Electronic Data Interchange) hub equation by moving the data processing and linking logic from the partners at the ends of the spokes to the center hub itself. In this model, the entire value chain community leverages a common core technology utility so that all partners link to a single version of supply chain truth across the entire network.”

Here you have conceptual-speak, what sounds like preamble, and lots of jargon made to sound sensible (who can resist “a single version of supply chain truth across the entire network”?). In the section that is supposed to answer “what is this technology made of?” I come across this explanation:

“First, importantly, it is technology designed for the deep and detailed processes of a specific B2B domain. It is not generic. In this respect it diverges sharply from traditional EDI technologies that were designed for file transport and translation across all processes. Traditional systems take a “one size fits all” to information exchange: EDI file delivery for everyone, but a complete picture for no one.”

There’s more:

“In rich process domains such as supply chain execution, where the processes are long-lived and highly collaborative, what is needed is an information transformation layer that is knitted to the specific business processes at hand. Only by understanding the underlying and highly detailed data models and linkages of the critical business objects themselves can an information exchange platform create tight mappings to process. If an EDI VAN (Value Added Network) transports file packets, but is blind to the contents, the next generation platform interprets at the content level — it applies technology to the inside of the packet, in other words.”

None of this made sense to me, so I met with the firm’s representatives.

What they mean, as it turns out, is that their cloud software acts like a big private Facebook page, where your partners post data and transactions, as compared to traditional EDI, which is like passing a message to your partners in a straw where only you and they can see what’s in the straw.

One of the best ways to start a constructive conversation with a vendor is to say, “Ok I’m stupid. Connect the dots for me. You can link me to my trading partners like we’re all on Facebook. So what? Do I get rid of my EDI? What does that save me? Do I reduce inventories and order lead times? Will my customers and suppliers love me for doing this and will they partner with me on this approach?”

If a software vendor is good, that firm will assess your business situation first – your operation and processes – before trying to sell you anything.

So to handle the FUD experience you have to break the spell.  Be the spoiler in the room who is not going along with the feel-good lingo emanating from the vendor.

Software is like no other product on earth – it is a collection of millions of lines of instructions telling a computer what to do. You can’t “see” software; reading the lines of code would tell you nothing unless you had written the code yourself, and even programmers themselves can easily forget what they did. You must imagine software, and are left to rely on what the software’s creators say about it.

That good software is indispensable goes back to one of the first-ever software projects: an effort in the early 1950s to link together data from radars along the Eastern seaboard that were monitoring possible air and seaborne threats to the United States. Software, it was discovered, could collect, compare and plot radar data on paper much faster than human beings could.

But from software’s early beginnings as an industry in the 1950s and 1960s, business managers have struggled to understand the systems they buy, and the people and firms that market them.

In his excellent history of the software industry, Martin Campbell-Kelly describes the origins of software programming in the 1950s: “Only weeks after the first prototype laboratory computers sprang to life, it became clear that programs had a life of their own – they would take weeks or months to shake down, and they would forever need improvement and modification in response to the demands of a changing environment.” Some things haven’t changed.

Mr. Campbell also describes what must be one of the earliest maddening software experiences. General Electric had purchased a Univac computer in 1954, but it took “nearly 2 years to get a set of basic accounting applications working satisfactorily, one entire programming group having been fired in the process. As a result, the whole area of automated business computing, and Univac especially, had become very questionable in the eyes of many businessmen.”

We are 60 years into the commercial software industry, and while applications have become much more powerful, they are still prone to failure.  Large projects still fail at a high level, and the sums spent are much greater than 60 years ago.

So the challenge remains: not to build more powerful or smarter applications, but to build and integrate software into an enterprise in a predictable, reliable and cost-sensible way.

You’re a busy Director or VP responsible for an equally busy key department within a large enterprise, and on your plate rests the success or failure of a project to integrate new systems into your business processes.  You’re the accidental person-in-charge.  You didn’t ask for it, or maybe you did, but in any case you can’t give it a lot of your attention; that’s why you have a project team.

So what are the most important things for you to ask your project team?

Before you commit to a software vendor

What does the business need and what does the software provide?  Are the differences, and the resolution thereof between those two, documented and well understood?

• With the best option out there, what is still missing and how will I fix that? Does it solve my problems and give me the ROI I expect?

After project launch and for the duration of the project:

• Does the software test out the way we expected? Do users understand how to use it? If the answer is no, you have more work to do – determine why and fix it; otherwise you aren’t ready for Go Live.

Before the switch over to the new system, ask:

• Have we planned in detail for the Go Live, including what we’ll do if things go wrong? Same thing applies here – if the answer is no, or even if you sense people are glossing over problems or making excuses for not being ready, you really are not ready and therefore risk the business disruption that can turn into a disaster.