Translate

Showing posts with label IT alignment with the business. Show all posts
Showing posts with label IT alignment with the business. Show all posts

Sunday, October 5, 2014

Getting IT a Seat at the Table



I’ve noticed a growing trend where CxO business leaders bypass the central IT organization for IT projects.  Often it’s the product of a “chicken and egg” situation. 

Business leaders feel IT isn’t responsive enough filling requests so they form their own workgroups that choose “best of breed” solutions, the implementations of which wind up failing (see previous article about the extremely high failure rate of projects) and then they dump the project in IT’s lap to save the day.  Why doesn’t IT respond quickly to business requests?  They’re consumed retrofitting “best of breed” solutions chosen by teams that didn’t involve the IT organization or didn’t involve them early enough. 

Statistics indicate that business leaders bypass IT as much as 65% of the time.  The sheer volume exacerbates the problem because the central IT team just gets more swamped performing personal heroics to salvage projects undertaken without sound infrastructure considerations early in the process. 

So, how does a CIO break this cycle and win a “seat at the table” with the other business leaders.  I’ve coached clients on many effective approaches but here are a few to try. If you’re interested in more details, send me a note.

  1.  Ask to be part of the business strategy sessions.  If that is not possible, then ask to see the business goals and key projects that emerge from the business strategic planning process.  This gives you much more advance notice of the types of projects that will require IT.  Few strategic business projects these days don’t involve IT and many are outright IT projects.  Gather your team to determine the IT implications for supporting the strategic business projects and approach business leaders with ideas for the plan.
  2. Explain the value of coordinating across all IT projects and having the IT organization lead that coordination.  Since IT is a component for almost all business projects, it puts IT in a position to increase collaboration between the individual strategic work streams for the business and to take a holistic approach rather than piecemeal one.  For example, one client for which I helped create an IT strategy had over 20 business projects that involved Analytics.  By the CIO leading the overall effort, the IT organization helped create an optimized infrastructure to support a prioritized roadmap for the full set of 20+ analytics projects.
  3. If the business leaders will not invite you to their business strategy sessions, invite them to your IT strategy sessions.  If you do this, you will need to take a business approach to your IT strategic planning.  Understand business goals and key projects across all disciplines, have the business leaders prioritize across the full set of projects and then determine the IT implications for supporting these projects. This effort should also include exercises to understand the current and desired future states for the IT Provider Relationship (see previous article 1 and previous article 2) as well as all IT capability areas. 
  4. Improve IT service quality in key areas.  Many times the IT organization is seen as providing sub-optimal IT services.  They might have enough ITIL certifications to wallpaper the office yet still have poor service quality.  Fix your IT service framework so that you truly offer services rather than just call applications services.  Take a practical rather than academic approach to instituting your IT service model.
  5. Invest in a few good architects who can bridge between the language of business and the language of technology.  Many times IT is not invited to the table because they are seen as speaking a different language from that of business.  This results in IT being seen as techies rather than business people.  A few good architects can work miracles to change that perception.
  6. Engage outside assistance.  As the saying goes, prophets are often scorned in their own land.  Sometimes using an outside organization to facilitate IT strategic planning or IT Service management improvement efforts gains a lot of credibility because the IT organization cannot be accused of being insulated or self-focused.
  7. Institute effective governance and enterprise architecture processes.  Most business leaders circumvent IT because their project will deliver time-sensitive competitive advantage that can’t endure idling in the IT project backlog.  Enterprise architecture aligns business and IT at many levels to ensure IT can provide needed competitive differentiation efficiently as well as run mundane daily operations effectively.  Governance defines decision-making processes and authorities and includes offering, portfolio and project management.  Many clients that consistently deploy projects successfully use architecture boards as governing bodies to focus IT on the right projects and create architectural standards to streamline solution creation, deployment and maintenance.  If IT lacks the capability and capacity to deliver the highest priority business projects in a timely fashion, there’s usually governance and/or an architecture issues lurking about.
  8. Assess IT resource (financial and human) deployment between day-to-day maintenance and competitively differentiating work.  The results of such analysis, when packaged in business language, are often good fodder for having a discussion with business leaders.
  9. Combine business and IT project management offices.  This demonstrates you understand business and IT interdependencies required for successful project execution and increases project success. 
  10. If you can’t win-over the CEO or full C-suite, find one advocate in the group and undertake a project with that business leader.  This demonstrates the value of business / IT partnership in planning the project all the way through execution.  If you do this, you need a strong project manager because you want to showcase this with other CxOs.  Hope for winning over skeptics diminishes if the project stalls or fails.

These are just 10 suggestions and I don’t recommend trying all of them at once.  Actually, I would recommend choosing only one or maybe two.  I offer a longer list because the right one to try will depend upon the business context and personalities involved.  But all of them help build the IT organization’s and your personal credibility as being business-minded rather than enamored with technology.

Friday, May 16, 2014

Changing the IT Provider Relationship


Last time I wrote about four profiles that categorize the relationship between business and IT – called the “IT Provider Relationship” profiles.  If you have no idea what I’m talking about, you might want to read the last article and then come back here.

It’s common to see business leaders wanting IT to be a partner or enabler to the business yet treat the IT organization as a commodity or utility.  The tough question when this gap exists is, “How do we fix it?”

I wish there was a magical phrase you could utter or a magic wand you could wave to alter that relationship instantly.  In reality, it takes time, consistent commitment and effort.  However, here are some suggestions that have worked with clients that you might want to consider:

1.  Get the business people to recognize the current and desired IT provider relationship profiles for your organization.  Having a common vocabulary and some semi-scientific data do wonders for facilitating conversation.  It also helps secure the business leadership’s buy-in that this is something important which deserves focus.  Just like in a strained marital relationship, if only one party wants to work on things, progress is usually difficult to achieve.

2.  If you’ve made it to step 2 then you have business buy-in.  Congratulations!  But, act quickly.  Business leaders sometimes have short attention spans.  If you have their attention and awareness that the IT Provider relationship needs work, then do not fritter away the opportunity.

3.  Establish regular communications between business and IT leaders about things that matter to the business and the associated IT implications.  Some of my clients do this twice a year.  Others do it quarterly.  I wouldn’t recommend doing it any more frequently than quarterly because that’s kind of like watching grass grow.  I wouldn’t recommend meeting any less than twice a year because remember step 2…short attention spans. 

As a side comment, it is imperative that this begin with the executive teams.  Leaders need to model the way.  Your staff will see it as “programme du jour” if executives expect their underlings to make all the changes whilst their own behavior remains constant.  Keep in mind that most of the people who keep the IT shop running have probably been around for a lot longer than you and have watched bright-eyed, eager CIOs with “great ideas” come and go.  They know they have outlasted many a CIO.  They often see themselves as having a better understanding of how things really work in the company and many feel they care about the business’ longevity more than the leadership team.  You don’t want your team seeing you and your leadership team as “suits” primarily focused on their own resume enhancement.

4.  Build a practical IT transformation plan that has business buy-in, connection to business objectives, assigned ownership, identified dependencies, realistic schedules, and prioritization based upon the support for business objectives.  Don’t have more work-streams going at once than your organization can handle.

5.  Build an effective business / IT governance model.  Many business leaders think their IT team moves at a sloth-like pace but often that’s because the IT staff keeps being diverted to do firefighting or to handle impromptu, under-developed, executive requests.  Anytime an organization spends more than 20% of their time fighting fires and handling ad hoc requests, they are in desperate need of improved governance.  If they spend more than 5% of their time doing this, they are in need of improved governance…it’s just not at the full-out “desperate” state yet.   

Governance includes the organization’s guiding principles for decision-making and accountability.
  • Who has the authority to make what decisions?
  • Who will be held accountable for what?
  • How are decisions made?
  • Who has to be consulted before making a decision?
  • Who has to be informed of decisions and when?
  • What’s the dispute resolution process?

6. Set IT key performance indicators (KPIs) that are meaningful to the business.  Don’t set targets that are just IT focused or things that IT knows it will achieve.  And if you are gathering statistics, then review them and use them to make fact-based decisions.

7. Focus on delivering solid utility-based IT services.  If you deliver inconsistent or inadequate service quality, you haven’t earned the right to move to a partner relationship.  Service quality improvement needs to occur in concert with business / IT governance because often service quality issues arise from a firefighting / ad hoc culture that impedes IT’s ability to fix broken processes.  Sometimes fixing service quality issues involves organizing IT into dedicated teams focused on building new solutions, implementing those solutions, and maintaining them. 

As a side note, sending your whole staff to ITIL training does not magically fix service quality.  If the executive leadership team is not fulfilling their critical role in organizational and process change, then sending everyone off for ITIL certification is just going to frustrate the staff and reduce their confidence in the leadership team.  Please see the side note for step 3 above.

8. Improve your architecture skills for the full span of Enterprise Architecture (EA) and start to develop a vocabulary and repository for enterprise architecture elements.  You’ve already taken some of the initial steps in establishing EA if you’ve made it this far, but you just haven’t called it that yet…and therefore probably haven't gotten hung-up on an academic approach that would earn you an A+ in an Ivy League business school but be impossible to implement in the real world.

9. Establish a communication process to communicate regularly to key stakeholders.  Communicate successes in business terms.  Hopefully this is easy to do because by now you’re measuring things that are meaningful to the business.  This also gives a regular structure for having other levels of IT leadership communicate regularly with their business counterparts.

10. Establish an “innovation factory” where a few business and IT people look at industry and technology trends and then brainstorm on ways to use technology for business competitive advantage.  Or, get started with a simpler approach of having IT people job-shadow business people to see the impact of their handiwork on the end client.

I’d like to label this list as “10 easy steps to improve the IT / Business relationship.”  However, to accomplish all 10 items takes at least 2 years.  That doesn’t mean that you won’t see business benefits until then.  Most clients start to see benefits within the first quarter or two of committed execution on their transformation plan.  The key is to get started and be practical.  Two years from now you can either have made progress or be the same place you are now…or possibly worse…since doing nothing while others move forward turns into a relative step backwards.

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.