Key IT Roles for Driving Business Value


Contract-to-Hire-BlogI’ve posted at length about the Business Relationship Manager (BRM) role as being key to driving business value from IT. But what other roles—typically under-served—work with the BRM in the pursuit of business value from IT?
In this post, I am going to introduce three dimensions of value realization than are important to driving business value. Along with those dimensions, I will discuss three roles that are associated with those disciplines.

Note: This post refers to roles. A role is not the same thing as a job. Think of a role as a ‘hat’ you wear if you meet certain qualifications (possess certain competencies). When you are qualified to wear a given hat, you have certain responsibilities and accountabilities. Roles, the competencies they demand, the processes in which they participate, and the ways they engage with other roles are all characteristics that are defined in an IT Operating Model. Some people will fill multiple roles, depending upon circumstances and needs.

Three Dimensions of Value Realization

So, how does IT increase its impact on Business Value Realization? There are three major value sources that the IT organization can impact:

Screen Shot 2014-06-26 at 1.21.31 PMLet’s examine each of these dimensions.

Shaping Business Demand

At low maturity, an IT organization is often referred to as “order takers” for business requests. One the face of it, this sounds customer-centric and responsive. However, the reality is that at low maturity, much  business demand yields relatively little business value. It’s also the case than when the business client has already figured out what they need before the engage IT (or if the business client has depended upon external consultants and vendors to tell them what they need) then the IT organization’s opportunities to add value are very limited.

If an IT organization is able to engage with their business partners earlier—to be proactive, not simply responsive, they can stimulate, surface and shape demand towards higher value opportunities. And these high value opportunities tend to suppress demand for low value activities, so more people are working on high value opportunities.

Shaping business demand is an important discipline for increasing IT maturity, and with it, driving more value from IT. Associated with this discipline is the role of Business Relationship Manager (BRM)—a role that sits between an IT organization and its business clients. In leading practice organizations, the BRM role (or whatever label it goes by) is focused on demand management, with an eye to elevating business value of IT.

Leveraging IT Assets and Information

At low IT maturity, much effort goes towards establishing a supportive, reliable and predictable infrastructure and the business applications that depend upon that infrastructure. Typically, these business applications go significantly under-leveraged. The cost, effort and business disruption associated with their deployment tends to lead to a mentality of “declare success and move on!” The business users need time to get back their breath. They also need to be shown new ways to leverage the platforms and the mountains of information they generate. Also, while IT organizations typically do a good job maintaining these business applications, there is no single role focused on managing their total lifetime value.

In order to increase maturity, architectural and asset management disciplines must be established around business applications, so as to create business platforms and products that enable business process improvement and innovation. Platforms are inherently extensible and readily leveraged—think about the iPhone as a platform, with open, published Application Programming Interfaces (API), the Apple Store and thousands of apps available to run on that platform.

The role responsible for these architectural and asset management disciplines is referred to as Product Management, and is an important aspect of reaching higher maturity and driving business value—ensuring that the full potential value of Business Platforms and Products is exploited and harvested. The BRM role works closely with Product Managers to help create the business appetite for new business capability that leverages the underlying business platforms and products.

Optimizing Business Use

While low maturity IT organizations focus on building, implementing and maintaining business solutions, as maturity increases the focus expands to help optimize the business value realized though using these solutions. This depends upon the discipline of Value Management, which in turn leverages competencies in Business Change Management and Portfolio Management.

There are several roles that are involved in Value Management—that of the Business Sponsor for a given initiative, Portfolio Manager, Business Change Consultant and, again, the BRM with their focus on demand management and business value realization.

In future posts, I will explore each of these disciplines and roles, and how these can be established as part of your IT Operating Model.

Note: My next on-line BRMP Certification courses are being held across 3 Mondays—July 7, 14 and 21, 2014 and 3 Tuesdays—September 2, 9 and 16 . For details, please click here.

Image provided courtesy of FreeDigitalPhotos.net.

 

 

About these ads

Common Failure Modes in Business Relationship Management – Part 2


hindenbergThis is the second in a series of  posts about common failure modes I come across in the deployment of a Business Relationship Management (BRM) role and/or capability.

In Part 1 in this series I discussed two common failure modes:

  • Failure Mode #1: Where the BRM is positioned as the “Single Point of Contact” between a provider organization (typically an IT organization) and their business clients. The Single Point of Contact role is often introduced in response to a common symptom—the business client is unclear who to contact for what. In other words, the root cause is lack of organization clarity, and the false belief is that by appointing a BRM (or whatever label you use) as a Single Point of Contact, the organizational dysfunctionality arising from lack of clarity will be mitigated.
  • Failure Mode #2: BRM As “Dumping Ground” when the BRM becomes a “catch all” for requests that nobody else wants to deal with, or that people are not sure who is supposed to deal with them. Again, lack of organizational clarity is a root cause here, and the types of problems this leads to are very similar to those identified above due to the Single Point of Contact failure mode.

Let’s look at a couple of other common BRM deployment failure modes.

Failure Mode #3: Strategic BRM when a Tactical BRM Is Needed

This is a very common BRM failure mode.  Here’s the common scenario:

For whatever reasons, a provider (typically, an IT organization) is seen to be not fully satisfying the demands and expectations of its business customers/clients (pick your favorite term—I’ve seen both terms as the preferred way of describing the entities a provider serves).  In response, the provider undertakes some type of capability improvement initiative (sometimes referred to as a ‘transformation’, ‘transition’, ‘realignment’, ‘refresh’, and so on.) The initiative often has several aspects, such as deployment of a Service Management Framework, Operating Model realignment, process management program, sourcing strategy, and deployment of a BRM role/capability.

Someone is nominated to lead the BRM deployment.  They do their research, perhaps retain some consulting advice, build their team, and with high hopes and a strong sense of “damn the torpedoes”, create and execute a deployment plan.

All this sounds reasonable, but the disconnect is that the vision of BRM to be deployed is that of a strategic relationship between provider and customer/client.  As such, the BRMs chosen to fill the role are relatively senior people, well-qualified to work with senior business executives with a focus on business demand shaping and business value realization. Meanwhile, Service Management, Operating Model realignment, Outsourcing, and so on are all underway. Just as a golfer determined to improve their golf swing knows, improvement initiatives are often accompanied by performance setbacks.  Imagine a golfer not only working on a new swing, but also using radically new clubs, a revolutionary new ball, wearing an innovative, experimental golf shoe, on a brand new course. With all these changes going on simultaneously, the performance degradation could take a while to pass through.

While the new BRM team is trying to foster new strategic partnerships, surfacing new, valuable, business demand, the ability for the provider to supply even basic services is seriously compromised. This is especially true with new major outsourcing arrangements, which can take a year to 18 months to settle down. The business partners quickly lose patience as the newly surfaced demand lays fallow in a backlog, and current services falter. It does not take long for one or both of two situations materialize:

  1. The BRMs get dragged into tactical firefighting.  This is ok, but it may be hard for them to reposition themselves back into the strategic role they were originally intended to fill.
  2. The BRMs are deemed to be not adding value—especially given that they are senior and relatively expensive resources.

Lesson 3: Don’t position the BRM as a Strategic when the context demands a Tactical BRM.

It is possible to migrate from Tactical to Strategic BRM, but it demands that the BRM has the competencies to be strategic, and it takes some skill and finesse to establish the medium to longer term vision for the strategic business relationship with the caveat that in the near term, the BRM will be part of the provider organization’s improvement efforts, and therefore mainly focused on essential, though tactical activities, such as service definition.

Failure Mode #4: Tactical BRM when a Strategic BRM Is Needed

This is less common than Failure Model #3 above, but is still quite common, especially when an organization has blindly followed the ITIL framework without sufficiently understanding their supply maturity context.  Here’s the scenario.

The provider has implemented a Service Management Framework such as ITIL, where they recognized they needed a BRM role. Some people from the Service Management function were appointed to BRM roles and deployed. The Service Management initiative has been effective, and the proverbial “lights stay on and trains run on time.”

After a while, the business customers/clients let the provider management know that their BRMs don’t add much value—things seem to work ok, and having folk in the BRM role seems like unnecessary overhead. Sometimes it is the provider management that comes to the conclusion that the BRM role has served its purpose and abandons it.

Meanwhile, there is little to no improvement in the business value that is realized from investments in the provider’s capabilities and assets. All the basics work well, the business’s ‘orders’ mostly get taken care of, but there’s a sense of general disappointment in the provider’s strategic and innovation capabilities.

Someone with the competencies and authority to be a strategic BRM can operate at a tactical level, but someone without those competencies cannot operate at a strategic level.  Tactical BRMs help to get the lights to stay on and the trains to run on time, but once those “table stakes” have been achieved, the tactical BRM will (to push the metaphor too far!) run out of steam!

Lesson 4: Don’t position the BRM as a Tactical when the context demands a Strategic BRM.

It is very difficult to migrate a purely tactical BRM to a Strategic role. They will be unlikely to have the experience and competencies to act as a true strategic partner, or to be granted the executive level access they need to be successful in the strategic BRM role.

What do you think?  What other failure modes have you seen?

 

Note: My next on-line BRMP Course is being held across 3 Mondays—July 7, 14 and 21, 2014. For details, please click here.

Enhanced by Zemanta

What’s Really Meant By Business-IT Engagement and How Do You Achieve It?


This is another post triggered by a reader’s question emailed to me.  Here’s his question (some details have been omitted to preserve anonymity).

I was searching for information around Business-IT engagement but have yet to really come across anything with substance.  I’m looking to better connect with the business unit managers to formulate an IT strategy. The unit managers have a track record of operating in their own silos, often making IT decisions without talking to IT which has ultimately cost the company money.  I was thinking about putting a plan together to engage. Structured via, face-to-face, email, social media, newsletter and even survey. Ultimately, from start to finish, I build the picture and connect and portray the message that IT is an enabler and there is benefit in engaging.  I wondered if you knew of anything which may help me?”

This is an interesting question and a common challenge.

What Do We Mean by Business-IT Engagement?

A little research into the term “Business-IT engagement” found a reference to “Employee Engagement“, which Wikipedia defines as:

An ‘engaged employee’ is one who is fully involved in, and enthusiastic about their work, and thus will act in a way that furthers their organization’s interests. According to Scarlett Surveys, ‘Employee Engagement is a measurable degree of an employee’s positive or negative emotional attachment to their job, colleagues and organization that profoundly influences their willingness to learn and perform at work’. Thus engagement is distinctively different from employee satisfaction, motivation and organisational culture.”

I don’t think it’s an unreasonable stretch to derive from this a definition of business-IT engagement:

Business-IT Engagement exists when business unit leaders are fully involved in, and enthusiastic about their IT capabilities, and thus will act in a way that furthers the business value of those capabilities.  Business-IT Engagement is a measurable degree of a business executive’s positive or negative emotional attachment to their IT capabilities, IT colleagues and IT organization that profoundly influences their willingness to participate in the use of IT for business value.”

IT Engagement Model

I also found an IT Engagement Model from our friends at the Center for Information Systems Research:

The IT engagement model is defined as the system of governance mechanisms that brings together key stakeholders to ensure that projects achieve both local and company-wide objectives. The model consists of three general components:

  • Company-wide IT Governance – decision rights and accountability of company level and business unit level stakeholders to define company-wide objectives and encourage desirable behavior in the use of IT
  • Project management – a formalized project management process, with clear deliverables and regular well-defined checkpoints, that encourages disciplined, predicatable behaviour for project teams.
  • Linking mechanisms – processes and decision-making bodies that connect project-level activities to the overall IT governance.

The Linking Mechanisms are further explained in the following graphic:

I find this to be a pretty comprehensive and easily understood way to define some of the major aspects of Business-IT engagement.

Key Business-IT Engagement Factors

The other key factors I pointed my reader to include:

  • The experience your unit managers have with IT – do they trust IT? Has IT served them reliably? Is there transparency into how IT charges?  Is the business value of IT recognized and celebrated?
  • How engaged are business and IT leadership with each other? Does the CIO sit on the Management Committee? Is there an effective business-IT governance board and related processes and structures?
  • The skills of those in the business-IT interface role (Business Relationship Managers, or BRM’s) – how well do they understand the business? Do they have good relationship skills? Are they co-located with the business unit leaders and sit in on business management meetings? Do they perform a business management role, or are they simply seen as technical people taking care of IT?  Are they primarily responsible for Demand Management?

To the balance of his question, I asked:

  • Are you really trying to formulate an IT strategy? Or is it going to be a business-IT strategy. (If I’m a business unit leader, why should I care about or want to be involved in an IT strategy – it sounds rather internal to IT to me, so I’d probably want to stay out of it – I’m busy enough as it is!)
  • Do you really understand the business problems and how IT can contribute to solving them? If you do, what’s the best way to “market” those ideas, and to whom should you be marketing them?
  • What are the cultural norms in the business – do ideas drift down from the top, or do they percolate up from the edges – the ‘front lines’?

Outside-in Versus Inside-out Thinking and Acting

Finally, I was troubled by an aspect of the language my reader used in his question:

I build the picture and connect and portray the message that IT is an enabler and there is benefit in engaging”

This is what I call Inside-out thinking – “We (IT) are good and can help you so you should engage with us!”  I think my reader might be on a better path to engagement if he can identify the specific business issues and needs and communicate how IT might contribute to addressing those issues and needs.

Don’t Engage – Empower!

Just as I was finalizing this post, Zemanta did its usual thing of suggesting links and related articles.  (I really like Zemanta – it’s been one of my little blogging secrets for a while!)  Among its suggestions for articles was Don’t Engage Employees, Empower Them!  I think that is an important dimension to Business-IT engagement – especially in this age of IT consumerization.   Too many IT leaders see there role as ‘protecting the business from the perils of IT.’  Empowering them – for example, Bring Your Own Device (BYOD) can be a powerful way of bringing the business into the business-IT dialog and engaging them in strategic and tactical dialog and decision making.

Graphic courtesy of People Insight and licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

 

Enhanced by Zemanta

Questioning the Role of the Business Relationship Manager


I’ve been deeply into understanding and developing the role of Business Relationship Manager (BRM) since the early 1990′s when, as a Partner at Ernst & Young’s Center for Business Innovation, I began researching what was then an emerging role.  Since then, I’ve continued research into this important role, led many consulting engagements helping companies implement or improve the performance of the BRM role, and have been on the faculty for several global BRM development programs.

More recently, I’ve been a co-moderator of the Professional Business Relationship Manager Group on LinkedIn.  This has been a fascinating experience for me – some very interesting dialogs surface from time to time, and the diverse opinions and approaches to the BRM role become ever more evident each day.  Also, the sheer growth of this group over the last couple of years is remarkable, and speaks to the growing importance of the BRM role.

What is a Business Relationship Manager?

First, it is important to understand that this is a role, not a job title.  In fact the job titles for people who fill this role vary enormously.  Adding to the confusion around titles, “Relationship Manager” is a common title in banking, and we get a lot of applications to join the LinkedIn group from banking officers – not the intended audience!  Also, a number of pure “sales” jobs call themselves “relationship managers.”  I don’t have a problem with that, but it’s not the focus of the BRM group.

Second, the ways that the BRM role is implemented varies significantly.  Sometimes it is a sole practitioner – other times, the BRM leads a small team (anything from 1 or 2 business analysts to a larger team, including architects and even developers.)  Sometimes the BRM reports to the IT organization – typically as a direct report to the CIO.  Other times, it reports to a business leader – perhaps with a dotted line relationship to the CIO.

No matter what the variations in organization and structure, the common thread across BRM implementations is an interface between business and IT.  The common goal (though expressed and measured in myriad ways!) is to increase the value realized from IT investments (typically, new initiatives), assets (usually current systems and infrastructure) and capabilities (the services and products offered by the IT organization.)

This “interface” responsibility implies two ‘faces’ of the BRM role:

Representing the Business to IT

This is one of the BRM ‘faces’ – representing a given business unit (or units, or business process, or geography) to IT.  In this regard, the BRM’s primary role is in shaping and surfacing business demand – always with an eye to maximizing the business value of IT investments, assets and capabilities.

Representing IT to the Business

This is the other BRM ‘face’ – representing IT to the given business unit(s).  In this regard, the BRM’s primary role is in supply management – ensuring that the IT organization understands business needs and expectations, and is delivering against those expectations.

But, What is the Real Rationale for the BRM Role?

Implicit in the many debates I see in the BRM community (and behind some of the failures I see in making the BRM role successful) is the question:

What is the most important aspect for the BRM to focus on – demand management or supply management?”

There is no easy answer to this – it really is a function of both supply and demand maturity.  But, I will make some assertions based on a great deal of experience:

  1. If supply maturity is low (i.e., basic IT services are unreliable, unpredictable, unstable, unclear) the BRM role will almost certainly fail.  It cannot add real value, spends it’s time apologizing for IT and making excuses, and is quickly seen by the business partner as “overhead.”
  2. If supply maturity is moderate (i.e., basic IT services work well, but capacity is highly constrained, projects take too long to deliver and are prone to delays) the BRM role has to play a careful balancing act – stimulating and shaping demand while living within the constraints of supply.
  3. If supply maturity is high (i.e., a well regarded IT organization that delivers basic services and project work; that has ‘elastic’ supply that can flex with demand and can deliver with ‘agility’) the BRM role can and should focus almost exclusively on demand shaping and surfacing.

Of these three situations, scenario 1 is the most treacherous for the BRM.  It’s essentially a losing proposition.  My advice to clients is, “Don’t put BRM’s in place – fix the basic services first!”

Scenario 2 takes a great deal of finesse.  The temptation for the BRM is to either try to fix the problems of supply, or shield the business partner from those problems.  Fixing supply is best done with those on the supply side who are responsible and accountable for IT supply.  If you put the BRM in that role, they can’t be effective in their demand management role.  Once their business partners see them as part of the supply side, the BRM loses their credibility as valuable demand shapers.

Why would I invite you to my leadership team strategy retreat – you’re the person who’s fixing IT services!” might be the reaction of a business leader to a BRM who has asked to join the business unit’s strategy formulation retreat.

On the other hand, shielding the business partner from supply side woes is also a trap – what I refer to as “colluding with dysfunctional behavior” which is never a good idea!

Scenario 2 also takes great skill with the discipline of ‘value management’ – understanding how IT investments, assets and capabilities lead to business value – making sure that the constrained supply is working on the highest value possibilities, ensuring that low value requests do not get through the intake process and that value is actually ‘realized’ – felt and seen by the business.

Scenario 3 is the ‘holy grail’ for the BRM.  Unfortunately, by the time IT supply has reached that level of maturity, so has business demand, and the BRM role may be redundant.  But that’s a story for another post…

Enhanced by Zemanta

COBIT – Good News… Bad News!


COBIT is described by its creators, ISACA, as a “Framework for IT Governance and Control.”  Celebrating it’s 15-year anniversary, COBIT provides an excellent framework for helping bring IT under control.  In ISACA’s own words:

COBIT is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks. COBIT enables clear policy development and good practice for IT control throughout organizations. COBIT emphasizes regulatory compliance, helps organizations to increase the value attained from IT, enables alignment and simplifies implementation of the COBIT framework.”

With Version 5 being released this year, COBIT 5 will consolidate and integrate IT value delivery and IT risk management into the COBIT 4.1 framework.

So, You Want to Increase IT Maturity?

For IT shops of relatively low maturity, COBIT provides an effective framework and body of intellectual capital for implementing or improving IT processes and controls.  It can help avoid a great deal of ‘reinventing the wheel’ that so many IT shops get into, developing IT processes from scratch, or living with processes that do not integrate properly and propagate IT organizational silos.  The danger here, though, is that simply licensing a set of process descriptions is by no means equivalent to adopting them.  If people don’t really understand the processes they are supposed to be following, or if they aren’t completely bought into the need for and value of those processes, then having scads of process descriptions and related documents is not going to ensure a controlled IT environment.

Oh, You Want to Reach High IT Maturity?

I have blogged at length about Business-IT Maturity and have described a simple 3-stage model of both Business Demand Maturity – the business ‘appetite’ for IT, if you will, and IT Supply Maturity – the necessary IT capabilities to satisfy business demand (at lower maturity) and to shape and stimulate business demand (to reach higher maturity).  I’ve also written several posts on what I refer to as ‘sticking points‘ or traps that IT organizations fall into when they are in the middle levels of business-IT maturity. (I’m reminded of the proverbial ‘gumption traps‘ that Robert Pirsig so eloquently describes in his exploration of the metaphysics of quality, Zen and the Art of Motorcycle Maintenance.)

Unfortunately, I’ve found that COBIT can easily create one such trap.  While it can be an effective way to get from Level 1 to Level 2 maturity (on the 3-stage model), it will not take you from Level 2 to Level 3, and can, in fact, inhibit movement towards high business-IT maturity.

Let me try an analogy.  Imagine a car driver who is taught how to drive around a city and diligently follow all the rules and regulations of the road, including speed limits.  Then put that driver into a racing car and expect them to keep up with other racing car drivers on a race track.  Not only will they be unable to keep up, they will likely wreck the car and hurt themselves, unaccustomed as they are to the finer points of fast driving, and unskilled in high speed steering techniques.  Note, the racing car driver is still perfectly able to drive in the city and be compliant with the rules of the road, she has learned additional skills to win races and avoid high speed crashes.  Our novice, city-trained driver has not learned these skills.

This is the COBIT trap – it will take you so far, but, absent further skills and enhanced processes, will not take you further.

I’m expecting this post to be controversial, and the COBIT bigots to attack my heresy, so please, bring it on!

Enhanced by Zemanta

Account Teams and Business-IT Relationship Management


I’ve posted quite frequently on this blog about the role of the Business-IT Relationship Manager. It’s a key role – crucial, in fact, at mid-levels of Business-IT maturity.  It’s a role that typically does not work well at lower maturity, yet is essential to reaching higher maturity. It’s also a role that is hard to get right!  But went you get it right, it can contribute significantly to business value realization from IT assets and investments.

An Account Teaming Approach to Relationship Management

I’ve found myself re-immersed in the Relationship Management (RM) domain lately.  I’m working on a significant RM development program with one current client, and helping another client fine tune their IT Operating Model.

With the first client, I got involved in a benchmarking exercise, going back to two former clients where I had led extensive RM training a few years back.  The purpose of the benchmarking was to find out how their RM approach had evolved, what was working well, and where they still had challenges.  In both cases, the clients had converged on an Account Management Teaming approach – essentially, a set of business unit-facing account teams comprising a very senior Relationship Manager (rarely called that, by the way), a Solutions Manager and an Enterprise Architect.

In the client where we are fine tuning the IT Operating Model, one such account team had formed fairly naturally.  Nobody told them to organize that way.  One of the RM’s met with a business architect and a solution manager and decided they needed to set time aside to meet and talk and strategize in order to present a cleaner, simpler face to the business client.  They wanted to be more deliberate and proactive in shaping business demand rather than simply respond to it.  They saw the formation of the account team as a sort of experiment.  They did not ask permission – just went ahead and tried it.  (I’d describe this as a fairly sophisticated client in an information intensive industry, with an exceptional quality of IT leadership and management.)

This Seems to be Working – Let’s Generalize It!

I met recently with the account team and other architects, RM’s and solution managers to talk about how to generalize the model and duplicate it for the other business units and their RM’s.  We analyzed what had changed as a result of the account team approach – both from the perspective of the individual IT roles, and from the business client’s perspective.  It was an impressive story with impressive results.

So, how to ‘codify’ the approach and generalize it?  The responses from the account team members were surprising and distressing on the one hand, yet obvious and comforting on the other.  Their counsel was, “Don’t try to codify this too much.  It won’t work!”  and, “Remember, we formed into a team because we wanted to, not because we were told to!”

Not So Fast, Tonto!

The business-IT interface is an extremely complex space.  The Account Teaming approach works because it is organic, and was emergent.  It works because the team members have mutual trust and respect.  It is the role of the team that is important and brings the magic, not the roles of the team members.  They talk about “having each others backs covered.”  About the fact that the client executives know that they can talk to any of the team and reach the whole team at the same time.  About the fact that any business-IT conversation quickly and automatically gains the perspectives of enterprise architecture, solution delivery and relationship management.  The business executives don’t need to be concerned about who to call for what.  Nor do they have to sit down with five IT folk to get anything done!

The Power of Self-Organization

Ralph D. Stacey, in his great book, “The Chaos Frontier” defines Self-Organization as:

A process in which the components of a system in effect spontaneously communicate with each other and abruptly cooperate in coordinated and concerted common behavior.”

I believe that viewing organizational spaces such as the business-IT interface as a complex system, operating at the ‘edge of chaos’ (scientifically speaking) reveals the insights that:

  1. Variety, randomness, paradox, information, and interconnection are sources of creativity.
  2. Organization is a natural, spontaneous act – to force otherwise is not sustainable or effective.
  3. Systems have a capacity to self-organize to great effect – given the opportunity to do so.

The danger feared by the Account Team was that as an organizational consultant, I would take the model and create organizational charters, role descriptions, competency models, and so on, and in so doing squeeze the life out of the account team concept.  And I use the word “life” deliberately.  Everything we know about complex emergent behavior tells us that for life forms such as this type of account team to really work, they have to behave like living organisms – with porous boundaries, guided by a common sense of mission and purpose, a ‘genetic code’ if you will, not sealed off from their world by hard boundaries and deterministic rules.

Image courtesy of The Savvy CIO

Enhanced by Zemanta

Four Common Mistakes in IT Portfolio Management


Among my most popular topics, week after week, is Portfolio Management.  It’s a key discipline, especially crucial in driving Business-IT Maturity past the tricky mid-point where many IT organizations tend to get stuck.

IT Business Edge has just published a short slideshow on “Four Common Mistakes in IT Portfolio Management“, re-purposing a post of mine from January 2008.  I think they did a great job simplifying and bringing to life some of the key points in the original post.  Enjoy!

Enhanced by Zemanta

Increasing Business Value Through Demand Shaping


walk-past-no-coffeeA key role for IT leaders, especially during recessionary times, is Demand Shaping.   A perennial reality in the business-IT world is that demand seems to exceed supply.

Of Backlogs and Early Cloud Computing

When I entered the field of IT back in the 1960′s, the term “backlog” was pervasive – that huge list of requests we could not get to until supply resources freed up.  Around the same time, and partially as a result of these huge backlogs (often measured in months or even years!) time-sharing and service bureau’s were the rage.  Often they would install terminals for you for free, provide access to so-called Fourth Generation Languages, data analytics, simulation and modeling tools, and let you “pay by the drink.”

Long term, this may not have been the most cost effective approach, but it let “end users” (as we called them back then) get access to the tools and computing power they may not have otherwise had access too.   I remember doing some work for a large enterprise that ran movie theaters.  I needed to model the economics of dividing up cinemas from single screen (which was the only model in the UK back then) into mutli-screen theaters – an approach called ‘multiplexing’ today.  I used a financial modeling tool called PROSPER through a service bureau.  I was learning the tool while I was building the model, so it took me a while to get it all working.  I remember getting to my 30th iteration of the model before I saw the first service bureau invoice, and on seeing all the zeroes following the pound sign, realizing that, “I had some splainin’ to do” as Ricky Ricardo would have said at the time!

But the results were important to the company, and they were happy to pay the invoice without complaint as it validated a major strategic shift for them, and they became one of the pioneers of the new movie theater model in the UK, capturing significant market share from competitors, and driving great profits for many years.  Had I responded to their request for the analysis with, “IT does not have the capacity just now, we’ll get to it in 18 months,” at best, I’d have had an unhappy customer.  At worst, we’d have watched a competitor beat them to the punch!  On-demand, cloud computing (in its earliest form) provided me the flexibility to satisfy demand without capital investment or undue delays.

Shaping Demand Rather Than Accepting It

Perhaps the more interesting story behind the cinema multiplexing modeling story above is how it came about.  I was at the time a Systems Engineer for ICL – then the leading British computer company.  I was working with a Sales Engineer.  The movie theater enterprise (actually, this was just one business in a broad range of consumer businesses) was his key account, and he was working hard to convince them to buy a larger computer.  He came up with the strategy of multiplexing (I think he’d been to the US and had first seen it there) and took the idea to his customer with the offer to find a free resource (yours truly!) and do the necessary modeling to analyze the financial implications.  (Note the irony here that we both worked for Britain’s largest computer company and that I had to go to a service bureau to get access to the computer cycles!)

The point is, that sales executive was shaping demand for his customer – bringing ideas to create demand.

Two Ways to Drive Business Value Through Demand Shaping

In the example above, demand shaping was through the relationship manager bringing ideas to his customer.  This is a technique familiar to all of us (at least, in the US) used by pharmaceutical companies to let us know about medical conditions we may not even be aware of and for which they have a potential remedy – even if we can’t go out any by those remedies.  We have to ask our doctors whether the treatment is appropriate for us.

The second method those in relationship management roles use demand shaping is when the customer tells us their ‘demand’ and we deflect it by suggesting a solution that might be of higher value, or, at least, pointing out that the requested ‘demand’ may not deliver value sufficient to justify the need.  This is the more common opportunity for demand shaping, and typically the trickier role to successfully pull off.  If we are not careful, it can be seen as being unresponsive or uncooperative.  It might mean elevating a one-off and/or siloed need to a more enterprise-wide solution.

Anne, that’s an interesting request, but perhaps we can kill several birds with one stone if we provide a solution that addresses more than the needs of your department?”

To the customer, that might mean delays as we work through enterprise-wide governance processes, or work the politics to enroll other departments in the solution.  In these cases, pushing back by the relationship manager requires intestinal fortitude, skills in the art of persuasion, and political savvy.  But such is the lot of relationship manager – shifting from ‘order taker’ to ‘valued business partner’, from ‘account executive’ to ‘agent of enterprise solutions and business value.’

How often are you simply in the role of order taker?  What could you do differently to position IT capability for value realization?

Getting Control Over Business Demand – How to “Just Say No!”


just-say-noDid you ever feel that some of the things you are asked to do by your business partners just don’t make sense?  That they won’t deliver value that truly justifies their cost?  I find this to be a common issue.  And it’s not just the questionable value associated with some of these requests.

Low value demand:

  • Carries with it an opportunity cost – resources working on clarifying and satisfying low value demand are not available to stimulate and satisfy higher value activities.
  • Fosters a ‘master-servant’ and ‘order-taker’ relationship between business and IT which in turn limits that relationship’s ability to grow into a more strategic and value-creating partnership.
  • Order-taking behavior misses out on important opportunities to raise business-IT savvy – to raise business awareness of information and IT possibilities for value creation, or to raise IT awareness of where and how the business can leverage information and technology in important or significant ways.
  • Typically backfires on IT by creating an undercurrent sense that ‘IT costs too much and delivers too little’.
  • Creates the feeling that the person taking the order adds only cost, not value, to the business-IT relationship, often leading to a vicious cycle of weak relationship managers not receiving the training and development they need to be more effective.

I think there are all sorts of historical reasons why we get into this bind, mostly associated with low business-IT maturity on which I’ve commented substantially over the last 15 months or so.  But I believe the economic downturn presents a wonderful opportunity for the IT professional to get back in front of, and in control of business demand.

Saying ‘No’ by Saying ‘Yes’

As nonsensical as this sounds, there are ways of saying ‘no’ that don’t sound like ‘no’ and can lead to a far more constructive conversation and a more productive outcome.  I’ve worked with The Second City improvisation group in client workshops, where they taught us the simple skill of re-framing a  ‘No” into a “Yes, and…”  With a little practice and the right mindset, you can take a low value request (e.g., please produce a report that shows sales trends by sales person by region over the last 6 months) and turn it into something with a lower cost-to-serve, higher business value, and an improved customer experience.  “That sounds like a useful report, and my guess is that in the current economic climate, you’re going to be needing all sorts of analyses to help drive sales performance improvement.  Given that, perhaps it would be more useful to you if we created a data warehouse with all the current and historical sales data, and showed you how to use the report-writing tools to create just about any report you are going to need.  Let me show you an example of how easy that is, and how empowering it can be – you’ll be a company hero for your understanding of the sales data, and your insight into what it means!”

Now, my example is, of course, trivial, but hopefully provides a sense of what can be done.  Saying ‘no’ is typically seen as non-constructive, lacking service orientation, obstructionist and generally annoying.  Rejecting a bad idea by smoothly and collaboratively turning it into a good idea is seen as constructive, service oriented, and satisfying.

Think back over times when you’ve had to say ‘no.”  Think about those times when you finessed the situation, using your best zen instincts that led to a positive outcome?  Compare those examples to the times where you were less elegant in how you handled the situation.  Could you have offered a better alternative?  Could you have better explained your rationale?  Could you have made the requester feel better about the outcome?  Finally, look for opportunities to practice and use this skill.  To quote Standford Professor Paul Romer, “A crisis is a terrible thing to waste!”

Why IT Might be Slow to the Web 2.0 Collaboration/Innovation Party


partyLately I’ve been spending time with several IT teams from global Fortune 500 enterprises who are charged with fostering collaboration, innovation and the other hoped-for outcomes of Web 2.0.  It’s been a fascinating experience – plenty of good news, but some aspects I find frustrating.  More importantly, I believe these are things that are slowing progress in exploiting Web 2.0 et al in the enterprise context.

For most companies, the necessary infrastructure, while mostly in place, is not fully there.  Desktop software may not be at the right level.  Videoconferencing capabilities are first or second generation, and need to be upgraded to tap the full potential of today’s telepresence and high definition video.  Instant messaging, previously banned as a perceived “renegade, redundant and dangerous technology is now seen as a useful tool, but the IT infrastructure must now be tweaked to embrace it.  Early implementations of SharePoint that served as interesting experiments, must be updated and redeployed to take advantage of the latest release and goodies.  More complex initiatives such as virtualization, unified communications, shifts from perimeter-based to asset-based security take time, energy and investment to sort through.  Collaboration strategies tend to be emergent rather than holistic,
IT- more than business-centric, push rather than pull, infrastructure rather than application focused.

The good news is that for the more forward-thinking companies, these infrastructure initiatives are funded, resourced and underway.  The people leading them are the best and brightest from the IT infrastructure ranks – they know what they are doing, and move assuredly through this complex space, checking off important milestones, and celebrating successes along the way.

The more frustrating, and ultimately limiting aspects are around the demand management (especially, stimulation/seeding) and application (especially value capture) of Web 2.0 – how to ensure that the emerging collaboration infrastructure is actually used, and used productively and creatively.

A couple of points.  Without the right infrastructure, Web 2.0 doesn’t work, or doesn’t work well enough to sustain itself – it is the table stakes.  But, a shyness in addressing the broader landscape of collaboration and innovation across the enterprise and its ecosystem ultimately limits the value of the infrastructure.

I use the word “shyness” with some thought – there is literally a shyness about getting into things that are thought of as “really needs to be in the business.”   The Catch-22, however, is that without IT leadership in demand shaping/management, you might not have the exact infrastructure you need to really tap the power of the emerging collaboration capabilities.  And I’m taking “infrastructure” quite broadly to include all the shared components and services that support Web 2.0 and its inevitable implications (e.g., Cloud Computing).

So, my recommendations to these teams typically include:

  1. Keep going with the infrastructure plans and deployments!  Celebrate the infrastructure, market its capabilities, keep up the great work!
  2. Step back and look at your broader collaboration strategy.  What other projects or programs are underway that impact or are impacted by this initiative?  What other projects or programs are needed to ensure success?   What does success look like?  How would we measure it?
  3. Add a demand shaping/demand management perspective to the collaboration initiative.  Wrap it into the overall collaboration strategy and plan.
  4. Expand the collaboration initiative team and brief/charter to bring in the business and customer/user perspective, and some “Net Gen” people or really understand how the Web 2.0 world works in the social/consumer space.
  5. Foster adoption from the grass roots up.  Think “chaos theory” and “emergence” – but don’t lose sight of the fact that we are human and ultimately, political and social animals.