The F-35 Joint Strike Fighter, first conceived in the mid-1990s, is a multi-purpose fighter jet that evades radar and anti-aircraft missiles, can fly at 1,200 mph, and can land vertically. While over 40 planes have been manufactured, the program is way behind schedule and the program’s costs have grown from an initial estimate of $177 billion to over $1 trillion, according to a Wall Street Journal article authored by defense industry analysts Arthur Herman and John Scott.

Herman and Scott say the Department of Defense (DOD) has identified software development (the plane’s systems run to nearly 10 million lines of source code) as one key issue behind the F-35’s problematic history, noting that the software needed for producing the plane won’t be completed until 2017.

Chances are you’re not making fighter jets with 10 million lines of code, but that doesn’t insulate you from one of the biggest mistakes of every software project: the assumptions everyone makes.

The average person assumes:

• Converting to new software is simply a matter of writing or purchasing the right application, installing it and turning it on;
• Everything will go fine as long as you have the right technical people involved;
• What the new software will do for the enterprise can be defined accurately beforehand, and it’s unlikely the new system will not perform as expected;
• The time it takes to implement a new system is predictable, and delays are unlikely

In short, there is a general presumption that the project will succeed. While it’s OK to have that positive outlook, it is more beneficial to be aware that the odds are your project – like many that have gone before – will likely run into problems, and to be well-prepared to deal with those problems.

So what should your assumptions be?

• You can’t manage every detail, so your outlook is big picture; you focus on the few things that drive success and you stay out of the weeds.
• This is a high-risk endeavor best managed by professionals; it can damage the business if not done right
• You are determined to get the ROI or the project isn’t finished.
• Your engagement with the project team is firm but supportive; you insist on structured work, discipline and facts, while doing what is needed to minimize distractions, supply the team with needed resources and eliminate barriers to their success

ROI, or Return on Investment, is essential to making the right decision about enterprise software. In simple terms, ROI is the percentage return you are realizing on the money you spent on the software.

ROI = ($ benefits per year minus additional yearly costs from the application) divided by the costs of implementing the new system.

If you spend $2 million up front for an application and another $400,000 per year to maintain it, and the benefits produced amount to $700,000 per year, the ROI would be ($700,000 minus $400,000) divided by $2 million, or 15%.

What ROI should you get from a successful system investment? That depends on your company’s strategy and overall approach to these types of projects. But I would say 30% to 40% should be a minimum. That’s because an annual rate of return in this range would “pay back” the original investment in about three years, which is about the timeframe within which better software options may exist in the market.

Payback is another way to quickly assess the relative attractiveness of a system implementation. In simple terms, payback is the number of months or years it takes for the financial benefits to “pay back” the original investment.

In the example above, the upfront cost was $2 million and the net annual savings were $300,000. So how many years would it take to pay back the $2 million? The answer is $2 million divided by $300,000, or almost seven years. Using the three year payback guideline, this particular example would be a loser.

Where do the benefits come from? Benefits don’t come from the software – but from what you do with the software. If a new system is integrated in your company but nothing else changes you will get – zero – benefits.

One example:

You are a manufacturer but you track all of your costs on spreadsheets. A shop floor application and standard costing system would show you where you are wasting money and which products cost the most to produce and why. If you know these things you can cut the waste and consider different pricing for more expensive-to-produce products.

At the very basic level, an ERP system can enable you to match invoices with receipts and purchase orders so that what you pay for is what you ordered and what you received. The purchase orders, receipts, and invoices are all in the same system, so the system can compare them and immediately determine if the invoice is valid and should be paid or if it’s not. This can eliminate overpayments or duplicate payments to vendors, reduction of paperwork and manual comparisons reducing administrative overhead.

An ERP system can also manage your contracts with vendors, including pricing and terms of payment. This means that data from invoices can be instantly compared to contractual terms to make sure the invoice is correct. The benefit is another way to eliminate overpayments. If your enterprise is large and is processing a large volume of vendor invoices you are bound to have at least a small percentage savings – say 5% of the amount you spend — and 5% of a big number may be enough to pay back at least part of the ERP investment.

A price-shopping or auctioning application or an online buying service can be an extension of the ERP system so that you can search for the best price for your materials, goods, or services, select the vendor, and place the order.

Usually these apps and web-available services are specialized according to what you are buying, such as transportation and delivery services, office supplies, basic materials such as standard corrugated packaging, shrink wrap, paper stock, chemicals and industrial supplies, and more recently energy sources such as electricity and natural gas.

The benefits here are getting the best price and terms and automatically creating a purchase order which is integrated to your financial system for proper payment. The dollar benefit can be a percentage of your total spend, especially if you think you haven’t opened up your purchasing to alternative vendors for awhile.

When purchasing is part of your ERP the proper postings to financial accounts are automatically done. When you issue a purchase order an entry is made in the ERP system that authorizes receipt of whatever you are buying. When you receive what you are buying a payable is created which goes on the balance sheet as a liability. All the accounting is taken care of, and your financial controls are in place as long as your system permissions reflect proper internal controls. This is a huge benefit for regulatory compliance and tax audits.

The F-35 Joint Strike Fighter, first conceived in the mid-1990s, is a multi-purpose fighter jet that evades radar and anti-aircraft missiles, can fly at 1,200 mph, and can land vertically. While over 40 planes have been manufactured, the program is way behind schedule and the program’s costs have grown from an initial estimate of $177 billion to over $1 trillion, according to a Wall Street Journal article authored by defense industry analysts Arthur Herman and John Scott.

Herman and Scott say the Department of Defense (DOD) has identified software development (the plane’s systems run to nearly 10 million lines of source code) as one key issue behind the F-35’s problematic history, noting that the software needed for producing the plane won’t be completed until 2017.

Chances are you’re not making fighter jets with 10 million lines of code, but that doesn’t insulate you from one of the biggest mistakes of every software project: the assumptions everyone makes.

The average person assumes:

• Converting to new software is simply a matter of writing or purchasing the right application, installing it and turning it on;
• Everything will go fine as long as you have the right technical people involved;
• What the new software will do for the enterprise can be defined accurately beforehand, and it’s unlikely the new system will not perform as expected;
• The time it takes to implement a new system is predictable, and delays are unlikely

In short, there is a general presumption that the project will succeed. While it’s OK to have that positive outlook, it is more beneficial to be aware that the odds are your project – like many that have gone before – will likely run into problems, and to be well-prepared to deal with those problems.

So what should your assumptions be?

• You can’t manage every detail, so your outlook is big picture; you focus on the few things that drive success and you stay out of the weeds.
• This is a high-risk endeavor best managed by professionals; it can damage the business if not done right
• You are determined to get the ROI or the project isn’t finished.
• Your engagement with the project team is firm but supportive; you insist on structured work, discipline and facts, while doing what is needed to minimize distractions, supply the team with needed resources and eliminate barriers to their success

Think of the typical meeting in your enterprise: people come in late, sometimes talking on a phone or otherwise distracted, and 10 or 15 minutes are spent getting into the real content of the meeting. Maybe someone asks what the meeting is about. The person who set up the meeting speaks up and may (or may not) explain what is needed from the meeting. Discussions ensue — some are on point to the reason for the meeting; others are irrelevant. Agreement is reached on a few actions and follow-ups, some people have to leave early, and the meeting breaks up.

These norms are anathema to a serious and successful software investment project, which demands rigor and, above all, structure.

Embrace Structure. You need, at a minimum:

• A work plan that is reviewed daily, with tasks, due dates and responsible owners
• System requirements, testing scenarios and future processes that are documented in detail and agreed to by all stakeholders;
• An issue resolution process to ensure that impediments to progress are eliminated;
• Commitments by team members to own and deliver key parts of the project on time;

A sense of urgency and focus are hugely important to success. In the film Apollo 13 – a great drama but also a study in focused, man-plus-technology effort and achievement, about six technicians in a conference room must assemble an air scrubber exclusively from parts that are available on board the returning spacecraft, because the main scrubber in the craft has failed, causing carbon dioxide inside the craft’s cabin to reach dangerous levels.

The astronauts will die – soon — from lack of oxygen if they cannot fix or replace the scrubber.

The technicians jump on the challenge, and produce a prototype that the Apollo 13 astronauts are able to replicate. We witness urgency and focus, and a breakthrough that saves the crew.

Can you imagine any of the technicians in that scene saying, “Hey guys, I’m good for another 10 minutes but then I’ve got another meeting”?

Well, you say, of course no one would say that; lives are at stake. True, but people skipping out of meetings is an everyday occurrence that does inhibit progress; in an IT project the lack of progress – bit by bit here and there – adds up to a late project over budget and potentially damaging to the business.

The average software project is not a moon mission, but it does require the same kind of focused and structured work that such a mission benefits from.