Covalent Solutions Inc.®



Why Architecture Matters

Five Fundamentals for Success

Why IT Initiatives Fail

Where to Begin

About Us

Contact Us


Covalent Solutions Inc.®

Bonding Business to Architecture & Technology

Why Information Technology Initiatives Fail

Technology is expanding at an explosive rate. Today we are capable to doing so much more work--or information look-up--in fractions of the time required only a few short years ago. Computer processors are faster, memory systems are much larger, high-speed networking is pervasive, storage possibilities are huge and very reliable, and software options cover a very broad range of business challenges. So, why then do so many technology initiatives fall short of delivering against expectations, or fail completely?

Often the answer is not so much the capabilities of technology as it is the preparatory work performed in advance of the technical deployment. CIO's and their direct reports are challenged to open new business venues and/or improve market penetration/margin contribution through technical enablement. Additionally, more often than not, they are challenged to to it with a frozen or shrinking staff/budget.

Organizations can no longer afford the luxury of maintaining vast arrays of custom in-house software--based on the notion that "our business is so different that we have to create our own custom applications". They are forced to look to outside suppliers of technology which come close to responding to the business challenges of the organization. And, increasingly they look to leverage existing relationships with vendors or Open Source to negotiate excessive overall cost.

These are fine tactics--but they are not strategies. Giving a chosen vendor a larger stake in your business should result in an overall reduction in cost through greater discounting. But it also grants that vendor a lock--effectively eliminating competition for your business. Also, while the cost of downloading Open Source software is low--it still has to be maintained (sometimes even modified)--so there is either an in-house cost or a maintenance fee. Open Source isn't free!

In a down economy every company has to focus on tactical moves merely to survive. And, survival is a pretty good thing to have capture your attention. However, astute organizations will not just set their sights on the immediate, they will also look beyond. They will take advantage of the downturn that nearly every industry is facing and see this downturn as a strategic moment (opportunity) to leap-frog their competition when the economy improves.

A primary strategy that technical organizations should be embracing is; "Business to IT Alignment". Only when your Business Demands and IT Capabilities are aligned will you be able to realize the dream of "IT being a strategic weapon--or enabler". While many CIOs claim to be 'partnered' with their line-of-business counterparts, the litany of marginal technical deployments coming from IT organizations today suggest something very different is happening. As a technical leader, you can't just listen to your line-of-business counterpart's challenges you have to understand them and activelly participate in responding to them. And, as line-of-business leaders, you can't merely lay your demands a the feet of your CIO and expect him/her to "make it happen". Given the different skills and focus areas, your CIO may not even clearly understand which "it" needs to happen first.

The problem with this alignment is that most business people speak a different language than technical people. Rarely do you find a "translator" in the organization that can help bridge the communications gap. So, you get a lot of: Ready--Fire--Aim scenarios happening organizationally. Organizations are conditioned to perform impulsively--and today's market pressures only serve to exacerbate the problem.

So, very often technology initiatives fail--or at minimum run long and over budget--because business and technology people talk past--vs to--each other. Neither have a genuinely vested stake in the business challenges of the other, and there is no common language to unify the conversation. While this seems rather grim, there are tools and techniques which will bring the two constituencies together.

First:

  • You must begin any new initiative with a crisp understand of who all the Business Stakeholders are and then identify their Requirements.
    • Requirements gathering is not a 30 minute meeting
      • Requirements gathering is a series of meetings/interviews/brainstorming sessions followed by some means of distilling "requirements" from "wishes" (several tools exist to aid in the distillation process)
        • A requirement is not a requirement unless it is recorded and substantiated
    • Disqualifying something prematurely may mean that a 'key requirement' will be missed--which could easily translate to a total implementation failure--or at least cost overruns
      • Organizations often fail when they think they have requirements because they have spoken to a line-of-business representative or two--rarely is this a deep enough inspection
    • Very rarely should technology vendors be involved in the initial requirements gathering exercises
      • Engaging specialists in early phases of requirements gathering translates to attempts to do problem solving before all requirements are documented
    • Resist urges to prematurely move from requirements gathering to Problem Solving or Analysis
      • Write strong requirements--but don't attempt to solve problems
        • Note: The Requirements Statement tells you what needs to be done, but it does not state how to do it. This is known as staying in the "Problem Space"
Second:
  • Move to assessing Information Technology's current capabilities
    • Once you feel that your have done a reasonable job of collecting requirements from major business stakeholder constituencies--and you have their concurrence/sign-off--you should look inside your IT department to determine the limits of your current infrastructure and staffing.
      • Simply assess capabilities at this point--don't make large scale judgments
    • Remember the flow of events should be:
      • People - Current staff and capabilities to support the change in Requirements
        • Change acceptance/management tools may be needed downstream
      • Process - To support the change in Requirements
        • Look at current process efficiencies
          • Sometimes it is easier/less costly to modify a process than implement new technology
      • Technology - Do you have what is necessary or will moderate to significant updates be required to support the change in Requirements
        • Looking a technical capabilities and making technical determinations should always be the last step.
          • Leading with technology tends to defocus your attention from the most important issue--your business.
  • This step is often referred to as "Validation of IT Capabilities & Business Alignment"
Third:
  • You should translate your Requirements into IT Principles
    • In other words--"If the business needs to do this--then IT must be capable of doing that"
      • Real world example: "All data is created equally--but as data ages, its access value diminishes"
        • This example does not tell you that you must implement a hierarchical data storage solution--nor does it tell you to ever delete old files/records. It merely tells you that your data's value moves along the corporate continuum. So, you should classify your data and determine the value it holds at various points in its life-cycle--so that you may determine how to manage it.
  • The IT Principles you develop are not a "rule book" they merely act as a guidepost for better living.
    • These Principles are however, the very underpinning of development of an Enterprise-Wide IT Architecture.
      • The Principles have absolutely nothing to do with calling out a particular technology (hardware or software) but instead are rooted in your core business values.
The process that I'm mapping out is what we refer to as a "Principles-Based, Business-Driven Architectural Life-Cycle". The process has 8 points of delineation in total--where deeper inspection is required. And, the process is cyclical in nature--so that you may iterate through it as necessary when new data is discovered.  Application of a process such as it is a cornerstone technique which may be applied to crossing the chasm in terms of the communications barriers that naturally exist between Business and Technology people.

We have successfully used these tools over the years to help clients across many industries. It really doesn't matter what industry you are in (health care, retail, manufacturing, telecommunication, financial services, etc...) these inspection and development tools work exactly the same. And they work because the approach works from the perspective of your particular business out--not from technology in.

We have been called by people frantically looking to engage Sr. IT Architects to implement J2EE, SOA, or B2B solutions in a very specific industry. Their engagement cycle is typically six months. In reality, they are not looking to engage a Sr. IT Architect at all. They are looking for a programmer or analyst with very specific experience implementing a given technology for a particular industry. We doubt that there would even exist an architectural plan for a Sr. IT Architect to follow--if they were able to engage one.

In these circumstances, our guess would be that these people lead the process with "technology" and are now scrambling to find ways to live up to the high expectations they have set with their clients. They didn't do requirements gathering or they would have known in advance that they had a void in their skills which would not allow project success. These initiatives will fail--so they are now looking for someone to blame!

Initiatives fail when requirements are not crisply defined, current capabilities are not assessed, milestones are not established--and measured. Projects break down most often due to lack of requirements gathering, planning and/or communications. Technology clearly can become the problem--it you lead with it--but technical options are so broad that they need not become the primary issue.

Success or failure is a shared responsibility. While it is incumbent on all affected internal departments to play an active role in the change initiative, rarely do they ever. Likewise, vendors/partners focus more keenly on their bottom line than the bottom line of the client they are there to serve. They make the sale, then worry about resourcing and implementing the initiative. This process is often long and leads to several points of disenchantment.

While we can never guarantee success, we can faithfully state that greater success levels are achievable when you engage us up-front in your planning and assessment process. It is at that time that we are in the best position to help you explore what change really means to your organization.

To learn more: Contact Us