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