Translate

Thursday, April 24, 2014

The IT Provider Relationship Model



Have you ever felt your senior executive team had “champagne taste on a beer budget” when it comes to IT?  Or, maybe they merely want the IT team to spin a little straw into gold?  The scenarios I’m describing are when business leaders expect very high business impact from IT without funding key projects or sometimes even while slashing IT budgets. 

There’s a formal set of terms to describe this phenomenon.  We at IBM call it the “IT Provider Relationship” and have done more than a decade of research on it.  I thought this topic was a fitting follow-up to my last blog article because understanding this relationship is one of the first steps to ensuring there is appropriate alignment between the business and IT.  And, that alignment is critical for project success.

A dearly departed friend and colleague of mine, Mr. Mark Ernest, began studying organizational characteristics and dynamics between businesses and their IT teams over 10 years ago.  He found that this relationship gravitated to four profiles depending upon trade-offs made between cost and business value as decision criteria.  He categorized them as follows:

Commodity: The business sees IT as a “necessary evil,” a place to spend as little as possible.  The over-riding decision criterion when considering IT spending is cost rather than business value or qualities of service.  These organizations usually have very basic corporate IT requirements and rarely have someone with the title of “CIO.”  More commonly, an IT director with multiple management layers between him/her and the CEO tries to work miracles with a small staff and budget.  “Shadow IT” organizations outside of IT sometimes sprout as individual business units implement technology not funded at the corporate level to solve business needs within their unit.  However, these costs usually get buried in their unit-level budgets and fuel an illusion that “we don’t spend a lot on IT.” 

Utility:  The business desires a broad set of dependable IT services at the lowest possible cost much like many people desire a broad set of dependable services delivered at the lowest cost from any of their utility providers such as their mobile phone service provider.  IT is still viewed as a cost but some consideration is given to the quality and breadth of services received for that cost.  IT is not seen as a critical business component until something breaks and then the elevated perception of its business criticality barely outlasts the time it takes to resolve the crisis.  Grand business projects that require IT often are planned and hatched without involving IT until late in the process.  At this point, IT is expected to work miracles, magic, or a little of both to meet project deadlines.

In Commodity and Utility situations, it’s common to hear the business people complain about IT as an impediment while IT people lament that business people “just don’t get it.”

Partner:  A marked relationship shift occurs in this profile.  The business sees IT as a potential competitive differentiator for the business.  Thus, IT is seen more as a business asset in which to invest rather than as pure cost to cut.  IT is typically involved very early in business projects so that from inception, the project is designed with an eye for the strategic value IT can bring.  This is not to say that costs are ignored.  Rather, the business value is weighed first and is weighted very heavily alongside costs. 

Enabler:  Organizations that see IT as an enabler to the business see IT as providing substantial business competitive differentiation.  Technology is woven into the fabric of business, if not constitutes a foundational core of the business itself.  If the technology did not exist, neither would the company.  Often these companies have a CIO and likely a CTO who are considered part of the senior business leadership team.

In Partner and Enabler relationships, the lines start to blur between the business people and the “techies” because the lines have blurred between what is a business and an IT project.  Thus the two groups work and play well together…for the most part.

There’s no one “right” answer for which IT Provider Relationship an organization should have.  Most often though, an organization has one relationship and desires a different one.  And here we come back to the “champagne taste on a beer budget” scenario.  That pretty aptly describes a company that needs IT to be a partner or enabler to the business but still treats and funds IT like it is a commodity or utility.

In these situations, it’s often good to derive some semi-scientific quantification to define the current and desired IT Provider Relationships after first establishing a common vocabulary.  Quite frankly, sometimes businesses struggle to evolve the IT Provider Relationship because they lack a language / vocabulary to even discuss it.

This focus on IT Provider Relationships might raise the question of how an organization can shift from Commodity or Utility IT Provider Relationship profiles into Partner or Enabler ones.  Stay tuned as that will be covered in upcoming blog articles. 

Thursday, April 10, 2014

Welcome to "The CIO Coach"



Welcome to “The CIO Coach.”  I hope to provide snack-sized advice tidbits to CIOs based on my experience coaching many, many CIOs over many, many years.  The CIOs with whom I’ve worked are partially to thank (or blame) for this blog because they told me I was helpful.  Their encouragement evolved into this idea to try helping more CIOs than the ones I directly meet.  So, hopefully this actually is helpful…and hopefully I remember to keep it snack-sized.    

I’ve seen many companies and/or CIOs that want IT to provide competitive business advantage but for various reasons aren’t successful making that happen.  Their struggles mirror those of many organizations since the statistic is that around 75% of IT projects fail, dramatically exceed budget, or severely slip in schedule.  Why is that? 

I’ve not once found a company with a “hire stupid people” policy.  In fact, the clients I’ve worked with have extremely bright, talented and accomplished staff.  So, why the struggles?

I’ve found that project execution success factors can be encapsulated in three categories:
Context – the “why”
Content – the “what”
Collaboration – the “who,” “when,” “where,” and “how”

Each of those can fill multiple blog articles themselves but in the interest of providing substantive snack-sized content, let me elaborate a little on them now.

Having proper context involves setting solid strategy aligned with stakeholders’ needs which requires aligning business executives with the IT leadership team.  As IT becomes a business competitive differentiator, then IT projects become business projects in need of business executive sponsorship, business leader involvement, business risk identification, business case development, setting business objectives, and establishing realistic project timelines.  Bottom line is: make sure you’re working on the most impacting projects for the business by assessing them like business projects – because that’s what they are.

Having proper content involves gathering business requirements and aligning them with technology solutions that are effectively deployed.  This calls for an effective requirements gathering process.  Trade-offs need to be weighed before translating functional and non-functional requirements into data, solution, security, and technology architectures.  Sub-optimal architectures often lead to sub-optimal solution design, configuration, integration, testing, migration, roll-out and ultimately business impact.  So, don’t scrimp on the architecture steps.

Having proper collaboration involves skills, metrics, project management, teaming and risk management.  When IT projects are business projects, the IT project management office should be completely integrated with the enterprise project management office and it should be staffed with skilled project managers.   Regular project health assessments should occur based upon analyzing facts and projected outcomes.  Teaming behaviors need to be encouraged via having a common vision and common processes as well as metrics and incentives leading toward achieving common business goals.

So, if you have the desire and business support to make IT a competitive differentiator but are struggling to make that happen, maybe it’s time to examine how healthy the overall enterprise’s environment is for project execution.