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.

Never mind how many people you can get to work on your enterprise software project team. The critical factor today is how much of their focused attention you can get when you need it.

Quoting columnist and Guinness record holder for Highest IQ Marilyn vos Savant, “Working in an office with an array of electronic devices is like trying to get something done at home with half a dozen small children around. The calls for attention are constant.”

It is not easy to get people to pay attention. Your project is competing for share of mind with texts, email and the internet emanating non-stop from your team’s cell phones.

Thomas Davenport and John Beck, in their book The Attention Economy, state: “The ability to prioritize information, to focus and reflect on it, and to exclude extraneous data will be at least as important as acquiring it.”

In 2005, I was on a team whose mission it was to modify parts of SAP to enable the sale and invoicing of what are called “kits.” A kit in software parlance is a product whose components include other products. The final product is what is recorded as the sale and what appears on the customer invoice. Sounds simple, right?

We worked in a global company. The team participants were in Ohio, New York, Western Europe, The Philippines, India, and Texas. After 14 months the team had finally gotten to the point at which it could test the solution. There had been more than 25 full-team conference calls, but no face-to-face meetings in which everyone – business people, developers, and technical experts – was present.

Why did it take so long? Attention deficit: People in remote locations for whom this project was one of many, and whose interaction with the substance of it was via impersonal conference calls during which multi-tasking naturally diverted one’s attention.

Do you know anyone who does not multi-task during a conference call? The attention deficit is automatic. People are caught not listening. Participants tend to speak a lot less than if the meeting is held face to face. It’s easy to hide and withdraw on a conference call.

We pride ourselves for the ability to work virtually across continents, have meetings anytime anywhere, and send work around the globe as if we were passing it across the table. But I think we’ve diluted our effectiveness and the quality of our output. We split our minds into more and more slices, marveling at our ability to manage so many things at once, but all we are doing is giving cursory attention to a lot of things instead of focused energy on a few.

Who needs a methodology?  Just do it.  Photo: Spring 2013 Hackathon at Columbia University, where participants were challenged to build — over a weekend —  software programs for New York City startups; by Matylda Czarnecka, hackNY.org, CC license.

You’re about to launch a big ERP project.

You need a structured methodology.  The lazy/easy thing to do is to use the one your software vendor or consulting partner uses.  Don’t automatically accept this.  Understand first how their methodology works (it’s usually designed to maximize billable hours).  Then use common sense.

A methodology is simply a way of doing things. A methodology for doing laundry could be: 1) separate colors from whites; 2) wash whites in hot water/cold rinse with bleach; 3) wash colors in cold water; 4) hang dry delicate fabrics and put everything else in the dryer on medium heat for 30 minutes.

But there can be variations in laundry methodology depending on preferences and beliefs, such as 1) throw colors and whites together in a cold wash and cold rinse so colors don’t run; 2) throw everything in the dryer on delicate cycle; 3) check periodically for dryness; and 4) pull out anything that seems dry.

IT project methodologies are practically an industry – templates, software, books, training programs and consulting engagements.

The “waterfall methodology” used in Microsoft Project and adhered to for decades by many in the project management field is arguably flawed from the beginning, at least according to some. This methodology assumes that task completion is a function of the number of man-hours, total time duration, and dependency on completion of one or more preceding tasks. Viewed on a chart, the timeline of the project looks like waterfalls cascading from left to right, top to bottom, as time progresses.

Frederick Brooks, the computing legend who pioneered IBM’s System/360 mainframe computers launched between 1965 and 1978, says in his seminal book The Mythical Man-Month that “the basic fallacy of the waterfall model is that it assumes a project goes through the process once, that the architecture is excellent and easy to use, the implementation design is sound, and the realization is fixable as testing proceeds (but) experience and ideas from each downstream part of the construction process must leap upstream, sometimes more than one stage, and affect the upstream activity.”

Brooks also says the planning process usually and mistakenly assumes that the right people will be there, available, focused and engaged, when they are needed, and that when they perform their work they will do so in a linear fashion, with no mistakes and no need to backtrack and start over. In the 21st century, this is simply not the case in many organizations.

I don’t prefer one particular methodology – I think the way to work depends on what you’re trying to achieve, by when, with whom. I also think the imposition of a particular methodology – if it doesn’t fit the project or the team – will actually detract from success.

I do like at least one part of the Scrum methodology, called a Sprint.  It could be a one week or two week “Sprint,” but the idea is the same: everyone needed for a particular stage or segment of the project is brought together and forced to stay together until their part is finished and tested.  Just get together and get it done.

Have you seen the videos where a house is built in a day?  Here is just one.  How did they do that? Lots of preparation, teamwork, intensity, focus, urgency.

The idea of a sprint in an IT project is the same: skilled people intensely focused on the same, singular objective that must be achieved within a fixed period of time.  I like it because sometimes it’s the only way to get the brains you need to complete something without the endless distractions of everyday work.  Attention deficit is rampant in organizations today — exactly the opposite of what successful enterprise software projects need to be successful.

Which methodology is best? For your project, the best methodology is the one that provides structure in a common-sense way with simple, easy-to-use tools that you think your team will, in a practical sense, actually stick to.

Photo: “Trails in the Sand,” Dubai, by Kamal Kestell, CC license

If “Humanscale” computing is managing bags of sand, “Hyperscale” computing is managing each individual grain of sand in every bag.

“Hyperscale” computing (HC) is the processing of data, messages or transactions on a scale orders of magnitude larger than traditional computing.  HC is becoming a need for many businesses.  Why?

Consider a company that sells bottled water.  Its main business used to be selling truckloads full of cases of water to big grocery chains.  It has 25 different products, or Stock Keeping Units (SKUs).  The big grocery chains then distributed cases of water to its stores, which numbered 20,000.  The data requirements for the water company’s computers was manageable, even as the company grew rapidly.

Now, the company wants to analyze the performance of its products on store shelves by measuring things like velocity (how fast the product turns), price compared to competing products, and out-of-stocks.  It’s customers — the big grocery chains — are offering to supply data from their systems on every scan of every product in every store, because they too want to improve the performance of products on the shelf.

In one month during the summer, about 3.5 billion bottles of water are sold.  A data file from just one big grocery chain runs to 3 million lines.  How and where will you process this data?  Traditional databases will be too slow.  You will need superfast databases that distribute computing to many servers — this is called in-memory, or massively parallel computing.  This is an example of hyperscale computing.

Other examples where you would need HC: selling direct to consumers through their smartphones, where you might have to process millions of transactions say, during the Christmas holiday season; gathering machine data every second to monitor a machine’s performance (a General Electric turbofan jet engine generates 5,000 data points per second, which amounts to 30 terabytes every 30 minutes); and managing millions of product-attribute combinations.

The computing tools for hyperscale will not be found in your ERP system.  Trying to engineer your existing systems to handle hyperscale data and transactions will be a costly failure.  But there are tools available on the market today, and many of them are found in cloud applications, and in application hosting providers.

Cloud application and hosting vendors usually have much larger data processing capabilities, including automatic failover and redundant servers.  You can take advantage of this capacity.  For example, you can obtain, from a leading application hosting provider, at a cost less than the monthly rent of an apartment in New York City, 30 terabytes of storage and a massively parallel computing environment.

My advice:

• Identify areas of your business that are significantly under-scaled, or where you have large gaps in business needs compared to processing capability;
• Pick one and design a pilot project (many vendors are willing to do this with you at very low cost);
• Measure results and benefits, and if beneficial, expand the solution to other parts of your business.

It’s probably not OK to ignore this trend.  Even of you don’t need HC today, think about the future and where commerce is going.  If you don’t gain the capability for hyperscale computing, one or more of your competitors probably will.

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.

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.

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.