Executive Interview: Senior Vice President of Marketing for Stratus Technologies, Jim Gargan

The Standish Group interviewed Jim Gargan, Senior Vice President of Marketing, Stratus Technologies, Inc. Maynard, Massachusetts. Here are the results of the interview:

Standish:

Tell us about yourself.

Gargan:

I joined Stratus six months ago after spending the last five years at IBM, where I headed up the high volume Intel server business. Prior to that I worked at Digital for about 13 years.

Standish:

Why do you think Stratus will gain success in the server market?

Gargan:

One of the interesting things with Stratus is the technology and how it fits with a number of trends in the marketplace. More and more customers and IT Managers are looking at applications that traditionally hadn't been considered mission-critical but are now becoming mission-critical. Things like mail and messaging, file and print. Basic infrastructure type applications becoming 24/7 is the number one big trend.

Big trend number two is that IT Managers have less budget to spend each year. Over the last two years we've seen a contraction in the amount of IT spending. Even when the economy turns around, I don't really expect to see a big boom because of pent up demand. I just think that people are going to pursue a different business style. Figure out how to do more with less. The only way they can solve the equation is to have inexpensive servers that never go down.

Standish:

You are working with two of the big giants - Microsoft and Intel. If you become successful do you run the risk of being squashed by two big elephants?

Gargan:

No, in fact I would tell you it's probably just the opposite. The success of Stratus in the marketplace is in the best interest of both of those companies. Microsoft's goal is to reverse years of perception that the Windows server platform is unreliable. So our success helps Microsoft overcome the number one objection to the Microsoft platform, which is its overall reliability.

Standish:

Where do you see Stratus in the next two to three years?

Gargan:

I believe that Stratus will grow to become a dominant player for fault-tolerance in our target markets. I also believe that fault-tolerance will continue to push more into mainstream computing in the future. The market's going to grow rapidly. We have the system range and price points to cover the spectrum.

Standish:

But that was the trap that Stratus had for a long time. They were a niche player and could never break out into general purpose computing. As a result they got more and more niche until they ran out of marketspace.

Gargan:

And that's largely due to price points. So if you look at the history, the typical price points were $250,000. We're delivering the same product availability at about an $18,000 price point. We are going to continue to push that price point down. In fact, we believe that within the next twelve months, we will be approaching the $10,000 price point.

BTW: Stratus plans to announce, next week, a new entry-level server called ftServer 3300 system. This new server will be optimized for use in 4U rack, and runs Microsoft Windows 2000. The ftServer 3300 1- to 2-way SMP server uses Intel® Xeon™ 2.4 GHz processors with Hyper-Threading. The server supports up to 3 GB of memory, 6 PCI slots and embedded Gigabit and 10/100 Ethernet, and Ultra3 Disk.

BONUS EDITORIAL

PROJECT ROI - Part XV: Risk on Requirements

Over the last two weeks we've talked about looking at features and functions and tying those to an ROI. In this installment we'd like to consider the risk of those requirements. If you recall we put requirements into three different categories: baseline, yield, and non-yield. To remind you, a baseline is a requirement and the system will just not work without it. Examples of a baseline function might be, database access or a read-a-magnetic card. Yield requirements are items from which an ROI number can be assessed. Non-yield functions are functions that are neither baseline, therefore the system can run without them, nor can they show a return.

Like tying the ROI to requirements, tying risk to this process is also a very iterative process and dynamic. First every project has risk, so you should start with a risk assessment for the project. This part is easy. Just use the VirtualADVISOR Risk Assessment Model. This will give you your project's overall probability of success. If the risk of the project is too great, you may wish to consider an alternate path or consider reducing the complexity, as well as risky behavior, as outlined in the CHAOS Chronicles.

Here is how you may wish to consider reducing the complexity. From your ROI, you already have taken each requirement and put it into the three categories. Now assign a complexity number from 1 to 10, 1 being the lowest complexity and 10 being the highest for each requirement. As Standish friend, Jim Crear would say, "Complexity Causes Confusion and Cost (4Cs) or increased risk. If the baseline requirements have all high numbers then you should consider the project at higher risk than the VirtualADVISOR's results; if they have low numbers then the risk should be lower.

Now if you decide to go forward, you should do the baseline first, so start the project off by completing the baseline. Once the baseline is completed you can implement the system or wait until some of the other items are functional. You have already ranked the requirements by the ROI, now you can re-order the requirements by risk/reward.

Start with the high yield and the lowest risk items first and work down the list. Try to eliminate low yield and high-risk requirements. As each requirement gets completed, don't forget to reassess the remaining items. By completing high yield/low risk requirements first, you increase your feature velocity. Implementing as rapidly as possible is a key to reducing risk, as well as maximizing ROI. You also gain feedback on feature relevance. Non-yield functions with a high risk should be eliminated all together. Like ROI, risk should not be a one-time or static event. It should follow the life cycle of the system.