Category Archives: IS Management

The management of the Information Services Organization – the formal organization charged with managing IT assets and capabilities

Design Thinking and Emerging IT Roles


designthinking

This is the third and final part in a multi-part post inspired by Robert Pirsig’s masterwork, Zen and the Art of Motorcycle Maintenance.  In Part 1 (titled “Reflections on ‘Zen and the Art of Motorcycle Maintenance’ 38 Years Later “) I discussed the implications for IT professionals of Pirsig’s musings on ‘classic’ versus ‘romantic’ worldviews, and his struggle to resolve these.

In Part 2, (titled “Zen, Motorcycle Maintenance, Design Thinking and Information Technology”) I teed up my observation that this classic-romantic balanced approach is embodied in the “design thinking” movement, popularized by Tim Brown and Ideo and exemplified by companies as diverse as Apple, Proctor & Gamble, Herman Miller and GE.  I discussed why Design Thinking is becoming increasingly important to the IT profession.  Among the reasons for the rising importance of Design Thinking in IT:

  1. Thanks to the likes of SAP, Oracle, et al, and the growing base of cloud-based ‘applications as a service,’ most of the opportunities to improve or automate transactional business processes have been exploited.  Today, businesses are increasingly searching for product, service and business model innovation.
  2. As we accelerate the move from custom development to personal apps, reuse, and “mash-ups,” much more emphasis is placed on synthesis rather than analysis – leveraging widgets and components rather than coding solutions from scratch.

I will pick up in this final part where I closed Part 2, with a discussion of three roles that are key to instilling Design Thinking in an IT organization.

Key Roles for Design Thinking in IT

Achieving the classic-romantic balance in discovery and solutioning involves many IT roles, but there are three roles that I believe are key:

Roles – Not Necessarily Jobs!

Before we examine these roles and how they work together, I want to emphasize I am talking about roles, as opposed to jobs.   The distinction is important in that the notion of organizing around roles imparts flexibility and variety for a workforce, whereas jobs tend to constrain people in boundaries defined in job descriptions.  An individual typically will hold only one job, but may fill multiple roles.  For example, my job is Principal in a consulting firm.  In some engagements, I am the Engagement Lead.  In others, I might be a Subject Matter Expert.  In still others, I am the Client Relationship Officer.  Beyond engagements, I might be a Research Program Leader or a Research Associate.

Also, these roles are typically instantiated with all sorts of labels – rarely the label I’m using here.  For example, I’ve worked with Business Relationship Managers (BRM’s) who were called Business Partner Director, Account Manager, Client Relationship Manager, IT Business Partner, Business IT Partner, IT Demand and Account Manager, Client Engagement Director, and so on!  And the specific missions, visions and implementations of the BRM role has been as varied as their titles!

Nevertheless, let’s drill into these roles and how they relate to each other and to moving IT to more of a Design Thinking philosophy.

Business Relationship Manager

I’ve posted extensively on this role in the past – it’s the role that sits between the IT organization and its business clients.  As such, it both represents the business clients to IT, and IT to the business clients.  This role has surfaced over the last 10 years or so.  I don’t know what percentage of IT organizations have this role today, but as an indication, LinkedIn hosts 2 groups dedicated to the role.  One group – IT Business Relationship Management - currently boasts over 1,800 members.  The other group, Professional Business Relationship Managers currently has over 2,600 members!  (In the interests of full disclosure, I co-manage the latter group.)

As the bridge between the business and the IT organization(s), the BRM plays a key role in moving above and beyond the traditional “requirements analysis” to an approach to discovery and solutioning that is more:

  • collaborative
  • abductive
  • experimental
  • integrative
  • outside-in
  • human-centric
  • innovation-biased approach

As such, the BRM has to understand Design Thinking, and ensure that the qualities listed above are brought to the table and play together effectively and efficiently.  The BRM herself does not have to be expert in these qualities, but must be an effective “broker” ensuring that people with the needed competencies and incentives are at the table.  These competencies will often be found in the other two emerging roles – those of Enterprise Architect and Product Manager.

Enterprise Architect

As with BRM’s, Enterprise Architects (EA’s) come in all sorts of flavors with a variety of titles.  The major distinction I would make is with what are generally called IT Architects.  Enterprise Architects are clearly focused on the business, business models, major business processes, business-IT platforms and the ecosystem within which the business operates.  IT Architects, by contrast, are focused on the technologies, their standards and how they inter-operate.

Wikipedia defines Enterprise architecture (EA) as:

… the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.

Practitioners of EA call themselves enterprise architects. An enterprise architect is a person responsible for performing this complex analysis of business structure and processes and is often called upon to draw conclusions from the information collected. By producing this understanding, architects are attempting to address the goals of Enterprise Architecture: Effectiveness, Efficiency, Agility, and Durability.

As with BRM’s, the EA role has been growing in prominence over the last 10 years or so.  Typically, it is complementary to the more technical roles of IT Architect, Information Architect, and so on.  Also, as with BRM’s there is little that is ‘standardized’ about the EA role, and by many measures it is something of a stretch to use the term “profession” when talking about EA’s, in spite of the efforts of bodies such as The Open Group Architecture Framework (TOGAF®), and my old friend, John Zachman and his Zachman Framework for Enterprise Architectures.

Again, as with BRM’s, LinkedIn is home to an Enterprise Architecture Network, with an astounding 85,000+ members!  As an example of the passion exhibited by this group, a recent comment that stated, “EA is often left in IT because it can only handle tame problems” garnered 572 comments!

At its best, the EA helps bring to the business-IT discovery and solutioning table some of the competencies from my bulleted list above.

Product Manager

The third role in the triad that can help IT organizations introduce more Design Thinking into their activities is that of Product Manager.  This role is far more scarce in IT organizations than either BRM or EA.  It is, however, universal in product companies, including information technology product companies.  Wikipedia defines Product Management as:

…an organizational lifecycle function within a company dealing with the planning, forecasting, or marketing of a product or products at all stages of the product lifecycle.

The role consists of product development and product marketing, which are different (yet complementary) efforts, with the objective of maximizing sales revenues, market share, and profit margins. The product manager is often responsible for analyzing market conditions and defining features or functions of a product. The role of product management spans many activities from strategic to tactical and varies based on the organizational structure of the company.

While involved with the entire product lifecycle, the product management’s main focus is on driving new product development. According to the Product Development and Management Association (PDMA), superior and differentiated new products — ones that deliver unique benefits and superior value to the customer — is the number one driver of success and product profitability.

Of particular note, Wikipedia goes on to note that:

Product management often serves an inter-disciplinary role, bridging gaps within the company between teams of different expertise, most notably between engineering-oriented teams and commercially oriented teams. For example, product managers often translate business objectives set for a product by Marketing or Sales into engineering requirements. Conversely they may work to explain the capabilities and limitations of the finished product back to Marketing and Sales. (Emphasis added.)

The Design Thinking Triumvirate

So, the keys to getting more Design Thinking into Business-IT solutions lies in the triumvirate of Business Relationship Manager, Enterprise Architect and Product Manager, with the BRM as the broker and orchestrator of these roles.  There are, of course, other roles played – e.g., business analyst, project manager, program manager, and so on, but I wanted here to focus on those roles which are less common but in the ascendancy.

Graphic courtesy of Green Hat Group

Related articles
Enhanced by Zemanta
About these ads

Book Review – The CIO Paradox: Battling the Contradictions of IT Leadership


I’m often asked to review new books – I usually decline.  There’s a couple of reasons why I stay away from book reviews:

  1. It’s just not what my blog is about – there are many sites that do a great job reviewing books, and I love the “wisdom of the crowd” effect you get from customer reviews on sites such as Amazon.com, so I don’t feel the need to add my own voice to the book review universe.
  2. I’ve been asked to review some books that were real clunkers!  I felt an obligation to say something (after all, the author has had a hand in getting me a review copy!) but I wanted to keep my authenticity, so I tend to end up “damning with feint praise” as they say!  (e.g., Fred’s book is nothing if not short!”)

Notwithstanding the above, when the request to review The CIO Paradox by Martha Heller came in, it was accompanied by sufficient clues as to its content (including a table of contents and a sample chapter) to convince me I’d enjoy reading the book, and have no problem creating an honest review.  It also helped that I was familiar with Martha’s writing for CIO magazine, including her first article on the CIO Paradox back in 2009 – a piece that resonated strongly with me from my work with CIO’s.  I suspected this book would be of value to my readers.

The CIO Paradox

Martha sets up the book with a question she started asking CIOs in 1999:

When you walked into your most recent CIO job, what did you find?”

She almost always got the same response:

I inherited a mess. IT had no credibility with the business. Projects were overdue and over budget. We had no project management discipline, no governance, no career paths, and the team had outdated skills.”

Thirteen years later, Martha points out, she is still asking the question, and getting the same response. CIOs continue to inherit a mess.  She goes on to ask:

How can this be? How can CIOs strive tirelessly to improve their IT organizations only to leave “a mess” in their wake? … is there something so inherently problematic about the CIO role that even talented, intelligent, and experienced leaders have trouble making it work?”

Great question!  From her work with the CIO Best Practice Exchange and the CIO Executive Council and as an executive recruiter, where she talks to hundreds of CIOs and helps them build their teams, she concluded that there are a set of paradoxes – conflicting forces that are deeply embedded in governance, staffing, executive expectations, and even corporate culture.  She groups these into four major categories which become 4 major sections of the book:

Your Role

  • You were hired to be strategic, but spend most of your time on operational issues.
  • You are the steward of risk mitigation and cost containment, yet you are expected to innovate.
  • You are seen as a service provider, yet you are expected to be a business driver.
  • IT can make or break a company, but CIOs rarely sit on corporate boards.

Your Stakeholders

  • You run one of the most pervasive, critical functions, yet you must prove your value constantly.
  • Your many successes are invisible; your few mistakes are highly visible.
  • You are intimately involved in every facet of the business, but you are considered separate and removed from it.
  • You are accountable for project success, but the business has project ownership.

Your Organization

  • Your staff is most comfortable with technology, but must be good with people.
  • Your staff is doing more with less, but must make time for learning finance and the business.
  • You develop successors, yet the CEO almost always goes outside to find the next CIO.
  • You are forced to seek cost-efficient overseas sourcing, yet you are expected to ensure the profession’s development at home.

Your Industry

  • Technology takes a long time to implement, yet your tool set changes constantly.
  • Technology is a long-term investment, but the company thinks in quarters.
  • Your tools cost a fortune, yet they have the highest defect rate of any product.
  • You sign vendors’ checks, yet they often go around you and sell to your business peers.

Leading and Interesting Practices

For each paradox, Martha shares leading and interesting practices from CIOs.  She names names, and writes clearly and insightfully about approaches that have worked – some simple, some more involved.  This makes for an easy and interesting read.  It also provides a comprehensive compendium of improvement ideas to consider.

A Suggestion for a “Meta-Practice” Based on The CIO Paradox

As I was reading the book, thinking back over my many years of management consulting and helping my clients think through and address some of these paradoxes, I found myself running through a thought experiment.  In the experiment, I had some of the IT leadership teams I’d worked with read the book.  Then they’d come together for a one-day retreat, where they’d discussion questions such as:

  • Which CIO Paradox have we made the most progress on solving?  What were the keys to our success?
  • Which CIO Paradox seems like it is the toughest for us to solve, and why?
  • Which practices suggested in the book should we be implementing, and how?

A variation on this theme would be to share the book with senior business executives, and run the retreat with them – perhaps as a prelude to a business-IT strategy/roadmapping process?  That could open up some invaluable dialog!

Two “Killer Practices”

Finally, as I was reading the book’s closing chapter – a “Breaking the Paradox” checklist, I was sorting out in my own mind which practice could have the highest transformational impact for an IT organization that was already doing well in terms of business-IT maturity.  I tried to distill this down to a single practice, but in the end, I whittled the list down to two:

  1. Reach beyond IT. CIOs are picking up new titles left and right. We see “CIO and VP of customer care,” and “CIO and VP of strategic planning” all the time. Whether they take on an additional title or not, it is time that CIOs apply their leadership far beyond the IT organization.
  2. Move closer to the revenue. When technology data is directly related to a company’s products or services, the CIOs of those companies have a shot at driving revenue.

To view the table of contents, advance praise and a sample chapter click here.

Enhanced by Zemanta

Is IT Organizational Confusion Exacerbated by the Role of Business Relationship Manager?


I received a question from a reader about the role of a Business Relationship Manager (BRM).  I decided to bring the question and my response to this blog.

His question, and the context for it was:

When the BRM role was introduced at our organization, the Head of IT did not convey a clear vision or direction for how the new role would fit into the existing IT organization structure.  We did not have clarity on how to deal with the issues that are brought to surface by the BRM, or how the BRM should work with Business Analysts, Project Managers and other key roles.  Please share practical examples of how a typical BRM should operate on a day-to-day basis.  What impact should a BRM expect to have made in 3, 6, 12 months and who should see/feel the impact- is it for the IT department and its behavior or how business begins to engage with BRM?”

His email went on to say:

I feel that a lack of clarity and appropriate structure and governance of how a BRM is to operate within an existing IT organizational structure will result in a muddle and confusion for IT colleagues and ultimately fractured relations with the business/customers.”

New Organizational Roles Disrupt the Status Quo

My first observation is that you could substitute any major new role for the specific BRM issue above and have the same potential for organizational confusion.  I’ve seen this with the introduction of Business and IT architects, Program Managers, Service Managers, Product Managers, and so on.  Sometimes the new role gets introduced with limited clarity as to its purpose – rather it feels like “the thing to do”.  Often, the catalyst for the new role is something like:

  • Someone in an influential position has read about or came from an organization where this role reputedly worked miracles – “We should try this here!”
  • There are recurring pain points (e.g., a ‘noisy’ or dissatisfied business customer) – “Let’s put Jill into a role to face off with this customer and see if she can reduce the noise!”
  • Something doesn’t feel right about the current organization structure – “Let’s introduce a new role and see if that improves things!”  This is akin to the proverbial moving of deck chairs aboard the Titanic!

Implications of New Roles

Whatever the catalyst, there are a couple of important contextual characteristics to note here:

  1. Lack of clarity about the rationale for the new role – what problem(s) are we trying to solve and how will the new role solve them?
  2. Unclear expectations about what the outcomes of the new role should be (for example, picking up my readers question, “impact to have made in 3, 6, 12 months and who should see/feel the impact?”)
  3. Failure to fully consider changes that must be made to the IT operating model.  Presumably, the new role is taking over some Responsibility and/or Accountability from other roles, and that other roles need to be Consulted or Informed by the new role.  Note, the initials I’ve capitalized – RACI – the (hopefully) familiar tool for clarifying and assigning roles and responsibilities.

Unclear New Role + Unclear IT Operating Model = Total Confusion!

So, what we have here is a new role being introduced with a lack of clarity as to why, or how, into an organization that already has an unclear Operating Model.  In the past, we somehow managed to ‘get by’ with the unclear Operating Model because:

  1. We have bright, hard-working people who work at ‘smoothing out the bumps’ caused by lack of Operating Model clarity.
  2. They’ve been at this for a while, so unless there’s an unusual disruption to the status quo (such as a new role being introduced), we manage to limp along ok.

Answering the Tough Questions

My reader asked for “practical examples of how a typical BRM should operate on a day-to-day basis.”  With due respect to my reader, it’s the wrong question.  You can’t solve the problem by defining how a BRM operates.  The real question is, “How should the IT organization operate on a day-to-day basis with the introduction of this new role (the BRM)?” i.e., “What is our next-state IT Operating Model?”  I’ve posted many times on the components of an IT operating model, how to define one, how to implement one, and so on.  Enter IT Operating Model in the search box at the top – you’ll get about 40 posts on this topic representing 30 years of IT management consulting wisdom shared over 5 years of blogging!

My reader also asked, “What impact should a BRM expect to have made in 3, 6, 12 months and who should see/feel the impact- is it for the IT department and its behavior or how business begins to engage with BRM?”  The first part of this is totally dependent upon the organizational context – and especially on business and IT maturity.  But it is the right question, and the BRM should be working with the IT leadership team defining the hoped-for impact and how to track it.

It is also important to consider possible unintended consequences of a new role’s introduction.  For example, I worked with a global multi-billion dollar company who carefully introduced the BRM role.  They picked their “best and brightest” to fill the BRM position, and we developed a robust training program and toolkit for the BRMs.  Unfortunately, they were so effective at surfacing, stimulating and shaping business demand for IT, that they quickly exceeded supply capacity.  The BRM’s found themselves saying “no” to the same business executives they’d worked with to surface that demand.  If the expression “getting egg on your face” has any meaning, this was getting an entire chicken farm all over yourself, with lashings of excreted waste!

To the second part – who should see/feel the impact – I’d say that if there’s no positive impact to the business customer, then why bother with the BRM (or any new) role?  And inevitably, the IT department will feel impact – disruption initially, but over time, greater efficiency (“doing things right”) and effectiveness (“doing the right things”).

So, What To Do?

Again, this is a topic I’ve visited many times over the years on this blog – click on Organizational Change Management on the tag cloud to the right of this post for a collection of posts that more or less deal with this issue.

There’s no easy formula here – it’s about motivating change.  This is highly contingent on organizational context, relationships, and other factors specific to a given environment, but there are some common elements:

  1. Find ways to surface the pain of the status quo to those with the organizational power and authority to initiate the change – what the quality movement calls “the cost of quality”.  Use the process of surfacing this pain to build a guiding coalition of stakeholders who want and will benefit from the change.
  2. Find ways to clarify and sharpen the vision of the future state – the remedy to the pain of the status quo.  How will the introduction of a BRM role improve things?  What will this look like – after 3, 6, 12 months?  What will the implications be for our IT operating model?  Again, leverage the coalition – get their input and ensure their buy-in to the future state.  Help them understand what they must do to help the change happen and the future state become real.
  3. Find ways to clarify the transition from the status quo to the future state – what’s the transition plan?  Should we start with one BRM and conduct a pilot?  Should we pull together an “IT Operating Model Improvement Team” to do a fast cycle (no more than 60 days) analysis and provide recommendations to the IT leadership team?

Image courtesy of Awakening Business Solutions

Related articles
Enhanced by Zemanta

To Whom Should Business Relationship Managers Report?


I recently received this question from a reader:

We are evaluating a strategy to centralize IT and implement Business Relationship Management (BRM) roles as part of the centralization. Where do you typically see the BRM’s reporting into in a centralized IT organization? Should they report directly in to the CIO, or can they be effective a level or two below the CIO?”

Rule #1 – Reporting Lines Are Weak Determinants of Success for the BRM Role

I have found reporting relationships to be a very weak determinant of success for the Business Relationship Manager (BRM) role. Far more important are the competencies (especially business knowledge and relationship skills) of the BRM and the maturity of the business executives they partner with.

Rule #2 – Heft Matters!

Notwithstanding Rule #1, the “heft” of the BRM role – the weight and implied authority it carries does matter.  There’s a couple of reasons for this:

  1. BRM’s are often on a CIO succession path (either explicitly or implicitly) – i.e., have the skills and wherewithal to be a CIO down the road, and the BRM role may be seen as a developmental step.  This has implications for who you chose to fill BRM roles, and for their career paths.
  2. The story a CIO tells the business executives when establishing the BRM role is along the lines of, “I am giving you one of my senior staff members to help surface, shape and manage IT demand so that you get the highest possible value from IT investments and assets. In return for this ‘gift’ I expect you to treat this BRM as a member of your management team.”

As a result, the most common reporting relationship for successful BRM’s is directly to the CIO.  In some cases, the BRM has a dotted line relationship to the senior business executive for the unit they represent.  In other cases, the BRM role is solid line to the senior business executive and dotted line to the CIO.

Rule #3 – Context Matters!

There are many other contextual factors to consider here, including:

  • What is the scope of the BRM role – is it primarily demand management (shaping, surfacing and managing business demand for IT)?  Or does the role include supply management, service management or other responsibilities?
  • Do the BRM’s act as Project or Program Managers for major initiatives?
  • Do the BRM’s sit on any governance bodies, such as Portfolio Management or Service Management?
  • How do BRM’s engage with the supply side?  How do they engage with Enterprise Architects?
  • How mature is IT supply?
  • Howe mature is business demand?

BRM’s Can Be ‘Game Changers’!

The BRM role is a tough one to get right, but from my experience, well worth the effort!  An effective BRM can:

  1. Elevate business maturity
  2. Ensure that IT resources are being focused on the highest potential value activities and initiatives
  3. Ensure that those initiatives capture the highest possible value

 

Graphic courtesy of Linda Galindo

Related articles
Enhanced by Zemanta

How Good are your IT Capabilities and How Good do they Need to Be?


This will be the first in a series of posts about assessing the “goodness” of IT capabilities, both in terms of your current state (how good your IT capabilities are) and ‘desired’ state (how good they need to be).  We will get into the dimensions of ‘goodness’ as well as assessment methods.

I’ve been designing and facilitating IT capability assessments for over 20 years, and have conducted hundreds of them – both as part of multi-company research projects that generated a substantial base of assessment data, and through individual assessments as part of consulting engagements. Over that time, I’ve developed a number of assessment principles I’ve found to be important.

The Process Is More Important Than The Results

There are several aspects to this.

  1. People don’t like being assessed, but they love being part of an assessment process!  By and large, people like to know how they are doing, especially from an organizational perspective.  But they are mistrustful (rightly so!) of consultants or other ‘agencies’ that come in and assess them or their organizations.  So, I’ve always taken an approach where I am a facilitator of a self-assessment process.  I bring the process (which the client and I may agree to modify to accommodate specific contingencies), experience to help them through the process, and act as an impartial ‘judge‘ to resolve differences of perspective, opinion or interpretation.
  2. The process must be transparent.  If people don’t understand or buy into the process, they will never buy into the results!
  3. The process should be repeatable.  Like a meaningful scientific experiment, the process should lend itself to repetition with consistent results.  In fact, repetition over time may well be important to sustained investment in capability improvement activities.  Too many assessments are conducted, discussed and then swept under the table.  This is a travesty!  Not only is the assessment wasted effort, but it may also be that much harder, or even impossible, to get people to participate in future assessments.  “Why should I bother – the last time we did this it went nowhere!” is a fairly common refrain.

The Results Must Be Actionable

The results should let you know:

  1. What needs to be done to improve capability performance.
  2. Where the greatest urgency lies for capability improvement.
  3. What it will take for a given IT capability to be improved, and to what benefit.

The Results Must Be Multi-Dimensional

This actually gets to the question of “goodness.”  I believe there are three important aspects of “goodness” as it relates to IT capability:

  1. Performance – this gets to efficiency – what resources it takes to achieve a given result.
  2. Value – this gets to the effectiveness of an IT capability – what benefits are being derived from the capability.
  3. Health – the ability to perform and deliver value over time.  We’ve all seen heroics, where, for example, a project team moves mountains in the final weeks of a project by working 20 hour days, 7 days a week.  It’s a wonderful thing to behold, and sometimes is necessary and may even promote ‘good health’ for the organization as people pull together and participate in a ‘miracle’.  But it’s not sustainable.  Expecting people to perform at a sprint when the course is a marathon is both dangerous and demotivating.

Process-based Assessments Only Go So Far!

We are all familiar with the SEI CMMI type maturity assessment.  These typically assess a capability’s maturity as somewhere along 5 levels:

  1. Initial
  2. Managed
  3. Defined
  4. Quantitatively Managed
  5. Optimizing

I believe maturity assessments such as this are appropriate for capabilities that are heavily process-dependent.  These include IT operational processes – highly predictable, repeatable processes.  But, drawing from Henry Mintzberg‘s discussion of standardization many years back, (see Mintzberg’s “Structure in Fives: Designing Effective Organizations”) not everything demands standardization of work processes.  If the goal is to make work consistent, repeatable, predictable and of high quality, there are three approaches:

  1. Standardize the work processes
  2. Standardize the outputs – i.e., the deliverables from the process
  3. Standardize the skills – i.e., focus on the people and their training

Typically, all three types of standardization apply to varying degrees – the mix being a function of the nature and complexity of the work you are doing.  For highly complex work (think brain surgery) the emphasis is on the people, which is why surgeons go through years of training, board certification, residencies, and so forth.  It’s no use handing them a detailed process to follow and expecting an untrained person to achieve a quality result.  For work such as bridge building, the emphasis will be on the deliverables – various types of blueprint, work breakdown structures and so on.  For routine, sequential work, the emphasis will be on defining the tasks to be followed and the sequence in which to follow them.  Ideally, the work can be so ‘routinized’ that it can be automated.  (Think data center operations and the shift over the years to ‘lights out’ data centers.)

The graphic below illustrates this concept.  Detailed processes are great at helping manage work that is routine and sequential in nature (which is one of the reasons why ITIL has gained so much traction in the last few years.)  For work that is inherently collaborative, and may require more visual enablement, standardizing on deliverables may be more apparent (think discovery and solution delivery).  For work that is more complex and exploratory, training and performance support systems are more appropriate.

For more on the different approaches to standardization, see my post, “Are Your Processes Setting You Free?  Or Holding You Back?“

Please join me for the next post in this series where we will drill further into assessment dimensions and processes.

 

Graphic courtesy of Take On Torah

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

Leveraging the Cloud to Accelerate IT Renewal – Part 3


This is the third and final part in a three-part post on how Cloud Computing can provide a fast path to “IT Renewal.”

What is IT Renewal?

In the first post in this series, I discussed how information and technology are becoming ever more central to what an organization does and how it does it and how consumer technology is beginning to have a dramatic impact on enterprise IT. I referred to the actions an IT organization takes in response to these changes as “IT Renewal.”

In Part 2, I described three major opportunities for Cloud Computing to accelerate IT renewal:

  1. Finding and validating new business opportunities.
  2. Improving existing business capabilities.
  3. Transforming how IT capabilities are managed and deployed.

I wrapped up the second post focusing on opportunity #3 from the list, arguing that IT Management is becoming a distributed activity that exhibits many of the characteristics of complex systems, where:

  • Organization is a natural, spontaneous act;
  • Emergent structure trumps imposed hierarchy and control;
  • Creativity arises from variety and randomness;
  • Relationships, porous boundaries, free flows of information and self-reference are essential to survival and growth.

These complex system characteristics lend themselves to the use of collaborative approaches to managing IT work – what I referred to as the “Five C’s” of Information Management.

The “Five C’s” of Information Management

As the management of information and technology becomes increasingly distributed and complex, five types of management activity emerge as important to the way work is done:

  1. Collaborating
  2. Coordinating
  3. Connecting
  4. Co-creating
  5. Coalescing

Enabling the “Five C’s” in the Cloud

Because each of these activities is increasingly being conducted across time and space and across organizational boundaries, enabling them through flexible, scalable cloud solutions becomes an attractive proposition.

As an example, I’m currently working with a client who is refining their IT Operating Model so as to enable a new, growth-oriented business-IT strategy. They had determined that they wanted to support their IT work and forge stronger business relationships using Microsoft SharePoint. However, they are currently on SharePoint 2007 and recognized that they needed to move to SharePoint 2010 as their preferred collaboration and knowledge management platform. However, the upgrades to servers, licenses and related IT infrastructure was going to take 3-4 months, and a significant capital outlay. But, they did not want to lose the momentum they had already established in developing the new business-IT strategy.

As an alternative, we were able to set them up with a cloud-hosted SharePoint 2010 instance over one weekend, with zero capital outlay, and a very modest monthly cost that scales with the number of users, and therefore with the value delivered. Now, they are creating new levels of organizational clarity, establishing a continuously improving IT Operating Model, and experiencing new ways of working – collaborating, coordinating, connecting, co-creating and coalescing, against a set of Cloud-based software services.

Let’s take each of these in turn and see how they can help you “manage IT in the cloud.”

Collaborating on IT Work

Much IT work is performed through teams – increasingly distributed across geographies, organizations and time zones. This change forces a shift in work management from a document-centric (write-attach-email-review-attach-email, repeat ad infinitum) to a more collaborative Wiki-based approach, which has significant advantages:

  • Wiki’s are inherently non-linear and encourage a ‘constructive informality’ that improves quality over time, drives organizational clarity and reduces or eliminates redundancy and contradictions. Wiki’s (well-managed!) let you stop wondering, “Is this the latest version? What was changed since the last version?”
  • Wiki’s encourage multi-author collaboration. Whereas the typical document-centric approach has one or two main authors with everyone else in a review role, Wiki’s encourage a more collaborative approach to authoring – with higher engagement and understanding in the content.
  • A Wiki approach dramatically simplifies search and discovery. The ability to hyperlink, tag, and use a well-factored semantic Wiki leads to content that is far more accessible, intelligible and searchable for all stakeholders.
  • There are many good Wiki products available as SaaS, including SharePoint, Confluence, and MediaWiki.

Coordinating Activities in Time and Space

As IT work becomes more distributed, the need to coordinate activities in time and space becomes both increasingly important and challenging. And again, SaaS offerings are ideally suited to helping distributed teams coordinate their activities, including:

  • Real-time communication and collaboration – e.g., IM, Google Wave
  • Collaborative Project Management – e.g., Bamboo, BaseCamp
  • Desktop videoconferencing – e.g., Go To Meeting, WebEx

Connecting People and Ideas

The need to identify and connect people and ideas is important to innovation and learning. As IT work becomes more distributed, cloud-based SaaS solutions become effective ways of connecting people and ideas, through tools such as:

  • Social Networking – e.g., FaceBook, LinkedIn, Plaxo
  • Mind Mapping – e.g., MindMeister, WebBrain, Bubbl.us
  • Virtual Electronic Whiteboards – e.g., FlockDraw, Colabopad
  • Social Network Analysis – e.g., Netminer, InFlow
  • Innovation James – roll your own using a combination of cloud-based services

Co-Creating Experiences

As business and IT converge, opportunities emerge to co-create experiences with customers, consumers, suppliers, business partners, etc. New types of SaaS solutions for co-creation include:

  • Modeling and Simulation – e.g., Creately, FlexSim, Second Life
  • Prototyping – e.g., iRise, Dreamweaver
  • Virtual Worlds – e.g., Second Life, There.com (currently closed)

Coalescing Around Ideas and Reaching Consensus on Decisions

With the increasing distribution of IT work comes the need to poll stakeholders, tap into sentiment, coalesce around ideas and reach consensus around decisions. And new approaches and supporting tools emerging into this space, including:

  • Polling – e.g., Survey Monkey, Kluster, IdeaScale
  • Group Decision Making – e.g., Resolve
  • Prediction Markets – e.g., NewsFutures

Summary

One the one hand, the increasing complexity of the world of IT management, and the convergence between the work of professional IT organizations and their customers and consumers can seem like a daunting challenge for IT leaders – a threat to the order, security and stability they have worked so hard to achieve over the last 50 years of enterprise computing. On the other hand, the shift to the “information prosumer” and the distribution of IT work is forcing a new way of managing IT activities – across organizational boundaries, across geographies and across cultures.

Just as these shifts are taking place, the Internet as a computing platform and the rise of Web 2.0 and 3.0 capabilities promise a new set of rapidly evolving tools – available as Web services – accessible from mobile devices – and affordable by even the smallest business or even the individual consumer.

I believe these Cloud-based IT management capabilities offer a way for IT leaders to step ahead – to take the lead in learning how to deploy and take advantage of these services – and help to drive business-IT convergence for their organizations.

Illustration courtesy of Suzanne Lebeda at Adirondack Artists’ Guild

Related articles
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

Three Ways To Increase IT Organizational Agility


Back in a September 2010 post, I asked, “How Agile Is Your IT Organization?  How Would You Know?“  The question came about as part of a research project I’m involved in through my affiliation with Formicio.  The aim of the research is to identify the factors that make IT organizations agile and recommend how agility can be developed as a core capability.  (Phase 1 of this research is still open – please feel free to participate by completing a survey here – it should take about 30 minutes, is free, and I believe you will find the questions stimulating!)

What Does ‘Agility’ Mean to an IT Organization?

Wikipedia defines agility as:

The ability to change the body’s position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, endurance and stamina.  In business, agility means the capability of rapidly and efficiently adapting to changes.”

From the perspective of the research project, we defined IT agility as:

The ability to rapidly and easily incorporate new technologies and methods into the way the IT organization operates, thereby having the capability to effectively sense and respond to changing business conditions in a timely manner.”

Why Does Agility Matter to an IT Organization

Simply stated, most business executives I speak to feel that their IT organizations lack agility! To paraphrase the typical response:

Things take too long to get to the point where they are delivering business results, and the IT organization typically seems to be behind the curve on emerging technologies!”

You may disagree with this statement, but I think most of you will agree that it is the common perception of your business executives.  In a world that seeks instant gratification, that is a value that is not typically embraced by IT organizations – and perhaps it should not be?  In a world where the business and competitive context can change almost overnight, increasing IT organizational agility should become an active goal.

So, What Have We Found?

The data is still coming in, and the numbers being crunched, but a couple of early observations:

  1. Your perspectives on Enablers and Barriers to agility depend upon where you sit.  In a federated IT Operating Model (some centralized, some decentralized), those that sit in the central camp tend to see shared IT capabilities as enablers of agility, whereas those in the decentralized units tend to see shared capabilities as inhibitors to agility, and seek more freedom from the ‘mothership’ in order to increase agility.
  2. Even with the definition of IT organizational agility provided as part of the research, its meaning is very squidgy and Rorschach-like – you read into “IT organizational agility” what you want to see.
  3. Fans of Agile Development equate IT organizational agility to Agile Development – they are essentially one and the same to them.  On the other hand, when you drill into what teams are doing with Agile Development, what you find is all over the map.  To some teams, it is a license to take short cuts, no matter what the consequences!
  4. Governance is desperately misunderstood!  This will be a subject of a separate post (or two!), but what I am seeing as I pour over the research findings indicates some governance perceptions that are way off base.  Again, it depends where you sit, but while some see governance as an agility enabler, others (in the same organization!) see it as a major barrier!
  5. The very different perspectives on what is meant by IT organizational agility and why it is important is quite troubling – if you can’t agree on what it means and why you want it, you are unlikely to increase your IT organizational agility!

Three Ways To Increase IT Organizational Agility

So, given those findings, here are three relatively ‘quick wins’ that will at least get your leadership talking in the same direction (excuse the mixed metaphor!)

1. Get clarity on what IT organizational agility means to you.

Don’t get wrapped up in academic definitions – focus on what it means to your organization.

  • What are your business drivers for IT organizational agility?  If you were more agile, what good things would you be capable of that you aren’t today?
  • Complete the tool in our research survey and use the 6 Domains of IT Agility to drive discussion internally on your enablers and barriers to agility.
  • Get to a consensus on the factors that need to be worked on for increased agility.
  • What do you see as the connections between agility and collaboration?
  • What do you see as the connections between agility and knowledge management?
  • What do you see as the connections between agility and Enterprise Architecture?

2. Identify where Agile Development fits in and how you will exploit that without increasing project risk.

Get clarity on Agile Development – what it is, and what it is not!

  • How do you define Agile Development for your organization?
  • When, where and how should you use Agile Development?
  • How will you define and monitor success?
  • What ‘unintended consequences’ will you look for and how will you mitigate against them?
  • What else is needed to increase IT organizational agility above and beyond Agile Development as you’ve define it?

3. Get to a shared understanding of IT Governance.

Get clarity on how you define IT Governance.  Again, don’t get wrapped up in academic definitions – define what it means to your organization.

  • What are the various aspects of organizational governance in your organization? (Don’t be limited by “formal” structures – consider aspects such as empowerment, decision rights, accountabilities, processes, culture of compliance, consequences for compliance or lack thereof.)
  • What is it about your IT governance that enables agility?
  • What is it about your IT governance that inhibits agility?
Enhanced by Zemanta