The IT Relationship Manager’s Role in Expanding Business-IT Capability


For those who care, I apologize for a recent decrease in frequency of posts – I hope it’s not a real problem for you.  I’m still trying to figure out the optimal frequency and best days to post to this blog. Of course, the bigger issue is sustaining the content, which requires concentrated writing and, perhaps more important, reading time.  For all good reasons, I’ve been consumed by other activities lately – all very interesting in their own rights, and ultimately, more fuel for the blog fodder! 

One of the many activities I’ve been involved in has been putting together a Webinar with the less than crisp but amply descriptive title, “The IT Relationship Manager’s Role in Expanding Business-IT Capability.”   This is a topic I’ve blogged about quite a bit in the past (a search of my site for “relationship management” finds 14 posts that touched on the topic).  I find a great deal of interest in this topic among my clients, and believe the relationship manager role has become critical, and is often misunderstood in bridging the business-IT organizational boundary.  Yes, I know I should not be talking business-IT boundaries, but there are realities out there that we have to accept and deal with – many boundaries do still exist.

Anyway, I’d love to have readers join the Webinar – it’s on June 5, 2008 from 12:00p to 1:00p EDT.  I’m going to be talking about:

  • The defining characteristics and business and IT prerequisites of a Level 3 Business-IT capability
  • Where Level 3 requires dramatic breaks from today’s common practices and attitudes
  • The specific relationship management challenges and required skills for reaching Level 3

So, to join me, and perhaps let’s get to know each other a little better, and spend an hour talking about an interesting and important issue.  Just click on the “register now” button.

 

About these ads

Platform Thinking


Idris Mootee’s excellent blog, Innovation Playground posted on “What’s the Difference Between Platform Strategy vs. Business Strategy vs. Product Strategy?”  This is a great post, and a opens up a huge area for analysis, speculation and discussion around platform thinking. 

Platform thinking emerged as an important dimension in our recent Reaching Level 3 Multi-company research.  I believe platform strategies build strongly on the disciplines of architecture,  marketing, product, program and portfolio management.  These are not necessarily the strongest capabilities of many IT organizations.  This is not an indictment – it simply reflects how IT has evolved – these were not the core disciplines (e.g., project and infrastructure management) that have traditionally been valued in the enterprise IT world.  Companies that seem to be doing this well, frequently have very strong marketing capabilities – and these have seeped into IT (and vice versa!)

“Platform” and “Collaboration” go together like the proverbial peaches and cream.  Good platforms enable collaboration.  Creating a good platform demands collaboration – across business units and IT organizations, and across several disciplines, including architecture, product and program management. 

Can you articulate your company’s platform strategy?  Is there one?  Should there be?  What is the role of the IT organization in defining and executing your platform strategy?

We will dig into these questions in subsequent posts.

The Miracle of Open Source


I enjoyed this post by Tom Evslin in his Fractals of Change blog.  Tom describes himself as a “Rip Van Winkle” of programming – a programmer who stopped writing code for 17 years and has recently started again.  He notes, “At my age, I can build much more interesting stuff in a day of coding now than I could in a week the last time I was doing this – all because most of the functionality I need already exists for free picking off the web.”  OK, so this is not huge news, but it does just show how far we’ve come in terms of the shift from “coding” to “assembling components” and how significant are the productivity implications of the new world of software.

While on the topic of progress made in the IT space, this year’s Enterprise 2.0 Conference is coming up – it will be in Boston, Mass from June 9-12.  Described as the “largest and most important gathering for the people ready to reinvent the way work is done,” this should be an excellent networking and informational event, and my company, nGenera is a sponsor this year.  That means I am able to quote a special promotional code: CMBMEB16.  Use this promotional code to get either $100 off the conference pass or a free demo pavilion pass.

By the way, for those who keep up with such things, you will have noticed that my company name has changed – from BSG Alliance (who acquired my firm of the last 10 years, The Concours Group) to nGenera – a significant change in name, but also a reinforcement of our positioning in the “next generation enterprise” space.  Check out our website for exciting news about the firm, and the acquisitions we have been making lately – all very exciting for an old timer like me!

 

Is IT Collaboration an Unnatural Act: Part 4


In the last post and post before that, I examined a real life case study of a team collaborating using Web 2.0 tools.  Now I want to review the lessons learned from that experiment.

  1. Many (most?) busy people working on a team with deadlines for deliverables will wait until the deadline is really close, and then focus intensely on the task to meet the deadline.  When a new learning curve is introduced (in the case of this experiment, using a Wiki for writing, reviewing and ultimately, publishing a major report), the needs of the learning curve and the common behaviors of team members to wait until the last minute were not compatible.  This team would have done better to force an earlier deadline, one where perhaps only a few paragraphs of content had been created.  This would have forced team members into the learning curve sooner, and would have surfaced individual and collective team problems with the Wiki tool or process much sooner.  Addressing these issues early in the report writing stage of this project would have been far more effective than trying to do so when the deadline for report was due.
  2. Team members knew and trusted the traditional MS Word-based process for this type of work.  They knew there would be wrinkles to the process that would have to be ironed out for the Wiki-based approach.  While one team member did a great job figuring out and addressing some of these wrinkles up front, he could not catch all of them.  None of the outstanding wrinkles were, in practice, significant.  But with a deadline to meet and a learning curve to overcome, there was a strong tendency among the more conservative team members to “stick with what we know and what works.”  When you are in the thick of it, it’s impossible to know if the new wrinkle that just surfaced and was solved is the final wrinkle, or a precursor to a whole host of other wrinkles yet to be discovered.
  3. New tools are almost always imperfect.  While there were workarounds for issues such as off-line writing and editing, for the resistors, any and every impediment justified their feeling that the old way (MS Word, etc.) was just fine.  And even the enthusiastic adopters admitted that some aspects of the Wiki and how it worked were frustrating and time consuming.
  4. While the notion of “experiments” is important to innovation, it is a tricky proposition.  Many years ago, I did a multi-year, multi-company study of Computer Aided Software Engineering (CASE) tools and their use in projects.  At the time, the conventional wisdom in transitioning to such a tool was, “Pick something not too small or not too large, not too complex, but not too simple.  And, most importantly, pick a project that can fail without disastrous implications.”  In practice, we found that this was bad advice, and people who followed this type of path typically ended with failed experiments.  On the other hand, those who ignored the advice and picked a “must win” type of project, almost always were successful – no matter how big or complex the project!  There is a danger that an experiment becomes “something to try and play with” or “how to prove the new approach will not work” rather than “how to figure out how to make it work.”  This is a subtle point but an important one.  This team’s “experimental” approach to using the Wiki did not establish the strength of sponsorship necessary to sustain it over the inevitable (though, in this case, relatively minor) hurdles that surface with a new approach.
  5. Speaking of sponsorship, the “change agents” in the project team (those who strongly believed that moving to a Wiki would be well worth the effort) should have thought through the sponsorship issues up front – deciding who “had to be fully on-board” with the Wiki approach, and working one-on-one with them to get their full understanding and commitment.
  6. Like most mature processes, people tend to confuse the means to the end with the end. The end is useful knowledge expressed in understandable content presented in a simple and useful way. The old generation means to that end was a written report that was designed to be read from paper.  But to most on the team, the report was the end.  To them, the utility of the Wiki was measured by how well or how poorly it led to the creation of the first iteration of the report.  Since writing a report in MS Word was natural to them, and the Wiki didn’t seem to offer any obvious advantage in the process of creating a report, there wasn’t much incentive to change to the Wiki approach.
  7. There are nearly always hidden issues that go un-discussed. (See my previous post on Unwritten Rules).  Often in change, one common issue is that people don’t want to feel incompetent or be perceived by others as incompetent.  So they express their resistance in other ways rather than admitting they are fearful their incompetence will be revealed.  Another common issue in change is control.  In this case, one individual on the team always had final editing rights to a report before it is released.  This individual is renowned for being a brilliant writer and editor.  The old process gave him a sense of control that the Wiki approach did not.  Like the issue of incompetence, the issue of control is often expressed in displays of resistance that mask the true source of concern.

So, was this experiment a success or failure?  Clearly that depends upon your perspective and what you believe the going-in hypothesis was behind the experiment.  I believe that in this case, it is a mixed picture – worth the effort, but not realizing the full success it could and should have been.  The draft report was circulated as a MS Word document.  It remains to be seen whether the tenacity of the main change agent – the team member who was formerly an Information Architect – is sufficient to keep the Wiki alive and, over time, to move similar projects to a Wiki-based approach.  Once again, the challenge is human behavior, and the insidious nature of organizational change.  In the famous words of Niccolo Machiavelli, “There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things.”