Tag Archives: IT leadership

Digital Business and the Fate of the IT Organization


Social-MediaInformationWeek just published an excellent article titled “Goodbye IT, Hello Digital Business.” The article presents a compelling case for “Digital Business” as a lens into what the more information and IT-savvy companies are doing. It presents some good case studies from Digital Business leaders in the retail industry. It also presents some interesting statistics on emerging platforms for building customer ties, on the main opportunities for today’s CIOs and how IT teams are interacting directly with customers.

Are IT Organizations Asleep at the Digital Switch?

I found the statistics InformationWeek presented as both believable based on my consulting experience, and disturbing! The numbers reinforce the facts that:

  • The majority of IT organizational focus and energy continues to be consumed by legacy solutions, keeping the metaphorical “lights on and trains running on time.”
  • The IT organization typically does not play a major role in business innovation.
  • The IT organization is slow to enter the world of mobile computing.
  • Many IT staff don’t have the customer-facing skills and business knowledge to play in the emerging Digital Business space.

The statistics indicate a move in the right direction – no surprise there.  But the shift is slow – rewarding the early movers with the advantage of a differentiated experience for their customers and for their employees – especially for those IT staff that are involved in these frontier applications. The early movers, through business experimentation and studying success stories are building their digital capabilities.

Accelerating the Shift

Exploiting Digital Business is not just about innovation, agile channels, mobile computing and social media – it has profound implications for the IT organization and its context – the IT Operating Model. I’ve posted before about how IT Operating Models must change for what I called Enterprise 2.0 – aka, Digital Business.  (See here and here.)

Some companies are accelerating the shift through IT Transformation programs – reorganizing, rethinking IT processes and value streams, re-skilling the IT organization and, in some cases, radical outsourcing initiatives. Other are using ‘skunkworks’ approaches to learn and build credibility through early business experiments. Some have the most progressive and promising Digital Business initiatives happening in the shadows – outside the purview of their IT organizations. I find that to be a dreadful indictment of the IT leadership! If that is not a wake-up call for a new CIO, I don’t know what is!

Digital Business is Literally Business-IT Convergence

I’ve posted before on the concept of Business-IT Convergence. In many respects, Digital Business is all about the convergence of IT with the business – business products and services become digital, and IT capabilities – historically located in an IT organization – converge with business capabilities. Some IT professionals and leaders will see this as very threatening. Others will see it as the solution to many perennial problems associated with the ‘us’ versus ‘them’ of the business-IT relationship.

What do you think? How is Digital Business impacting your work life?

Image source courtesy of Devicix

Related articles
Enhanced by Zemanta
About these ads

Motivation and Engagement – Why It’s Often Lacking in IT Organizations and How to Increase It!


motivation

A couple of years ago, I came across a remarkable presentation by author Daniel Pink, and featured it in my blog post, “So You Think You Understand How To Motivate People!” It’s always been a popular post (and a great example of animation as a way to present ideas.)  I recently got around to reading the book that inspired the presentation – Drive, by Daniel H. Pink.  I’ve also just read the wonderful, To Sell Is Human by the same author, so I’m clearly “in the pink” as they say, and very appreciative of his research, writing skills, and his ability to constantly challenge the conventional wisdom, with insight and clarity.

Why Are Motivation and Engagement Important to IT Organizations?

Clearly, this is a trick question – motivation and engagement are important to any organization (or endeavor) but I have worked with quite a few consulting clients over the last few years where engagement was low – it both felt low as I worked with various teams and observed behaviors, and it was measured as low in annual engagement surveys, such as those by Gallup and Towers Watson.  Often, the IT organization scored lower on engagement than any other part of the business – sorry, readers – please don’t blame the messenger!

Why is IT Organizational Engagement Low?

I’m not certain about the reasons, but I have some hypotheses based on my observations and conversations with many IT staff:

  • In tough times (yes, like we’ve had the last few years!) IT organizations take it on the chin!  They are asked to participate in cost cutting, and they do – often again and again!  I often hear comments such as, “I’m doing the work of three people – and I never feel as though I can catch up and do a good job!” These rounds of cost cutting take their toll on morale and negatively impact engagement.
  • Often the cuts impact things that are important to IT staff – education and training, for example, or office ‘socials’ where people get to network and know each other.  Even ‘perks’ that used to be taken for granted, such as free coffee and sodas, or subsidized cafeterias have been eliminated.
  • I’ve noted before that IT professionals tend to abhor ambiguity – after all, they have to reduce business problems to zeros and ones!  And yet, in times of organizational change and transition – which have become the new normal for many IT shops – ambiguity is high, leading to frustration and low engagement.
  • The nature of IT is that it is noticed most when things go wrong – less so when they go right!  I’ve observed before that the half-life of an IT snafu is 12 years, whereas the half-life of an IT success story is 12 minutes!  It’s tough to stay motivated when you are constantly defending yourself!
  • For IT to deliver great results requires that many moving parts and processes across a complex environment work together seamlessly and harmoniously.  It’s tough in such an environment to create the kind of motivation-inducing autonomy Dan Pink writes about.
  • Finally, outsourcing has created both fear of job stability, and, for some IT professionals at least, degraded the job to that of a commodity.  I don’t personally think of outsourcing as wrong or misguided, but sometimes it is handled and introduced to the IT organization in a crude and clumsy way – for example, as a threat, “You’d better knuckle down or your job will be outsourced!”

What Does Research Tell Us About Motivating Knowledge Workers?

Knowledge workers are most motivated by intrinsic rather than extrinsic factors.  This explains phenomena such as the open source movement, and, as Pink points out, the remarkable and almost unpredictable success of Wikipedia – created by volunteers over Microsoft Encarta – a product of a gigantic company with a large budget and a massive team of experts.  Pink goes on to define three elements of what he calls “Type I” motivation – fueled by intrinsic desires:

Autonomy

One of the three basic human needs, what motivation researchers Edward Deci and Richard Ryan describe this way:

Autonomous motivation involves behaving with a full sense of volition and choice.”

It can include autonomy over task, over time, over team and over technique.  I’ve posted before about the concepts of standardizing process, deliverables or skills, and how IT organizations tend to get these confused, or try to standardize everything though processes.  Autonomy has been all but stamped out in many IT shops!

Mastery

Which reminds me of Robert Pirsig‘s Zen and the Art of Motorcycle Maintenance, which I’ve posted at length about as one of the most influential books I’ve ever read.  Given sufficient engagement in an activity, rather than being forced into that activity by compliance, individuals will generally seek personal fulfillment by striving to achieve mastery.  Even though they may never get there, they find enormous personal satisfaction in the journey towards mastery – spending significant chunks of time in what some call “flow.”  My colleague at the new Business Relationship Management Institute, Dr. Aleksandr Zhuk, pointed me to this quote from Matthew E. May‘s The Shibumi Strategy: A Powerful Way to Create Meaningful Change.  Shibumi is a Japanese word that better captures the concept of flow:

Moments of utter clarity. We feel wide awake and connected and balanced: everything makes sense, we know exactly who we are, what we want, and why we’re here. In that moment, be it one blink or a thousand, our effectiveness is maximal. And yet our actions seem minimal, effortless even, and the experience is consummately satisfying.”

How many IT jobs are designed to encourage Shibumi?  Many of my clients create an environment where constant context shifting takes place, as people are shuffled from design to maintenance to break-fix and so on.  Not much Shibumi takes place under such circumstances!

Purpose

Purpose provides the energy for living.  Think about the things you do outside work – and why you do them.  Coaching kids soccer.  Skiing.  Learning a musical instrument.  Volunteering for a charitable organization.  All these things have a purpose – and it’s not wealth creation.  Of course, there’s an element of wealth creation in our work, but for most of us, the need to make a living wage was satisfied early in our career.  So what is the real purpose in our work?  I remember some years back in a coaching session with a group of IT leaders from separate organizations discussing the fundamental mission of our work places.  Most of the group members were confounded by the discussion – they did not know what I was trying to uncover.  Except for one of them, who watched the others struggle with a slight grin on his face.  Eventually, this IT leader from a global pharmaceutical company said, “We save lives by inventing drugs that cure deadly diseases!  That’s why we do what we do.”

Why are you and your IT staff coming to work every day?  Is the purpose really motivating mastery?  And do you have the autonomy to engage in your work?  What could you do to improve motivation and engagement?  As a starting point, you might read some of Dan Pink’s “Drive.”

Graphic courtesy of Success Blog

Related articles

 

Enhanced by Zemanta

Driving Business-IT Convergence – The Evolving Role of the Business Relationship Manager (Part 1 of 2)


WhitePaperCoverI’m seeing a surge of interest in the emerging role of the Business Relationship Manager (BRM) as a key position that sits between a shared services organization (most frequently IT) and its business partner.  This is an internal role that should not be confused with the similarly titled externally-facing role common in banks and financial services organizations. I have referenced the BRM role many times over the last 6 years, and covered the topic at some length in January (see ITIL and the Business Relationship Manager: Avoiding the Performance Trap and Design Thinking and Emerging IT Roles.)  Recently, I’ve been getting an inbox full of questions about the role, so I decided to satisfy that interest with a new 2-part post looking at how the role is evolving.

Defining the BRM Role

The BRM role is by no means ‘standardized’, even as the IT Service Management movement tries to place it in its standards as a rather tactical position, mostly focused on steady-state IT services.  High quality steady-state services are certainly an important aspect for any IT organization – table stakes, if you will, for getting a “seat at the business table”.  (Please excuse the double table metaphor!)  But once the business partner experiences the BRM as negotiator for and arbiter of services, service levels and the like, they are unlikely to invite that BRM to the next strategy offsite to help figure out how the business strategy should address increasing business digitization, for example!

We see common variations in BRM:

  • Seniority – and the level of business executive with whom the BRM partners.
  • Scope – and the number of business unit executives and managers the BRM works with.
  • Purpose – especially in the balance of the BRM focus between supply and demand.
  • Title (e.g., Business Partner Director, Account Manager, Client Relationship Manager, IT Business Partner, Business IT Partner, etc.)
  • ‘Supply side’ focus (i.e, many BRMs represent the IT organization, some represent HR, Finance, and so on.  A small number represent multiple “shared services”.)
  • ‘Demand side’ focus (e.g., Line of Business, geographic region, major business process, corporate functions, etc.)
  • Size of the BRMs team – from sole practitioner to leader of a team of 8 or 9.

The Typical BRM

While typical, as with averages, can be misleading, the most common model for the BRM includes:

  • The BRM sits at the intersection of IT and its business partner – representing the business partner(s) to IT and IT to the business partner(s).
  • The BRM stimulates, surfaces and shapes business demand for IT projects, services, capabilities and investments in order to maximize their business value.  This means taking a proactive role in educating the business partner, suppressing demand for low value activities while stimulating demand for high value activities.
  • Ideally, the BRM is a member of both business and IT leadership teams, contributing to both business and strategy and planning, identifying how information and IT can support and advance business objectives, and helping translate demand into supply.
  • The BRM partners with appropriate supply resources to ensure supply-demand alignment.
  • The BRM helps create project and program charters.
  • The BRM oversees initiatives and helps manage business process change to ensure that the value predicted by a business case is actually realized.
  • The BRM monitors business partner satisfaction and facilitates continuous improvement in the business partner experience with IT (or HR, etc.)
  • To accomplish all the above, the BRM typically manages a small team comprising “junior BRMs”, business analysts and other specialized resources required to ensure an effective business-IT relationship.

If that sounds like a lot of responsibility, it is!  In fact, at their best, IT BRMs are thought of as “mini-CIOs” and are often on a succession path to the CIO position.

BRM Responsibilities

Common responsibilities include:

  • Active member of both the business partner and IT leadership teams.
  • Joint accountability (with the business partner) for business case development and value realization.
  • Accountable for development and execution of the business partner IT investment portfolio.
  • Partnering with the IT Solution Delivery Organizations to manage expectations and ensure efficient and effective delivery of all IT services.
  • Accountable for business partner awareness of systems security requirements and responsibilities.
  • Orchestrating key roles on behalf of their business partner (e.g., Project Manager, Enterprise Architect, Business Analyst).
  • The BRM acts as a broker for needed resources and capabilities (e.g., Vendor Management, Service Management, Organization Development).

From Alignment to Convergence

I’ve posted on this important concept before – with all due credit to Professor James Cash, Harvard Business School, with whom I helped design and deliver a relationship manager development program some years back.  He first helped me to the insight that alignment was no longer sufficient – CIOs needed to recognize that business and IT were converging as every aspect of business strategy and operations was increasingly dependent upon information and IT.  Today, it is largely the BRM who operates at the leading edge of the convergence movement – a movement being accelerated by the ‘consumerization of IT’.

Teaser for Part 2

I’ll pick up in Part 2 of this 2-part series with examples of needed BRM competencies, a discussion of how the BRM role changes over time with increasing maturity (of both the BRM and her business partner) and how the way that the BRM engages with the business partner shifts the relationship from one of order taker to that of strategic partner.

Graphic courtesy of Acre Resources Limited

Related articles
Enhanced by Zemanta

Does Cloud+Consumerization Doom the Federated IT Operating Model?


The Federated IT Operating Model is Under Threat!

Today, most organizations employ some sort of Federated IT Operating Model.  Wikipedia defines a federation as:

…characterized by a union of partially self-governing states or regions united by a central (federal) government. In a federation, the self-governing status of the component states, as well as the division of power between them and the central government, are typically constitutionally entrenched and may not be altered by a unilateral decision of the latter.”

Typically, enterprise-wide or common applications, initiatives and infrastructure are a centralized (federal) responsibility, while local applications and activities are under the control of business units or functions.  This “federal rights/states rights” model has infinite variations.  Definitions of “common,” “enterprise-wide” or “infrastructure” are subject to interpretation, and these tend to change over time, with changing business conditions, leadership, technology and other forces.  There’s also inevitably a “shadow IT” phenomenon – sometimes quite large – where much IT activity happens outside the realm of IT governance.

Just as in countries with a federal governance model, the competing forces between state and federal rights pull and push over time, leading to an ebb and flow of centralization and decentralization.  This can be healthy – like an accordion, making sweet music as the parts are squeezed together or pulled apart.  It’s never static, but constantly responding to the forces of change – just as all living systems “breathe” in some way or another, and have their seasonal variations.

But every now and again, new forces surface and combine together to disrupt the gentle ebb and flow – the so-called Arab Spring comes to mind.

The New Forces of Change

IT governance is undergoing such a confluence of new forces.  These include:

  • Cloud computing – it is easier, faster and cheaper (on the face of it) to leverage the cloud to host applications and provide IT services (e.g., storage, transaction processing, data analytics) rather than have your federal IT group provide these services.  Much of this activity takes place in the “Shadow IT” realm.
  • Mobile computing – more of us are doing more via smart phones and tablets.  This exposes us to mobile applications and the many “app stores” including Apple’s and Google.  Getting an app is as simple as clicking a button – and many apps are free, or cheap enough to add to your mobile phone bill without feeling any pain.
  • The shift in the personal computing operating system – from Windows, et al, which can be controlled by the central (federal) IT department, to technologies such as Apple’s iOS and Google’s Android which are much harder (perhaps impossible?) to control centrally.  The genie is already out of the bottle, and it’s not going back any time soon!
  • Economic climate – the economic climate facing most businesses, whether in the US or just about anywhere else is in the doldrums.  This keeps people scrutinizing costs, prepared to make short term economic moves, even if at the expense of the longer term, and trying just about anything to get “unstuck”!  Such a climate tends not to favor centralization and federal power (just ask President Obama’s campaign advisers!) but empowers local forces and factions.

Beware the Unintended Consequences

So, what to do about it?  Here’s three options:

  1. Take a laissez-faire approach – a path of least resistance.
  2. Push back, hunker down and reinforce the federal model with more controls and stronger sanctions for “shadow” behavior.
  3. Adopt a “mutual adjustment” approach that navigates the stormy waters to constantly find the optimal balance.

From my perspective and experience, Option 1 has potential (likely?) unintended consequences.  We saw this when many central IT groups were slow to respond to the emergence of the Personal Computer.  When they did respond, it was generally via Option 2 – they tried to constrain them.  That drove a lot of rogue and shadow behavior and set many companies IT efforts back several years.

For most of us, Option 3 is the practical and pragmatic solution.  Let’s face it, there are all sorts of unknowns in terms of how these forces will play out over time.  We need some form of centralized coordination of infrastructure. However, the terms “coordination” and “infrastructure” must be defined clearly and re-defined from time to time as we gain experience with cloud computing and consumerization of IT.  There is not a right and wrong here – but a critical need for organizational clarity so that you are setting the bounds of infrastructure clearly and in a way that is appropriate to the times and to your business context.

Seven Steps to a Mutually Adjusting IT Operating Model

I believe IT leaders must approach this in the same way they would approach any needed change:

  1. Create and “market” a compelling end state vision.
  2. Surface and “sell” the cost of status quo or of going down the wrong path.
  3. Define a credible and palatable path to the future.
  4. Enroll key stakeholders in joining together on that path.
  5. Engage selected key stakeholders in the governance model.
  6. Surface and celebrate successes along the way.
  7. Take action to discourage deviations from the path.

Image courtesy of Charles Ayoub

Related articles
Enhanced by Zemanta

What Does Your Leadership Team Talk About?


I was talking to a senior IT leader at a global company this week, who said, “Our leadership team really needs to schedule some time to talk about strategic issues.  Our weekly IT Leadership Team meetings are consumed by tactical and operational stuff!”

This struck me as odd – and unfortunate!  “Tactical and operational stuff” should be on auto-pilot.  IT processes and management systems should take care of most things.  When I hear that an IT leadership team is consumed by the tactical and operational, my first reaction is that it is not a leadership team – it is a management team – a very different beast.

Leadership versus Management

Much has been written about the distinctions between leadership and management, so I won’t go far into this here.  For me, leadership is about influencing people, whether you have managerial authority over them or not.  Management is about exercising authority.  This basic distinction has important ramifications.  Leaders focus on the longer term and typically are concerned with achieving higher levels of performance for an organization.  Managers are more focused on the shorter term and on achieving agreed performance goals and objectives.

So, to recognize that “our leadership team doesn’t talk about strategic issues” is to recognize that it really isn’t a leadership team, it’s a management team.  That may be ok.  I worked with the CIO and his team at a major financial services company a while back.  They had been through a multi-year transformation under a new CIO.  The CIO and his team had been very ‘hands on’ and directive.  The results had been very positive, and the business clients of IT were impressed by the gains made from the transformation.  But, like many transformations I have seen, their performance improvement efforts had plateaued.  Managers and workers in the IT organization felt dis-empowered, so there was no real culture of continuous improvement.  The results of the annual engagement survey showed significantly lower employee engagement in IT than anywhere else in the company.

I raised the subject at an IT leadership team meeting, posing the question, “Are you a leadership team?  Or a management team?”  Consensus was quickly reached that they were a management team, with this finding justified by the sorry state of IT prior to the transformation, and the need for the top people in IT to drive change.

Which Do You Need – Leadership or Management?

I think that was a valid justification in their situation.  But the follow-up question, “What do you need to be now – a management or a leadership team?’ was much more contentious – especially as we drilled into what behavioral shifts would be implied if they did shift into a true leadership role.  For example, could they really trust their IT managers to manage?  If not, would they replace them with those they did trust to manage?

Dealing with this question and it’s implications became a major theme of my work with that team for the balance of the consulting engagement.  Great managers often have a hard time transitioning to a leadership role.  Great management teams have an even harder time transitioning to leadership teams – team members mutually reinforce each other’s instinct to be directive and in the details.

Have you fallen into the management trap?  How much time do you spend leading versus managing?

Graphic courtesy of Anthem Athletic Association

Related articles
Enhanced by Zemanta

Why Some Projects Should Be “Led,” Not “Managed”


I’ve posted before (many times!) about Business-IT Maturity, and the common “sticking points” that most IT organizations run into around the mid-point between low and high maturity.  (See, for example, here, here, and here, or enter “Sticking Point” into the search box.)

Walking Ever Faster Will Not Get You Running!

If, arbitrarily, you pick 3 levels of Business-IT Maturity – say Level 1 = low, Level 2 = medium and Level 3 = high, you will typically find that the things you have to do to get from Level 1 to Level 2 not only won’t get you from Level 2 to Level 3 – they will actually prevent you from reaching Level 3!  The trick is to recognize what these things are, and that you are entering a very different learning curve.  For example, if your solutions delivery process is broken, you need a great deal of rigor and discipline – in the form of Project Management and a Systems Development Life Cycle.  That will get you from “chaotic” (Level 1 in my hypothetical 3-Level scale) to “managed” (mid-Level 2).  But over time you will find the limitations of a “managed” approach to solutions delivery – especially when you need to implement “fuzzier” solutions, such as social media, or business analytics.

One Size Does Not Fit All

With solutions delivery, one-size does not fit all, and the methodology that works well for a relatively easily pre-specified transaction processing system (order-to-cash, for example) will not work well for something that is less predictable and more emergent.  Hanging in there with the “official” methodology (for fear of reverting to the chaotic situation that persuaded you to implement the methodology in the first place!) will frustrate the developers, annoy the business client, and will probably lead to a poor or unworkable solution – which will upset everybody!  What is needed is a finer-grained way of categorizing types of business solutions, and flexibility with methodologies to fit the best approach for a given solution type.

What Worked for Transactional Systems Won’t Work for Innovation Solutions

Collaboration and Knowledge Management initiatives are not readily planned using traditional project management methods – they tend to follow an ‘emergent’ pattern that is typically non-linear and somewhat unpredictable.   A traditional planning style, with detailed deliverables, work steps, activities and due-by dates must give way to a more iterative and organic approach.

Social Media Projects Should be Led

You cannot mandate participation in a community – you can invite participation and create reasons to do so. You cannot schedule a date by which a given percentage of a community will be collaborating on a wiki, for example – you can only set expectations, model desired behaviors, and create good reasons for people to become active users of the wiki.  Then you must reevaluate the results and adjust the approach in the light of experience.

Recognizing the Hard-Won Battle – and the Need to Fight New Battles

It seems that sometimes the battle of getting from Level 1 to Level 2 Business-IT Maturity is so hard won, and the win so apparently fragile, that leaders hang on to the methods that got them to Level 2.  This is about being really good at solving yesterday’s problems.  It’s a different world today, and the ways that technology and information can be exploited for business advantage demand different approaches.  Don’t let the trappings of Level 2 restrict your ability to get to the next level!

Enhanced by Zemanta

 

Does Your IT Shop Embody a “We Can Do That!” or a “We Can’t Do That!” Culture?


I was reminiscing with a consulting colleague recently about the two kinds of IT shops we’d worked with.  (Reminds me of an old joke that I first heard from Professor John Henderson at Boston University – “There are two kinds of people in this world – those who believe there’s two kinds of people and those who don’t!”)

The “Can Do’s”

Some IT shops fall clearly into this camp.  Suggest something innovative or new to them, and they are quick to explore the idea, see if it makes sense, and then figure out how they’d make it happen.  These clients are a delight to work with – energizing, engaging, sometimes challenging, but in a positive, constructive way.

The “Can’t Do’s”

Other IT shops fall into this unfortunate camp.  Suggest anything – innovative or not – and the immediate reaction is some variation on, “We can’t do that!” or, “That won’t work here!” or, a common variation, “That’s just not the way things work around here!”

Ask someone in a “Can’t Do” shop to help with something, and they will spend 30 minutes or more telling you why they don’t have the time to help – even if the help you are asking for would take only 15 minutes!  In other words, they will spend more time telling you why they can’t help than the time it would have taken to help.  It’s a knee jerk reaction.  The thought bubble I see in my head, floating above these naysayers is, “If I sign up for this, I might have to do something that would change the status quo.  That might be dangerous.  That might lead me to the unknown.  It’s safer to say, ‘no.’”

Prevent “Bad Change”

The “can’t do” environments spend all their energy trying to prevent change that might be harmful or counter to the established order.  Of course, there’s typically no way of knowing if it’s going to be a “bad change” or a “good change”, so by definition, any change is to be resisted at all costs!

Create “Good Change”

These are the innovators – the change agents.   Always looking to challenge the status quo and explore new possibilities.  I imagine that companies like Woolworths and Circuit City had a critical mass of “change resistors” (or at least, had enough of them in positions of power to preserve the status quo), while companies like Best Buy and Target had a critical mass of “change agents”.

I can understand why IT shops tend towards the “prevent bad change” camp.  IT operations depend upon stability and predictability, so you don’t want to mess with that.  But, unfortunately, the operational needs and culture tends to permeate everything the IT shop does!  Just when the business needs their IT specialists to be bringing them new ideas and new ways to compete, the IT specialists are beating down anything new.

From “Can’t Do” to “Disengaged”

Unfortunately, it’s an easy slide from “can’t do” to “disengaged”.  People in the organization get so beaten down whenever they try to introduce something new, that they give up.  It becomes such a painful endeavor, banging your head against a wall, that you stop trying.  It’s easier to slip into the background and go with the flow.  I have to admit that even as a consultant, there have been times where it was too painful trying to change things, and I’ve “gone native”.  Just make sure the deliverables per the Statement of Work are produced, get paid, and get out!  After a while, the extra energy it takes to break through the culture is spent.  At times like that, I empathize with the client’s employees – beaten down, disengaged, and at peace with simply going with the flow.  All that potential creative energy left at home, rather than being brought to the office as a source of new ideas.

So, What To Do About It?

I’m sorry, there’s no magic formula I’m aware of.  The first step, like the substance abuser, is to admit to the shortcoming.  Recognize that “can’t do” has permeated everything – way beyond those operational process where preventing bad change makes sense.  Then follow the familiar but tricky steps of organizational change management – establish the cost of the status quo, create a vision of the new, brighter future, build a guiding coalition, create early wins, etc.   Sometimes, it pays to stick you neck out – ask forgiveness, not permission!  If you get shot for doing so, that’s OK – you probably didn’t want to work there anyway!

Enhanced by Zemanta

The Decline and Fall of the IT Organization?


With apologies to Ed Yourdon for my plagiarism of his original the book title, published back in 1993, “The Decline and Fall of the American Programmer“.  (Though I don’t recall if Ed gave apologies to Gibbon for first using this line!)

For a blog entitled “IT Organization 2017″ and for a management consultant who has had a very satisfying professional career consulting to IT organizations, the title of this post may seem both extreme and inappropriate.  However, I use the title not just as a controversial ‘hook’ to attract readership, but as a sincere expression of what I think is happening today – and will continue to do so.  The traditional role of the IT organization is on the decline and will never return to the importance and business value impact it had over the last 50 years.  The good news is, there is a crucial new role emerging – and for IT leaders that can envision and lead the new possibilities, I believe there’s a bright new future – perhaps brighter than the traditional IT leadership role.

So, Who Screwed Up the IT Organization?

I’m not sure this is anyone’s ‘fault’ per se, or could have been avoided.  Rather it is a natural by product of technological evolution.  Back in the late 1800′s, many corporations employed Chief Electrical Officers.  Nick Carr gets into this nicely in his aptly named book, “The Big Switch.”

A hundred years ago, companies stopped generating their own power with steam engines and dynamos and plugged into the newly built electric grid. The cheap power pumped out by electric utilities didn’t just change how businesses operate. It set off a chain reaction of economic and social transformations that brought the modern world into existence. Today, a similar revolution is under way. Hooked up to the Internet’s global computing grid, massive information-processing plants have begun pumping data and software code into our homes and businesses. This time, it’s computing that’s turning into a utility.”

The shift from electricity as a highly specialized resource to commodity took about a decade as standards such as voltage, alternating current, plug and socket configurations, and so on were settled.  Once the standards existed, businesses could simply plug into a grid – electricity became a commodity, and the Chief Electrical Officers become extinct as the Dodo.

An Historical Perspective

The first commercial mainframe computers, the LEO were created in 1951 by J. Lyons and Company, a British catering and food manufacturing firm.  The idea of a food and catering company today designing and building it’s own computer is unthinkable!  I remember in the late 1960′s, businesses such as Massachusetts General Hospital were creating their own programming languages, data base software and teleprocessing monitors – activities that would be considered wholly irresponsible today.  I wonder if 15 years from now we will look back at the turn of this century and be bemused by the fact that typical companies of any size at all maintained IT organizations – in some cases, thousands of IT professionals – writing programs, tending help desks, and so forth.

So, What’s Happening to the IT Organization?

For many years the annual surveys of top CIO issues list business-IT alignment. It’s a noble and challenging goal – and it’s no longer the right goal! A combination of technology advances, advances in standards and architectures (mostly prompted by the Internet revolution) and the increasing IT literacy across the business means that the challenge has moved beyond Business-IT Alignment to Business-IT Convergence.

From Business-IT Alignment to Convergence

Let’s drill further into this convergence phenomenon. Today, many IT activities, including project management, information analysis, application configuration are devolving into Business Units while others are consolidating with support functions such as HR, Finance, etc.  Helping to drive this is the rapid consumerization of IT devices and services, with iPhone’s, iPads, Android devices and the like becoming an important window into business systems and information.  Further driving this is the increasing ‘IT Savvy’ and confidence with IT that business executives, line managers and workers (especially, knowledge workers) increasingly feel.  This is in part generational – people entering the workforce with high IT literacy, and in part a byproduct of people’s engagement through social media, e-commerce and so on.

From Owning to Sourcing IT Capabilities

The last decade or so has seen a shift from owning all needed IT capabilities (data centers, server farms, software teams, application development groups, desktop support, etc.) to sourcing these capabilities externally.  Today, traditional functional outsourcing is being continuously expanded, and now often includes Business Process outsourcing as well as the outsourcing of compute power, data storage, IT infrastructure, applications and platforms through the rapid rise of Cloud Computing.

Information is Becoming both Strategic and Implicit

Information is becoming an increasingly strategic asset.  There is compelling research data showing how companies are successfully embracing and competing on business analytics.  At the same time, data is also becoming implicit to business management and operations – increasingly representing what the business manages and how it manages. In many respects, the context for IT today is becoming less about IT and more about information – the ability to capture, integrate, interpret, predict, and act is increasingly the holy grail of competitive advantage – and that belongs in the business – not in a separate specialist group.

So, Where Do IT Capabilities Belong?

Now, I’m on dangerous ground, because the answer depends – on the nature of the business, IT savvyness of business managers and knowledge workers, and their vision for how they want to deploy and manage information and IT.  But, I’d argue that many IT capabilities belong in business operations.  For example:

  • Business Process Management
  • Business Analytics
  • Project Management
  • Satisfying Business Unit application needs

Other IT capabilities belong in the governance of the business.  This might include, for example:

  • Enterprise Architecture
  • IT Strategy
  • Portfolio and Program Management

And finally, some IT capabilities should be centrally coordinated and shared. Examples here include:

  • Common and shared IT Infrastructure
  • Enterprise Applications

So, What Are the Implications for IT Leadership and the IT Professional?

I will save that for a follow-up post, but suffice it to say that most companies and their IT organizations are not quite ready for the shift I’m espousing (and, indeed, predicting).  And, I think it is the clear responsibility of IT leadership to help lead this revolution – ensuring that it is orderly and safe – ensuring that the business and IT professionals are fully prepared and able to take advantage of business-IT convergence.

Please join me in the next post on this topic – and in the meantime, please weigh in with your perspectives and observations.

Painting by Joseph-Noël Sylvestre: The Sack of Rome by the Barbarians in 410

Enhanced by Zemanta

When Words Just Don’t Cause Change


I was in a heated ‘discussion’ with a client recently.  We had completed an IT strategy refresh and one of the outstanding items was to review their IT Principles.  The IT leadership team had come up with some candidate new Principles, and I was being asked if I thought they were appropriate.

“What Will You Do With The IT Principles?”

I asked, “What will you do with these IT Principles?”  The silence I was met with was palpable.  My client was too polite to say it, but I knew that in the silence he was thinking,  “Vaughan – you complete idiot!  A Principle is a Principle!  Having a Principle is the whole kahuna!  It has nothing to do with ‘what you do with them!”

The Pleasant Reassurance of New Words

This weekend, I saw a post by Seth Godin with the title above.  I knew I was going to like it – I like all Seth’s posts, and I LOVED this title!  This is what I found:

It’s a lot easier for an organization to adopt new words than it is to actually change anything.  Real change is uncomfortable. If it’s not feeling that way, you’ve probably just adopted new words.”

Short, and very sweet!

Giving IT Principles “Teeth”

I’ve posted before on the power of Principles, and in particular on Principles as a Problem Solving Tool.   To recap, there are three keys to making IT Principles valuable:

  1. Pick a few (say between 3 and 9) ‘points of pain’ that you want to try to address.  By ‘points of pain’ I mean something that is a significant performance inhibitor – often, this will mean it keeps surfacing as a root cause of some important dysfunctionality.
  2. Come up with a simple, direct and unambiguous statement that FORCES A CHOICE that would resolve the pain point.
  3. (And this is THE MOST IMPORTANT KEY!) Identify what will have to change in order that behaviors will change to come into line with the Principle.

Let me provide an example.  You have constant tension and debate around how much of the IT budget gets sucked into maintenance.  You’ve had good success getting prioritization of major new initiatives based on business value, but it is ongoing maintenance of existing solutions that is nickel and diming you to death!  You drill into root causes, ask a lot of “why’s” and come up with the recognition that the planning for new initiatives never takes the full life cycle costs into account.

This meets key #1 above – it’s a real point of pain!  You come up with a new IT Principle as follows:

We manage all business solutions and technology investments based upon total value of ownership – including total life cycle costs.”

This meets key #2 above.  But this is where I feared that my client was going to stop.  And this is where Seth’s words of wisdom about words were so salient.  It was going to feel good to the client’s IT leadership team to draft the words in the Principles – to debate over the language.  I imagine that once they’d been agreed upon, they’d be printed on posters or perhaps handy wallet inserts.  And that somehow these words would change things.  They won’t.  We need to address key #3 – what will have to change for us to act in accordance with this principle?

What Has to Change?

As an example:

  • The total cost of ownership of an IT asset and its value-contribution must be periodically calculated and tracked over time.
  • Requires closer alignment between program planning, project estimating,  budgeting and benefits tracking processes.
  • The cost of a new system should include the cost to retire the system it replaces.
  • Application retirement must be an active process.
  • The total cost of ownership must include both the business and technology costs of developing, deploying, and operating business solutions.
  • Costs such as hardware, software, maintenance, security, monitoring, training and on-going support must be included in the total cost of ownership.

These changes will have implications for business-IT governance processes, structures and reporting.  There may need to be new Policies.  There may need to be changes to rewards and recognition.  There may need to be changes to IT audit procedures.  And so on.

Remember, as powerful as words can be, they usually need the strength of structural, process, governance, rewards and recognition change to bring them to reality.  What say you about this?

 

Image courtesy of Drop Ship Access

Related articles
Enhanced by Zemanta

Some Consulting Principles to Live By…


The CEO of a firm I am affiliated with recently asked me what were my 3 top “principles of consulting.”   He was updating the firm’s web site, and thought this would be a useful addition to my profile.

It was an interesting question in that during some 30+ years of management consulting, I had never really sat down and decided what these should be.  At a subconscious level, I did indeed have a whole bunch, but had never really formalized them, or put pen to paper about them.  Going through the mental process of coming up with my top 3 was an interesting exercise, so I thought I would share them here – as much to get readers thinking about their own “working principles,” whether they are in consulting or some other discipline.  But some readers may, perhaps, also find my own principles instructive.  So, here goes!

Creating Client Capability is the Only Sustainable Approach to Management Consulting!

Many years ago I was with a large professional services firm.  They went through a massive strategic planning exercise (one that, I have to say, was rather effective in terms of impact on growth and profitability!)  One of the concepts that came out of the plan was to focus on the top 100 clients, and establish what was referred to as “annuity relationships.”  I was always somewhat troubled by this, in spite of the business results it led to.  (By the way, no surprise that this is a dominant strategy for most professional services firms.)  I remember a very uncomfortable meeting with a bunch of Partners to whom I was explaining a new service that was coming out of a 3-year multi-company research program on IT Effectiveness.   The new service effectively packaged a tremendous amount of intellectual capital about IT Effectiveness and Transformation and transferred that to our clients.

During my presentation, I had a feeling that my message was not being well received.  At the end of the presentation, as we moved into Q&A, one of the Partners angrily asked, “Vaughan, what on earth are you thinking of – you are going to kill our children!”  I was totally bemused by this comment and asked him to clarify his question.  “Vaughan, we make our livings on the back of incompetent IT organizations.  Why would we want to help them get better?”

I left the firm shortly thereafter to start a new consulting firm with a different value set.  Of course, we all want repeat clients and long term relationships.  But somehow doing that on the back of client dependency did not feel like the way I wanted to make my living!

Client Capability is Best Nurtured Collaboratively!

My most successful and enjoyable engagements have been with client teams – often with cascading networks of teams as IT transformation efforts take hold.  My least successful and enjoyable engagements have been when the CIO has wanted to work directly with me and not involve others (or involve them minimally).  Sometimes, there are good reasons to work this way – for example, when the CIO is about to replace his leadership team.  And sometimes the nature of the engagement is one-on-one coaching or counsel to the CIO.  But anything with broader implications – IT strategy, IT operating model, governance, transformation, etc. is, from my experience, far more successful conducted with and through client teams.  Which takes us to my third consulting principle…

Never Collude with Dysfunctional Client Behavior!

This one’s sometimes a hard one to live by, but every time I have ignored my instincts and gone along with some sort of dysfunctional behavior, I have regretted it!  Examples are clients who are sloppy about meetings – start late, end late, miss calendar appointments, and so on.  This is not at all uncommon.  And, of course, we all find ourselves dealing with exceptional circumstances sometimes – the freeway accident, the call from the CEO to come up to an urgent meeting.

But, in some companies, a pattern often emerges quickly, and it’s clear that this is indeed a pattern of behavior.  It’s tough to take this on, but when I have done so – either a direct confrontation (which, frankly, rarely solves the problem for long) or by “firing the client” (which either does work in that it leads to changed behavior, or works because I no longer have to put up with it!) I have always been happy to have stood my ground.

Psychologists talk about “enabling behavior” and that while this can be positive, it is often negative and ultimately destructive.  I believe it is also a trap that consultants can easily fall into and have to be quite deliberate about recognizing and avoiding it!

More insidious examples of dysfunctional behavior include poor decision making, or constant second guessing of decisions already made, or not being clear about accountabilities and expectations.  The pity of this is, these are issues you are sometimes hired to help fix, but you find that the person that hired you (e.g., the CIO) is actually the worst offender, and when confronted, is not prepared (or equipped) to change that behavior, but wants you instead to try all sorts of interventions with “his people.”

 

Do you have any favorite “working principles” you’d like to share?  Or reflections on my top 3?

Enhanced by Zemanta