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.

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