This month we're going to examine why customers make technology-buying decisions based on both the target technology and on their or someone else's ability to implement it. Bad software implemented by anyone is still bad software. Good software deployed by a knowledgeable team is what creates winning solutions. Good software implemented by less than the best is what can create dark scenarios that range from limited functionality to deep black holes that absorb revenue and resources into an unknown vortex.

Tale of The Ducks
Here's a quick story that demonstrates the point. One of my favorite foods is duck; my brother likes duck too, and we've both eaten duck in some great restaurants over the years. Duck is fun to eat, it's always served in an elegant fashion, and seems to be cooked just right with tender meat inside and crispy skin an the outside. Expert chefs take great pride in their ability to serve a finely crafted duck dish to their patrons.

I like to cook and fortunately I've only had a few kitchen disasters when I had to say "HmmS this didn't work out at all." My brother likes to cook too. Last month we decided that we would cook some duck for ourselves. We were sure we could cook a duck as fine as any we'd eaten in restaurants. My new high-tech gas grill was out on the deck-ready to cook its first duck. The cookbook that came with the grill says that you can cook anything on it, burgers, steaks, fish, vegetables - even duck.

This was going to be great. I purchased fresh ducks from a poultry farm, planned the rest of the meal, and was all set. We followed the recipe; we were confident in our abilities and were guided by our collective cooking instincts. We knew that the cooking process would take hours, but we were prepared. In the beginning, everything went fine; we were rendering fat out of the ducks, they were starting to cook, and we were having a good time. My brother told me stories about ducks he had cooked in a conventional oven and how wonderful they were. About halfway through we made an adjustment to the heat and everything was still going fine. Day faded into night and we stood in the dark watching those ducks. This was taking longer than we had expected and we were still waiting to eat. All we really had was a bunch of rendered duck fat. It was getting late, wives and children were growing impatient; but the ducks weren't crispy. We had to do something.

We thought about what we could do to make the ducks crispy. We huddled together and discussed various options, then came up with a plan. We decided that the meat was cooked but the skin needed to be crispy. If we increased the heat to a very high level for a short time, the skin would crisp up and we would soon be savoring duck. We increased the heat and debated how high we should go and for how long. We decided to let it go to 500º for a minute and then pull the ducks out. Unknown to us was that around 500º is the flash point of duck fat. When we opened the grill, fire raged in and around our poor ducks. The tray beneath them was a seething inferno. I grabbed the tongs and attempted to rescue them from the flames. Flaming duck fat flowed out of the body cavity and onto my deck. Disaster had befallen our ducks. There would be no crispy skin this night, only the charred remains of what should have been delicious ducks. The ducks were still edible, but only as a shadow of what they could have been. Not very good at all but hey, it was still duck.

At this point you must be wondering why I've regaled you with this sad story of ducks and fire. The moral of the story is: even if you know what you're doing, when you step out of your range of expertise and experience, you inherently create some degree of risk. This rule holds true for almost every endeavor we undertake, including large-scale IT projects.

Helping Customers Spread Their Wings
Many customers will spend countless hours planning IT rollouts only to have eleventh-hour issues crop up that threaten to scuttle everything they've worked so hard to achieve. The risk isn't increased because the deployment team isn't good or because the software is bad, but rather because they are attempting to do something new. Sometimes when we attempt something new we're fortunate to taste success on the first try; sometimes we walk away with a burnt duck.

So how do we ensure that a project planned becomes a project successfully executed? There are several methods we can employ to ensure that we get our desired results; however, the method with the highest rate of success is to include the customer in the sales process. Last month we talked about how by including the customer as part of the sales team we can minimize closing objections because the customer has been actively involved in the value proposition and in determining how ROI will be recognized. Now we have a different reason to include our customer. We need to be sure that we're not selling a product that doesn't fully address customer needs - not because the product doesn't measure up, but because the customer may not possess the needed resources to address implementation issues that could arise or those resources aren't yet ready to fully maximize the potential of the project.

As we work with a customer to understand their business objectives, part of the goal is to understand what they envision the new technology initiative will bring them and how they intend to deploy and support that technology once it's in place. This can become a strange study of human nature. Some customers will divulge trade-secret information on their business plans but really don't want you to look too deeply into how they actually run their business. They don't want you to see what they see when they look in the mirror. It's easy to say, "By expanding our marketplace and making it easier to do business with us we will grow by XX% because we deployed this technology." It's hard to say, "This is great technology that we really need, but we may be at risk because we may not have the right resources to handle this."

I've seen sales stall at this point because either the customer or the sales team didn't find a path to create success out of limitation. Sooner or later someone has to add up all the costs related to implementing a project. In the end, how closely this number resembles the numbers used in the decision process is all that matters. Part of the ROI evaluation will include a calculation of not only the foundation technology but also the deployment and support costs.

Let's say you work for a software reseller; you sell a customer at a fair price and they're happy - great. The dark cloud appears when a troubled deployment adds additional dollars to the real cost of ownership. This can stall additional business by creating a financially gun-shy customer who thinks, "Great idea, but did you look at the numbers for what it cost to implement that stuff?"

This is when the participation of the technical members of the team becomes invaluable. In most cases it will be those team members who will have the greatest insight into what the customer's true technical resources are. Once you make an assessment that the customer doesn't have adequate resources, it becomes paramount that the sales team understand that things have evolved from a base software opportunity to include a services sale as well. If the customer has a relationship with an integrator or development company, you should try to meet with them to ascertain their abilities as well. Any faults on their part will reflect on the entire project, so make sure your customer has the technical resources they're going to need. As we noted earlier, good software implemented by less than the best can lead to dark scenarios.

This doesn't mean that the customer has to break with their trusted integration/development partners. With the proper skill sets they will continue to be valuable partners.

Open Standards
How? WebSphere is built on open standards that allow application integration with tools that may already have been built. The open-standards approach is what makes WebSphere such an attractive choice for dynamic, mission-critical environments. For example, when eBay decided to migrate to WebSphere, as the architecture for its auction site, the open-standards approach was key to the decision process. Chuck Geiger at eBay explained, "There were several factors that required us to take a systemic look at the entire business. We stopped, took a breather, and asked the question: If we were to do it today, how would we do it? The solution required a different approach using a three-tier architecture to expand the business horizontally and vertically using open standards, particularly J2EE."

Open standards make it possible for customers to not only reuse tools that are already in place, but also to adopt additional tools as their business evolves. Customers aren't locked into a proprietary technology that could limit or restrict their ability to chart the IT course of their choice. This is another reason that the integration/development partner is such a critical element to the success of a project.

IBM Global Services was on site at eBay for a skills transfer and to help with the J2EE architecture. "I want IBM to teach us to fish, not fish for us," Gieger explained. "eBay is still very much in control of its technological destiny." This is a winning approach that ultimately leads to a successful implementation. It expands the sales team to include not only the customer but also the service providers that will be contributing applications, processes, and support to the initiative.

The open-standards model is one of the most powerful selling points of the WebSphere product suite. It is critical that everyone involved in the deployment understand that the adoption of the WebSphere platform opens the door to untold ways of doing business with today's technology and with tomorrow's. The legacy technology that powers the customer's business today doesn't need to be cast aside. but rather it is incorporated into the new architecture. Open standards are the ultimate COTS (commerical off-the-shelf) solution. The residual value of IT assets is something that's often overlooked in the selling process; however, it's rarely overlooked in ROI.

Learning From The Ducks
So how does this all fit together, and how does it relate to learning that sometimes it's better to order a duck in a restaurant instead of making it yourself? What does the duck have to do with WebSphere? The cooking of the ducks wasn't all that much different from planning an IT project. I knew my goal: to eat a delicious dinner. The customer knows their goal: to grow their business. I knew what I was going to make, just as a customer knows that they need to adopt a flexible, open platform. I thought I knew how I was going to accomplish the task, just as a customer often thinks they know how they're going to deploy a new technology like WebSphere.
In a nutshell, the lesson is to make the planning process part of the sales process. Take an accurate, holistic look at the customer. Understand the how, what, and why and make sure that the customer has the same fundamental understanding of these elements. Be alert; learn when to engage an IBM WebSphere Development Partner or IBM Global Services so the sales team can devise a complete solution for the customer, one that the customer is expecting because of their involvement in the sales and planning process.

Back to the duck for a second. If the man at the poultry farm had asked me, "How are you going to cook the ducks?" I would have told him I'd be using a gas grill. Perhaps he would have passed on a few tips on how to cook a duck on a gas grill. He took for granted that I knew how to cook a duck, just as we can take for granted a customer's resources to implement an IT initiative. Sure they have sophisticated IT departments that do a good job in the current comfort zones; given enough time and education they certainly could deploy the solution. However, we should always put the best, most complete, solution before the customer, and sometimes that involves proposing a service as well as an architectural solution. An experienced integration/development partner can provide the assurance of proven methodologies that have worked before. There's no substitute for experience. When eleventh-hour deployment issues crop up, and inevitably they do, that experience will keep the project moving forward, as opposed to stalling and increasing risk by altering the plan on the fly. Looking back, that late decision to turn the heat up on the ducks wasn't a good one. Why? The ducks burst into flames. An experienced chef would have known what to do.