Home

Acquiring New Technology? Why “Build-versus-Buy” is Dead

Leave a comment

Still debating the build-versus-buy decision at your organization for your IT purchases?  If so, you probably aren’t getting the biggest bang for your IT dollar: Build-versus-buy is dead.  For better decision-making when acquiring IT systems, forget build-versus-buy and remember the Technology Acquisition Grid.  You’ll not only save money, you’ll make smarter decisions for your organization long term, increasing your agility and speeding time-to-market.

In this article, I describe Software-as-a-Service (SaaS), application hosting, virtualization and cloud computing for the benefit of CEO’s, CFO’s, VP’s and other organization leaders outside of IT who often need to weigh in on the these key new technologies.  I also describe how these new approaches have changed technology acquisition for the better – from the old build-versus-buy decision, to the Technology Acquisition Grid. Along the way, you’ll learn some of the factors that will help you decide among the various options, saving your organization time and money.

The Old Model: Build-versus-Buy

When I earned my MBA in Information Systems in the mid-1990’s, more than one professor noted that the build-versus-buy decision was a critical one because it represented two often-costly and divergent paths.  In that model, the decision to “build” a new system from scratch gave the advantage of controlling the destiny of the system, including every feature and function.  In contrast, the “buy” decision to purchase a system created by a supplier (vendor) brought the benefit of reduced cost and faster delivery because the supplier built the product in advance for many companies, then shared the development costs across multiple customers.

Back then, we thought of build versus buy as an either-or decision, like an on-off switch, something like this:

Buld-versus-Buy Switch

In the end, the build-versus-buy decision was so critical because, for the most part, once you made the decision to build or buy, there was no turning back.  The costs of backpedaling were simply too high.

The Advent of Application Hosting, Virtualization, SaaS and Cloud Computing

During the 2000’s, innovations like application hosting, virtualization, software-as-a-service (SaaS) and cloud computing changed IT purchasing entirely, from traditional build-versus-buy, to a myriad of hosting and ownership options that reduce costs and speed time-to-market.  Now, instead of resembling an on-off switch, the acquisition decision started to look more like a sliding dimmer switch on a light, like this:

 

Build-versus-Buy Slider

Suddenly, there were more combinations of options, giving organizations better control of their budgets and the timeline for delivering new information systems.

What are each of these technologies and how do they affect IT purchasing?  Here’s a brief description of each:

Application Hosting

During the dot-com era, a plethora of application-service-providers (ASPs) sprung up with a new business model.  They would go out and buy used software licenses, then host the software at their own facilities, leasing the licenses to their customers on a monthly basis.   The customers of ASPs benefit from the lower cost-of-ownership and reduced strain on IT staff to maintain yet another system, while the ASPs made money by pooling licenses across customers and making use of often-idle software licenses.

While the dot-com bust put quite a few ASPs out of business, the application hosting model, where the software runs on hardware supported by a hosting company and customers pay monthly or yearly fees to use the software, still survives today.

Virtualization

One of the first technologies to change the build-versus-buy decision was virtualization. By separating the hardware from the software, virtualization separates the decision to buy from the need for new software.  In virtualization, first, computer hardware is purchased to support the organization’s overall technology needs.  Then, a self-contained version of a machine – a “virtual” machine – is installed on the hardware, along with application software, such as supply chain or human resources software, that the business needs at that point in time.

When the organization needs a new software application that is not compatible with the first application, because it runs on another operating system, they install another virtual machine and another application on the same hardware.  By doing this, the organization not only delivers software applications more quickly because it doesn’t need to buy, install and configure hardware for every application, the organization also spends less on hardware, because it can add virtual machines to take advantage of unused processing power on the hardware.

Even better, virtual machines can be moved from one piece of hardware to another relatively easily, so like a hermit crab outgrowing its shell, applications can be moved to new hardware in hours or days instead of weeks or months.

Software-as-a-Service (SaaS)

Like virtualization, Software-as-a-Service, or SaaS, reduces the costs and time required to deliver new software applications.  In the most common approach to SaaS, the customer pays a monthly subscription fee to the software supplier based on the number of users on the customer’s staff during a given month.  As an added twist, the supplier hosts the software at their facilities, providing hardware and technical support, all within the monthly fee.  So, as long as a reliable Internet connection can be maintained between the customer and the SaaS supplier, the cost and effort to support and maintain the system are minimal.  The customer spends few resources and worries little about the software (assuming the SaaS supplier holds their side of the bargain), enabling the organization to focus on serving it’s own customers, instead of on information technology.

Cloud Computing

The most recent technology innovation among the three, cloud computing brings together the best qualities of virtualization and SaaS.  Like SaaS, with cloud computing both hardware and software are hosted by the supplier.  However, where the SaaS model is limited to a single supplier’s application, cloud computing uses virtual machines to host many different applications with one (or a few) suppliers.  Using this approach, the software can be owned by the customer, but hosted and maintained by the supplier.  When the customer needs to accommodate more users, the supplier sells the customer more resources and more licenses “on demand”.  Depending upon the terms of the contract, either the customer’s IT staff maintains the hardware, or the supplier.  In addition, in most cases, the customer can customize the software for their own needs, to better represent the needs of their own customers.

Adding Application Hosting, Virtualization and Cloud-Computing to the Mix – The Technology Acquisition Grid

Remember the dimmer switch I showed a few moments ago?  With the addition of application hosting, virtualization, SaaS and cloud computing to the mix, it’s not only possible to choose who owns and controls the future of the software, it’s also possible to decide who hosts the software and hardware – in-house or hosted with a supplier, as well as how easily it can be transferred from one environment to another.  That is, it’s now a true grid, with build-to-buy on the left-right axis, and in-house-to-hosted on the up-down axis.  The diagram below shows the Technology Acquisition Grid, with the four main combinations of options to consider then acquiring technology.

Technology Acquisition Grid

 

Here’s where application hosting, SaaS, virtualization and cloud computing fit into the Technology Acquisition Grid:

Technology Acquisition Grid with New Technologies

 

Making a Decision to Host, Virtualize, go SaaS, or seek the Cloud

If the rules of the game have now changed so much, how do we make the decision to use virtualization, application hosting, SaaS or cloud computing, as opposed to traditional build and buy?  There seem to be a few key factors that drive the decision.

At the most basic level, it comes down to how much control – and responsibility — your organization wants over the development of the software and the maintenance of the system.  Choose an option in the top-left of the Technology Acquisition Grid, and you have greater control of everything; choose an option at the bottom-right, and you have far less control and far less responsibility for the system.

In my own experience advising clients during technology acquisition and leading technology initiatives, decision-makers tend to choose a “control everything” solution because it’s the easiest to understand and poses the least risk.   While this may, in the end, be the best answer, organizations should weigh the other options, as well.  Certainly, more control usually sounds really good, but it almost always comes along with much higher costs, as well as delaying use of the system by months.  Particularly for smaller organizations,  which probably need those IT dollars to serve their own customers more effectively, a “control everything” answer is often the wrong decision.

Which should your organization choose?  Start by making an effort to include software products that take advantage of hosting, virtualization, SaaS and cloud computing among your choices when you start your search.  Then, weigh the benefits and downsides of each option and combination of options, choosing the one that balances cost and time-to-market with your own customer’s needs and your tolerance for risk. A good consulting company like Cedar Point Consulting can help you do this, as can your organization’s IT leadership.  Using this approach, you’re sure to free yourself from the old rules of build-versus-buy, delivering more for your own customers at a much lower cost.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in technology strategy, project management and process improvement. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

 

For Successful Business Leaders, Sometimes it’s Right to be Wrong

Leave a comment

One dreary October day in the late 90’s, I sat in my local Fidelity office waiting to shift funds from one account to another, a common practice in an era before online banking and financial services. That fifteen minutes sitting would have remained forever unmemorable, were it not for the fact that I picked up a business magazine sitting on the coffee table next to me and read a brief article on CEO’s and decision-making.

According to the article, researchers studied the decision-making of CEO’s at both successful and unsuccessful businesses, categorizing their strategic decisions along two dimensions — correct/incorrect and fast/slow, as shown in the table below:

CEO Decision-Making Success Fast Slow
Correct    
Incorrect    

As you might surmise from the labels on the table, “correct” was defined as making decisions that accurately gauged the market, adapted to changes in the business environment, and made new expenditures or trimmed costs in ways that helped their businesses to out-perform competitors; “incorrect” decisions were the opposite.  Along the other dimension, “fast” decision-makers were among the first to make a decision–right or wrong–and then act on the decision, while slow decision-makers took their time, often deciding and acting well after the counterparts in their industry.

Not surprisingly, the CEO’s who made fast, correct decisions led the most successful businesses, while the CEO’s who made slow, incorrect decisions were the least successful. However, the second most successful group of CEO’s came as quite a surprise to me, ultimately affecting how I lead and make decisions to this day. It turns out that the second-most successful CEO’s made fast-but-wrong decisions — not the CEO’s who made slow-but-correct ones. The completed table below summarizes this:

CEO Decision-Making Success Fast Slow
Correct 1stMost successful CEO’s 3rdThird-most successful CEO’s
Incorrect 2ndNext most successful CEO’s 4thLeast successful CEO’s

Why were fast-but-incorrect CEO’s the second most successful group? It turns out the slow-moving-yet-correct CEO’s were simply too slow to take advantage of changing business landscape. They waited too long, letting good opportunities slip by and causing their businesses to under-perform. However, the fast-yet-incorrect CEO’s did something that was really not very difficult–they monitored the results of their decisions and, when they determined they were wrong, they corrected their mistakes.

All of this makes thorough, complete analysis and extreme caution – even in the worst of business climates — look like a pretty bad decision-making model.  Sure, we should base our decisions on facts, research and data, weighing the options along with our trusted advisers. But, we shouldn’t wait until the last piece of information finally makes its way to our desk, assuming that having a complete picture is the only way to certain success.  Because if we do, we’ll probably be too late.

(If you’ve read my previous articles, you’ll notice that I’m pretty thorough about citing material appropriately. The article to which I refer needs an appropriate reference, but while I’ve looked and looked, I simply can’t find the original article, published in either Fast Company or Inc Magazine between 1996 and 1998.  Certainly, the publisher and the researchers deserve the credit, so if you know of this article, send me an e-mail and I’ll give credit where it’s due).

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

Watch that Basket-Seven Ways to Identify Troubled Projects

Leave a comment

Though the traditional advice is “don’t put all of your eggs in one basket,” the celebrated author Mark Twain is famous for saying, “…put all of your eggs in one basket and — WATCH THAT BASKET.”

Whether you’re a an entrepreneur leading a small business , a C-Level executive (CEO/CFO/CIO/CTO) at a mid-sized business, the head of the Project Management Office (PMO), or a business manager watching out for your department, you are often stuck in the position of having to “watch that basket” with your most critical projects.

Even worse, many times you’re never truly sure if one of your key projects is in trouble until it’s too late.

Fortunately, there are some signs that can help you identify a troubled project early, so that you can intervene and put it back on track. I polled our project recovery services specialists at Cedar Point Consulting, and we thought of seven effective ways to identify a troubled project:

  1. Perpetual Green Lights, Little Activity. Many of us are familiar with the approach of labeling projects green when they are on schedule and budget; yellow when the project is falling behind; and red when the project is far behind and/or over-budget. Perhaps your key project has been reporting green for the last three months, but oddly there’s been very little activity related to the project. This is probably a good signal that the project is actually in trouble.
  2. Lot’s of TBD’s. Effective risk and issue management are critical to the success of most projects, yet they are often ignored. If your key project is well past the early stages, but is reporting back a lot of TBD’s (to be determined) in the “resolution” column for risks and issues, then it’s probably a troubled project, even when the schedule doesn’t show it.
  3. Avoiders. The leader in charge of your key project may be a formal project manager or a manager of a business line, but regardless of who they are, you are getting the unsettling feeling that they are avoiding you. Perhaps they are missing at meetings, they’re head the other way down the hall when they see you, they’re not returning phone calls, or they’re not providing status reports. Unless you have a problem bathing, the project leader is likely avoiding you because the project is in trouble.
  4. Troubling Trends. Experienced project managers are familiar in using techniques like earned value management (EVM) to identify project progress by comparing actual to planned results for work completed, costs incurred and time spent. Though you may not be using EVM on your projects, you can watch for dramatic increases or drops in spending, dramatic changes to the work being delivered or sudden changes to schedule with no new schedule dates. In many cases, your key project is in a free-fall.
  5. Non-Progress Reports. You’re wise, so you have asked your project manager to provide status reports on a weekly basis. However, they’re more like “Non-Progress” reports than progress reports because no progress has been made. In particular, if you have received two weekly status reports where no progress has been made, you’re well on your way to having a troubled project on your hands, if you don’t already.
  6. Inability to Show Tangible Results. Well in to your project timeline and knowing that interim reviews are a good idea, you ask for a review or demonstration of work completed thus far. However, your review meeting is repeatedly delayed and rescheduled, sometimes by a few days and sometimes by weeks. Even worse, you’ve tried a quick visit by the desk of the project leader and it resulted in the person shoving documents in their desk instead of sitting with you to review tangible results. If so, this is likely a troubled project.
  7. Spidey Senses Tingling. Like Peter Parker in the Spiderman comic book series, you know which projects are highest risk and every time the subject of your key project comes up, it sets your spidey senses tingling, though you’re not certain why. While I’m a big believer in science over emotion, there is surely something very scientific that you’re reading so trust your instincts. Your likely to find something amazingly like trouble in your key project.

Of course, identifying a troubled project is one thing, but recovering that project is a completely different challenge. I provided some tips to recover troubled projects in a previous article that may be of help.

However, particularly if you don’t have experience recovering troubled projects and the stakes are high, it might be time to consider getting some help.  Our firm provides project recovery services and we’re proud of our success rate, but other competent firms do, as well.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

%d bloggers like this: