5 greatest myths at start of tech rollouts

The first third of a technology project is by far the most critical. Decisions and groundwork laid here will impact the rest of your project. In many cases, it can be impossible to reverse a project’s early direction once it’s established.

Here are the five most prevalent myths that impact a project’s first third.

Myth 1: You can reach consensus on technology choice

Do you choose Adobe or Microsoft? Salesforce or another customer database? WordPress or Drupal?

Business people confronting these early questions often think that they will put everyone in a room, explore the information, and come to a mutually agreed-upon decision.

The truth: That never happens.

Technology-decision meetings invariably devolve into “red-state-blue-state” factions, with technologists hurling jargon at one another.

Often, the business stakeholders simply cave to the preference of the technologist with the loudest voice or the most senior title.

Don’t make this mistake. Technology choice is critical to a business’ strategy. Adhere to this critical rule.

Rule: Technologists recommend. Business leaders decide.

Following this rule ensures that business stakeholders remain in the driver’s seat when it comes to company strategy.

Learn more and hear a case study on Myth 1 in this 7-minute video.

Myth 2: Off-the-shelf (OTS) software saves time and money

 We all agree this should work. Using a piece of pre-built software should result in a quicker and cheaper development initiative.

So why is it so often the case that companies are disappointed in their off-the-shelf solutions? Why does off-the-shelf so frequently take more time and cost more with a less desirable result?

One key reason: Counterintuitively, off-the-shelf software solutions require more up-front discovery compared to a custom-development route.

When you are in the middle of a project programming a custom solution, you are actually more nimble. You can turn on a dime. In an off-the-shelf package, you are locked in to what the software wants to do.

At this point, if you discover the software is missing some key feature, you now must engage in a costly customization of the packaged software.

Make sure to carefully vet your requirements against the features and functions of the packaged software, taking as much time, or even more, in discovery than you would if you were pursuing a custom solution.

Hear more about Myth 2 and listen to a case study in this 4-minute video. 

Myth 3: You can save time and money with an internal team

Often, companies make the staff-vs.-outsource decision in a bean-counting way. They look at a quote from an external vendor. Then they look at the salaries and benefits that would be required with an internal team. Often, the internal-staffing route looks cheaper.

This bean-counting misses a key factor in the decision to in-source or outsource.

Technology folks generally fall into two types. There are the “Project Types” and the “Steady-State Types.”

You have to decide which you are going to hire. There is very little crossover.

• Project Types love the thrill of project launches, and they are good at it.

They are familiar with the hair-raising times around “go-live” and are accustomed to staying up until 1 a.m. putting out fires. Project types are most often found at agencies or development shops. To keep them interested, a steady stream of new projects is required.

• Steady-State Types prefer maintaining an existing software system.

They like to develop deep expertise in a system. For these types, “new development” means creating enhancements for the system. These folks are most often found in-house.

If your company is going to do one major project every three years, then you would be better to hire an external team full of “project types” until your one big initiative is complete. After, you can consider a “steady state type” to maintain the system. You can also decide to outsource the maintenance.

If your company has an ongoing stream of development, you are able to hire an internal team of “project types.” You can also decide to establish a good long-term relationship with a development shop.

Keep the tech-personalities in mind, and leave the bean counting aside when it comes to the decision of insourcing or outsourcing.

More about this topic in a 3-minute video on Myth 3.

Myth 4: Accurate budgeting is impossible

You can know the accuracy of your software budget—as long as you know how the budget was arrived at.

There are four types of budgeting:

1. Comparative

2. Bottom-up

3. Top down

4. Blends

• Comparative budgeting is when you have a recently completed project that you can use as a comparison for the new project. You look at what that project cost and use it as the basis for your budget.

• Bottom-up budgeting, also known as classic waterfall budgeting, happens when you can develop a very detailed list of features and estimate them one by one.

• Top-down is the opposite of bottom-up. It is when the project is sized more conceptually, or using “big buckets.”

Top-down budgeting often happens when it’s impractical or impossible to develop a detailed list of features, such as in a project that involves considerable innovation or with one that is very large.

• Blends, of course, is when your budget involves some of each.

Comparative and bottom-up are the most accurate budgeting methods. Top-down the least.

Now the ugly truth: Most business leaders have no idea how their budget was developed.

If it is blended, they don’t know the percentages of each method. Therefore, they are often surprised when a budget is blown.

Question your teams about how they are developing budgets and you will know how accurate yours is. You can set aside contingencies for the less accurate parts of your budget.

More on this topic as well as some additional keys to accurate budgeting in this 8-minute video on Myth 4.

Myth 5: When all else fails, trust your gut

Guts are notoriously unreliable in software development. This is because the emotions of the business often start in a highly euphoric state. Business stakeholders theorize and dream about what the software will do and how it will transform the business.

Then, in the Alpha state, they come crashing down to earth, entering a phase of extreme and equally unrealistic disappointment.

I call this the Trough of FUD—Fear, Uncertainty, and Doubt.

The roller-coaster emotions of a software project cannot be trusted as your guide.

Learn more about software-project emotions, and see a narration of the Trough of FUD, in this 4-minute video on Myth 5.

Read a review of The Complete Software Manager by blogger Dan Fisher