Platt Perspective on Business and Technology

Implementing business technology – Part 4: cutting through the hype and buzz

Posted in strategy and planning by Timothy Platt on November 12, 2010

This is my fourth posting in a series that deals with issues any CIO or CTO should be familiar with, and that in fact any manager who is responsible for, or dependent on technology should know. Technology forms a central framework in the supporting infrastructure for any business or organization, and information technology is essential in this regardless of industry or sector.

So far I have written in this series about cyclical processes and how implementing and maintaining effective technology follows a recurring series of steps in analysis of options and requirements, implementation, due diligence and ongoing review with an eye towards the next loop in that cycle. If there are any minefields in this process, they go by the names buzz and hype, and I will be dealing with these issues with this posting. You can find the first three postings in this series at Business Strategy and Operations as postings 95, 97 and 98.

In a perhaps ideal world, we would all be able to find our options for addressing our business technology needs with all of the details readily apparent and without any misleading statements, gaps or pressure to conform to fads. We would have the information we need and without embellishment or distraction, and we would be able to make our decisions strictly on the basis of that. In the real world, that is rarely possible. New technologies and technology options are always coming out and with marketing that can be more focused on gaining market share than on best meeting the needs of any particular customer. When this is picked up on in the marketplace, fads can develop for the new and against the more standard, tested and available old. Gaps in fuller understanding of long term implementation issues can be glossed over with a focus on the expected and perhaps even idealized benefits of deploying this newest and greatest. And pressures to jump onto this new opportunity can come from within your own organization too, and from your stakeholders as they demand the newest because it must be the best. And the pressures of buzz and hype enter your planning and affect your options.

I in effect wrote about these issues but from the product or service manufacturer side in Putting Value Added into a More Balanced Perspective. Good judgment in designing and producing for the marketplace comes in significant measure from knowing what to include and what to leave out. A parallel process goes on for the buyer’s side of the marketplace too.

This means understanding what new features are being offered and the costs and benefits they would actually bring to your organization.

• If I go for the newest high end version which of these new features would actually be used and what savings and/or performance increases would they bring?
• Which features would work in the context of our ongoing legacy systems and business processes? If for example, a new system component offers a functionality that the rest of our system does not support, it would probably not work very effectively if at all here – and certainly if its potential value to the organization would not reach a threshold level to justify the additional costs of making the further changes needed to really implement it.
• In this, you cannot simply make purchasing and implementation decisions as if in a vacuum. You have to look at the needs and requirements of the organization and of the stakeholders who would use and rely on the services performed by this new acquisition.
• You need to do the due diligence in looking at possible impact if this does not work. Here, bugs happen and beta testing frequently continues from the manufacturer and their test experience to the customer and their “real world testing.”
• I add, of course, that you rarely if ever face a simple yes or no decision in this with only one possible new technology decision and one purchase option for it on the table. There are always multiple options for any given decision as to how to maintain or upgrade and you usually have to look at multiple systems upgrades and even potential systems-wide upgrades and all at once. Ultimately, all the pieces have to fit together and work together, and with mutually supported capabilities. All of this has to be cost effective and it should all support the organization in offering a sustaining unique value proposition.

Yes, you have to be ready to address the concerns and enthusiasm of the stakeholder who comes to you with an article from a newspaper or trade publication, saying their competition is using the brand new XYZ so they need it too. Consider this just one of your due diligence goals and requirements that you read these articles and check to see if this new XYZ would be the best choice. And armed with that information, you then need to go back to this stakeholder and discuss their needs and priorities and be prepared to argue the case as to how to best meet them, and cost-effectively and both for that stakeholder and for the organization as a whole.

Should some departments or services get special treatment? The answer to that is yes, and for several reasons.

• First, sometimes specific departments or services have special needs that require one-off approaches.
• Even when a possible global change in a system looks reasonable, it can be helpful to prototype test its implementation in a key service that would need to be an early adaptor in your organization for this new technology change.
• And quite simply, politics does happen and sometimes you have to at least locally implement something simply because you have to do so – and if it does not work out as hoped for you can work with these stakeholders to adjust from there. (Hint: never take an “I told you so” approach here.)

I write this as someone who has managed to avoid some mines, but who has stepped on a few too. I write this as a lead-in to a final thought I would finish this posting with. Plan and prepare for remediation and Plan B approaches as part of your basic assessment, planning and implementation.

I learned this early in my career from a very wise man who never immediately bought into the next major release of the database system deployed in our IT department. He made sure that we were very quick to pick up on every patch and incremental update for the system in use but when a brand new version X.0 came out he waited until it had gone through at least one or even two decimal point upgrades and patches, so we would not be bleeding edge adaptors. I add that this software manufacturer’s database systems were excellent but their new next generation releases always seemed to need those early patches and incremental updates to bring them to the stability and reliability of the product generation they were to replace. So be an early adaptor but be a selective early adaptor, and a later one when that would make more sense. And do not simply fall for the buzz and hype.

Tagged with:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: