3.3 How Technologies Fail

 < Day Day Up > 



3.3 How Technologies Fail

If I walked into a room full of engineers and asked why technologies fail, I would expect them to immediately throw three questions back at me, namely:

  • What do you mean by "fail"?

  • What do you mean by "technologies"?

  • Don't you mean, "Why do projects fail?" because there is nothing wrong with properly applied technologies?

Each of these questions is somewhat rhetorical and contains the seeds of the answer we seek. Let us see what can be learned from walking through each of them.

3.3.1 What Do You Mean by "Fail"?

In the present context, technology is known or assumed to be the reason for unsatisfactory results. If this is the case, how specifically can technology be blamed? If you really think about it, technologies fail in just a few ways, as listed in Exhibit 4.

Exhibit 4: Why Technologies Fail

start example

  • The technology did not support or deliver the requirements.

  • The technology did not scale well to production requirements.

  • The technology had interoperability issues with the legacy environment.

  • The technology was "buggy," unstable, or intermittently inoperable.

  • Manufacturer support was ineffective.

end example

One would expect your project experts to indemnify against these conditions through experience, proper research and analysis, simulation, testing, and running a proof-of-concept scenario in any condition where the selection of the right technology is not a "slam dunk."

The eleventh question of the Big Thirteen stresses the creation of hard success metrics in advance of implementation, so that managing toward success has a more disciplined goal than "we got the system installed in time for quarter-end processing." To the extent possible, you should expect your technologists to agree with this approach. Ask them to incorporate it into their design process for those requirements that require customization, complete fabrication, or involve technology that is new to them, to your corporation, or to the marketplace in general. Do not assume that, in the absence of such a request, they will behave in this manner.

3.3.2 What Do You Mean by "Technologies"?

Ignoring the philosophical aspect that I am not qualified to discuss anyway, there is an interesting issue here. The IT world has come a long way in the past few decades. Still, no single type of technology, in and of itself, is a silver bullet, nor are they stand-alone. End computing devices, such as personal computers and hand-helds, local area networks (LANs) and wide area networks (WANs), host systems, and "the Internet" all must coexist in varying degrees of compatibility and productivity.

The complexities are such that unless everything is perfectly aligned, any system or application that you inject into the corporate environment can experience unstable if not unpredictable performance. The reasons are many and varied. The most significant is that you can never assume that everything you use works seamlessly with everything else you see, and cannot see, in your IT environment. For example, you can never assume that all servers are at the exact same level of operating systems. Anti-virus and server monitoring tools do not always integrate seamlessly. The way applications are distributed to the desktop can vary from site to site. In fact, you can never be assured that each and every desktop has the same "build," or that the local network behaves the same way from site to site or, in some cases, from one floor to another or even among same-floor cubicles.

The bottom line is that although new or significantly enhanced technologies come along every now and then, they will be applied on top of, or slipped into, a nonhomogeneous environment that already has indigestion. As companies struggle with mergers and acquisitions, efforts to transparently integrate different networks, systems, and platforms add enough complexity and uncertainty that any new technology rollout should be approached with some apprehension.

3.3.3 Don't You Mean "Why Do Projects Fail"?

Some would contend that it is projects, not technologies, which fail. I personally do not worship at the altar of technology, although I still get the occasional cheap thrill from new IT bells and whistles. More important, I believe that the ultimate outcome of technology projects will be hugely impacted by how well the technology rollout has been conceived, tested, and adjusted as you wend your way from start to finish.

This is a practical matter. A few years ago, I worked with several teams to move a complex architecture of application servers from one data center to another. The customer was driving the previous project manager so aggressively that we inherited a mess that was bumping up against some critical business deadlines. This was a financial application with "do or die" dates associated with its output.

One piece of the architecture included a half dozen Web servers front-ending the application server, the purpose of which was to deliver data to global users. There was a need to load balance the Web servers, which meant that there was an agent embedded in the Web server software that made sure that as each new user logged in, he or she had a session established with the least-congested server. The obvious benefit was that not all 75 users were trying to access only one of the Web boxes.

When the servers were installed in the new data center, we were horrified to learn, at the eleventh hour of course, that load balancing did not work. Based on my peripheral knowledge of the network and blessed with personal relationships, I was able to get a quick diagnosis of the problem. The new data center had a more sophisticated, much faster network infrastructure than did the legacy site. That was the good news. The bad news was that the load balancing software that had worked so well in the legacy site, on older hubs made by a since-deceased company, did not work on the new gigabit Ethernet data center LAN we had so proudly constructed.

This tale illustrates why I maintain, with a touch of irony, that it is better to be lucky than good. It just so happened that one of the top network engineers and I were on good speaking terms. For that reason, I happened to know that he had in his possession switching gear the vendor had just brought to market that could be installed in our new data center switches and deliver load balancing. We swiftly engaged other engineers, the vendor, cable pullers, and the telecom switch management team to install and test this brand new technology. We made our deadline the same way some teams probably win the Super Bowl - on the very last play.

Part of our good fortune was the fact that the "add-on" equipment that saved the day was a brand new product. The only reason we had it was because the vendor gave us a set for evaluation, because our company was a big customer and they hoped we would find a myriad of uses for it. I mention this only because it would have cost over $100,000 to buy it. No one was funded for that, plus we were not positive in advance that it would work with the application.

This story illustrates many aspects of project management, but it particularly goes to the heart of project failure. We narrowly avoided a disaster. The core project team, myself included, was clueless about the load balancing issue. As project manager, I was fortunate to be able to reach out for help to folks who were astute and professional enough to pitch in when they could have sat on their hands. I have omitted several details to this story. Suffice it to say that many mistakes were made, not the least of which was the previous team wasted so much time that there was no opportunity to test until 72 hours before cutover date and end-of-month processing for a mission-critical financial application.

In other words, it was very poor project management. It was as though the driver steered into well-documented potholes instead of seeking the safer, easy way out. Unfortunately, although the details of this tale might be unique, the cause of this debacle is one I have seen over and over. This is why, no matter how technically astute you might be, even with the technology at hand, as project manager the most important question you must continuously ask is: "How do we know this thing is going to work?"



 < Day Day Up > 



Complex IT project management(c) 16 steps to success
Complex IT Project Management: 16 Steps to Success
ISBN: 0849319323
EAN: 2147483647
Year: 2004
Pages: 231
Authors: Peter Schulte

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net