Category Archives: Useful Tools

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
About these ads

What You Probably Don’t Know About Wikis


Several of my posts talk about uses of semantic wikis.  In fact, my company is largely based upon a semantic wiki platform, called Symcordia™.  But the more people I talk to, the more I realize that:

  1. While just about everyone has used Wikipedia as a reference source, few people have ever really thought about what a wiki is – what are its strengths and limitations?
  2. When people visit a Wikipedia article, they almost never look at the Talk page associated with that article, and have no idea of the value that may be hidden within the Talk pages, or why they exist.
  3. When people visit a Wikipedia article, they rarely look at the Page Ratings, or rate a page (you can rate Wikipedia pages based on the degree to which it is Trustworthy, Objective, Complete, Well-written.)
  4. Occasionally, I come across someone who says, “I don’t use Wikipedia – the content cannot be trusted!”  (These same people trust network television news!)

What is a Wiki?

Here’s a nice little video that describes the basics of a wiki:

Wikis – More Than Just Knowledge Capture!

If you look beyond the basic encyclopedia article in Wikipedia and examine a typical Talk Page, you will find it provides a place for people knowledgeable and passionate about a topic to debate that topic and how best to present it to readers.  Similarly, it provides a place for those with knowledge of Wikipedia’s standards and editorial policies to ensure an article meets quality and integrity standards.

If you look at the Page Ratings (not all pages have these – this is a fairly recent feature and is being expanded in functionality) you will find a place to rate a page based upon its trustworthiness, objectivity, completeness and clarity.  Perhaps, even more importantly, you can see how others have rated it.

Why Semantic Wikis?

Wikipedia is an encyclopedia – a compendium of articles.  As such, it deals with a single class of knowledge – the encyclopedia article.  For most organizations (for example, a business or an IT group) there will be dozens of different classes of knowledge to organize and represent.  For example, the diagram below is a simplified entity-relationship model for the knowledge inherent in a typical IT organization.  It comprises entities such as processes, services, metrics, roles, competencies, and so on, and shows the relationships among them.  So you know, for example, that if you are going to define a new process, you will need to define roles needed by that process, and if you are going to define roles, you need to define the competencies needed to fill a given role.

A semantic wiki lets you assign semantic properties to a page to reflect these different knowledge classes.  It also enables you to have page templates for each class of knowledge content.  This simplifies and encourages knowledge capture and use and ensures consistency within knowledge types.  This helps you to organize the content, and even to differentiate between two types of content:

  1. Content that must be of extremely high integrity (an operational process, say) and therefore the entire organization needs to understand its current state of development and its governance process. This type of content can and should be designed and made consistent in appearance to increase organizational clarity. The ER Model above represents this type content which tends to be at the ‘core’ of IT in most companies and encourages convergent thinking.
  2. Content that is more exploratory in nature (pages for a Community of Practice, say). This type of content doesn’t necessarily have a lot of pre-defined structure or governance in its development. It emerges over time as people brainstorm and collaborate. This type of content is typically at the ‘edge’ of an organization’s processes and encourages divergent thinking.

The graphic above (from Symcordia™, our semantic wiki platform) shows a typical example of the semantic properties of an IT Capability page.  The Property ‘Status’ can be changed, say, from Operational to Proposed to Under Discussion to reflect its current status.  This change can even be automatically controlled by workflow – the act of changing an Operational page, will change the semantic status of that page to Proposed, alert the appropriate page Owner and Governance Entity and move the page through its governance workflow until it reaches Production status.

We use the same screen real estate – the Property Box – to capture and show page ratings.  Again, the fact that each page can be of a different semantic class allows you to easily adjust the ratings questions based upon the page type.  (My post on how my rock band is using a semantic wiki to enable our learning and development illustrates this nicely.)

Is Microsoft’s SharePoint Really a Wiki?

SharePoint is often referred to by those in the know as a WINO – Wiki In Name Only.  For a rich discussion on this point, I’ll point you to an informative post by my business partner, Roy Youngman.  The other aspect of SharePoint in practice is that its strengths as a document management system tend to reinforce document-centric behaviors.  A common result, given that “old habits die hard” is that people tend to create and attach Word, PowerPoint and other document types, so the collaborative and “single version of the truth” characteristics of wikis are never realized.

Wikis Versus Document Management

To appreciate the limitations of documents as ways to share and grow knowledge, think about all the servers and disc drives filled with documents that never get shared – that quickly become out-of-date. To quote from another of Roy Youngman’s posts on Why Are Wiki’s in Corporate IT Rare:

The very notion of updating a document is perceived as painful and avoided at all costs by anyone with the expertise to actually make the changes… Every document was originally written to stand alone and few of them rely on one another to create clarity, so they contain many redundant passages; in fact, most of them contradict each other in one way or another and confuse the few people who do read them.”

Wikis mitigate the short-comings of document-orientation. Again, to quote Roy:

The nonlinear nature of a Wiki enables well-factored content, thereby minimizing redundancies and preventing contradictions that confuse people. It also allows people to contribute to whatever area of expertise each person happens to have so everyone is drawn in, not just the elite few. “

That means that Wikis enhance knowledge discovery and improvement, while documents tend to bury knowledge.

Have you experienced the power of a wiki?  Please take a moment to share your thoughts and experiences.

Graphic courtesy of The American

Related articles
Enhanced by Zemanta

Accelerating Individual and Organizational Learning – Case Study from a Rock Band: Part 2 of 2


This is Part 2 in a 2-Part post – please see Part 1.

Quick Recap

This post explores how a semantic wiki can support self-organizing teams, using a rock and roll band as a case study.  We developed a semantic wiki using the Symcordia™ platform to enable the band’s development and learning – both collectively (organizational learning) and for band members (individual learning).

Necessity is the Mother of Invention.

The band began as a vehicle to cover classic rock songs.  Over the first week or so, we found ourselves drowning in endless email chains, with lists of songs to cover, suggestions for band names, and so on.  I’ve always found emails to be both inefficient and frustrating as an approach to coordinating and sharing knowledge across a work group.  We were finding it tough to keep track of all the suggestions and maintain a “single source of the truth” to guide our practice and development.  We believed there was a better way, so we quickly (initially about 3 hours work) built a band wiki using my company’s Symcordia™ platform.

A band has several characteristics that make a wiki a great enabler:

  1. Playing in a band is a highly collaborative endeavor.  Wikis are inherently collaboration tools.
  2. Playing in a band demands shared knowledge:  What are we going to play?  Which key should we play it in?  Who will take which parts (e.g., lead vocal, harmony vocal)?  Wikis are a fabulous way of capturing and sharing knowledge.
  3. A band must develop and grow – or it dies on the vine.  Wikis are wonderful enablers of individual and collective growth and learning – they can put at your fingertips all that you need in terms of knowledge and tools to develop and grow – things like musical scores, YouTube tutorials, song lyrics.
  4. For a developing band, history and shared experience is crucial to learning: What did we try and why?  What worked well – and not so well?  A wiki is an ideal vehicle for capturing history and creating shared learning.
  5. A band depends on all sorts of creative decisions:  What’s the best sequence of songs for a given context?  Which settings worked best for amplifiers, mixing boards and effects pedals?  A wiki is a great way of enabling and capturing those decisions and the logic and collective wisdom behind them – one place to keep a ‘single version of the truth.’

Initial Design and Features

Given these characteristics, we came up with our initial design.  Here’s a screen shot of the wiki sidebar – a primary navigation mechanism.  Note, we’ve not yet tried to make the site “pretty” – we will eventually create a public face into selected portions of the band wiki, and use a more fancy style sheet for that:

There’s an inevitable section about the band – each member has a page where they can post personal details, photos, videos, etc.  We’ve also worked up some “principles” or “simple rules” about how we want the band to work (e.g., We encourage band members to move from instrument to instrument.)  Having these on the wiki allows us all to collaborate on developing the principles and bringing them to life.  We struggled with naming the band, so we created a space for us to develop naming ideas, comment, vote and converge on a final name.

The most important space, in terms of developing as a band, is the Band Repertoire.  As you’ll see above, there are sections for:

  • Performance Ready Songs – songs we feel are ready for performance to an audience.
  • Songs In Development – songs that we are working on with a view to readying them for performance, at which time they get promoted to Performance Ready pages.
  • Prospective Songs – songs that we’d like to perform and within our talent and limitations, e.g., if it needs a flute, we probably can’t do it (sorry, Jethro Tull!)
  • Song Ideas – suggestions about songs we’d like to try at some time.

Typical Song Page

Here’s a partial screen shot of a typical song page:

Key here is:

  • The version of the song (some songs have multiple versions by different performers – for example the Guns ‘N Roses version of Knockin’ on Heaven’s Door is quite different from the Bob Dylan original).
  • A YouTube of the song by the performer we are trying to emulate, so we’re all aiming for a common performance outcome, or at least, a starting point to develop from.
  • Links to the tablature (music) for guitar, bass, drums, keyboards and any other learning aids.
  • The key we will play it in.  (Four band members playing a song in different keys does not sound so good!)
  • Performance Notes – clues about how to perform a song, and observations on how we are doing so far.
  • Song lyrics – lead vocals and harmony vocals singing different versions of the lyrics can really spoil a performance!

Semantic Properties

Each song page has a Semantic Properties box:

In order to protect my band mates privacy, I’ve ‘faked’ the assignment of parts to be all me!  But each part (vocal and instrument) can be assigned to different band members, and we can try different assignments at our practice sessions to see what works best (and capture this in our Performance Notes).

We can also vote on different aspects of the song.  The things on which to vote change depending upon context – e.g., whether it’s Performance Ready, Song In Development, Prospective or Song Idea.  For Performance Ready songs, a question is, “How well do we perform this song?”  For a Song In Development, it is, “Are we getting better with this song?  Are we ready to perform this song?”  And for a Prospective Song it’s, “Do we want to work on this song?”

Because these are Semantic Properties, we have pages that dynamically generate reports, such as:

  • Which parts I am playing what roles on?
  • Which songs do we most want to work on?
  • Which songs are improving the most quickly – or slowly?

Capturing Performances

We capture MP3 recordings and video clips of our performances and embed these in the song pages, track and rate how our performances are evolving over time – creating an historical record of growth and learning.

How Is It Working Out?

I’m going to save my richer response to this till we have a little more experience under our belts, but there are some early insights that I’ve seen many times before with my business consulting clients as they try to leverage collaborative tools like this:

  1. Email habits die hard!  For all the frustration with email overload, and the inefficiencies and inadequacies of email for collaboration, band members’ first instincts are to send an email, which begets a natural reply response.  Good thoughts are lost to the ether and invisible to the wiki!
  2. It’s tough making time to learn – even though the learning curve for a wiki is trivial.  The late Dr. Stephen Covey talked about the man struggling in the woods to saw down a tree.  An old farmer came by and observed, “That saw looks pretty dull.  Why don’t you sharpen it?”  The man replied, “I don’t have time to sharpen the saw – I’m too busy sawing!”
  3. I know from my business client experience with wikis that they gain the most traction when their use is ‘in the natural flow’ of daily work habits.  For our band members, they tend not to sit at desks with a computer screen and a browser.  They are busy executives moving from meeting to meeting and town to town.  Their dominant means of communicating beyond their meeting context is via Blackberries – phone calls and emails – so the band wiki is not ‘in the flow.’  This will change when we release a version of Symcordia optimized for smart phones and tablets.

Lessons Learned from a Reader

I’ll close this post by pulling a comment from the Part 1 post.  The comment came from Glenn Remoreras, one of my favorite bloggers (See Simple Processes.)

Based on my experience of championing the use of wiki with my team, it was a bit of a crawl, walk run process– and we are still crawling after a month. Here are our lessons learned:

  • Adoption champion is critical to success of the process. (I took this challenge myself as the manager of my area). As champion I generated initial contents and encourages to channel collaboration through the tool by suggested practices.
  • Different team members will have a different level and pace of adoption. That’s normal and acceptable. I did not force my team to use the tool, I slowly introduce it in our meetings and reporting.
  • Leader’s example is important. The leader spearheads the different ways to use the tool by doing it himself/herself. Later on the team will realize the benefits by experiencing how it changes the way they work.
  • Crawl walk run approach is necessary to not force the team adoption. Team members will adopt when they realize that it actually facilitates better flow of information and better team collaboration. Don’t rush it!
  • Subsequent and consistent use of the information in the community (wikis, blog, forum, file sharing) for information purpose to outside entities strengthens importance and drives team members to adopt.

My team is getting there collectively. Now we are managing some of our project status reporting, meetings, team locator, activity-task assignment, forum, and file sharing through the team community we have established.

Disclosure

My company is centered around a semantic wiki platform – currently optimized for IT groups (see Symcordia.com for more) so I do have a few axes to grind.  But I’m also a true believer in wikis as an enabler of collaboration and performance improvement. This is based upon my experience as a consultant and our client’s experiences using Symcordia™, our semantic wiki platform.  The platform is built on the underlying Confluence wiki engine, with a variety of plug-ins that add semantic properties, sortable tables, page ratings and so on.

Image “Classic Rock” by C.F. Payne courtesy of Reader’s Digest

Related articles
Enhanced by Zemanta

The Keys to IT Demand Management


Once again, I’m posting in response to a reader’s emailed question.  The reader wrote:

While trying to understand the difference between Demand management, Portfolio Management and Project management from an IT Infrastructure Service delivery perspective, I stumbled upon your blog and found some interesting reads.  Could you please share your thoughts on how to define Demand Management for a service delivery company – what is in-scope and out of scope?”

IT Leaders Tend to Focus on Supply Management

Delivering IT products and services has been challenging since businesses first became IT-dependent.  There’s lots of complexity, layers of specialization, an unnatural separation of IT producer and consumer, and significant capital investments.  Exacerbating this is the typically high ongoing maintenance and life cycle costs, rapidly changing generations of technology, with resulting technological obsolescence.  As a result, IT leaders have focused far more on supply management – figuring out their supply chains, providing security, integrity and stable services, squeezing out costs,and so on.

Meanwhile, the demand side has typically received short shrift.  Demand chains are unclear at best, and complexities such as the IT infrastructure implications of supply activities and changing technologies are opaque.  IT planners have a hard time answering fundamental questions such as, “What’s in the pipeline for the next 6 months?” or, “What is our projected resource utilization for the next 6 months?”

There are also common problems where demand meets supply – IT delivers products and services that business users don’t understand, did not really want, or did want but do not know how to extract the business value.  It is generally seen that IT’s job is to “deliver” the solution, but not to ensure it is working to full effect.

So, What is IT Demand Management?

According to Wikipedia:

Demand management is a planning methodology used to manage and forecast the demand of products and services. In business, the term is used to describe the proactive management of work initiatives (demand) with business constraints (supply).” (Bold font added for emphasis)

I like to think of IT demand management as:

A set of disciplines, tools, and governance mechanisms designed to surface, stimulate and shape business demand for IT products and services in balance with supply constraints.”

In other words, given that IT supply is always limited, how do we surface and shape demand to get optimum business value from limited IT supply?

Key Elements of IT Demand Management

Getting demand management working effectively requires an orchestration of several techniques and processes – and ultimately, a moderate to high level of Business-IT Maturity (earned through the focus on supply management mentioned above).

The key elements include:

  • Portfolio Management is an important demand management technique and tool (and, if implemented properly, a governance mechanism).  Portfolio Management can help balance IT demand across time horizons (short versus long term), across risk/reward profiles (high risk/high potential return, low risk/low potential return), across business units or business processes, and across IT investment categories, such as IT projects and programs versus IT infrastructure.  Portfolio Management can make these balancing acts explicit so that they become strategic choices (Portfolio Planning) rather than the result of natural “drift.”
  • Product and Service Life Cycle Management.  In the world of IT, creating a solution is a fraction of the cost – maintaining and evolving it, keeping up with changing business needs and shifting technologies is costly.  Traditional accounting practices add to the load as depreciation of capital expenditures creates an ongoing drag on funding sources.  So, ensuring that life cycle costs are taken into account with the initial investment, and managing product life cycles to ensure that necessary investments are made, and unnecessary products and services are retired in a timely fashion is a key Product and Service Management function.  Also, maximizing ‘reuse’ of products and services – “why bring in yet another Customer Relationship Management system when we already have three” is a common refrain that often goes unanswered.  Finally, understanding cost drivers, and influencing business behavior towards ‘responsible’ consumption of IT products and services is an important part of the demand management equation.
  • The role of the Business Relationship Manager (BRM) – the key interface between business and IT.  The BRM is an important demand management channel.
  • My reader’s question asked about what Project Management has to do with IT Demand Management.  Project Management is mostly a supply management technique.  However, poor project management can negatively impact demand.  For example, I’ve seen business behavior that essentially says, “I will ask for more than I need because I know IT will screw it up!”  Or, “I will ask for as much as I can get because I know nobody is keeping count on the results!”)
  • Though not mentioned in my reader’s question, Program Management embodies an important set of both Demand and Supply Management disciplines, tools and governance mechanisms.  Program Management is a critical linkage between Portfolio Management and Project Management.
  • Effective demand management also requires agile supply capabilities.  This is one of the best reasons for techniques such as selective outsourcing and cloud computing – being able to flex up as demand increases and scale back when it wanes.

The COBIT and ITIL Trap

I’m generally supportive of frameworks such as COBIT and ITIL – there’s no really good reason to reinvent these wheels – they embody ‘good practice’ for IT governance and service management respectively.  However, they have to be customized to fit your environment, and many companies short-change this activity and end up with processes-in-theory, but not in practice.  In other words, the processes, control objectives, and so on that they think they have are not what people actually do!

Another problem these frameworks can induce is deluding their proponents into thinking that tools and processes solve the problems of demand management.  Yes – you need clear, transparent demand (and supply) management processes, and these can certainly benefit from good frameworks and tools.

However, effective demand management hinges on strong business understanding and buy-in, highly skilled Business Relationship Mangers (or whatever you call people in that role) and robust business-IT governance.  In particular, governance must address how demand is justified, funded, and how benefits are tracked and accountability held for them.

 

Graphic courtesy of Vendeka

Related articles
Enhanced by Zemanta

Accelerating Individual and Organizational Learning – Case Study from a Rock Band: Part 1 of 2


My regular readers know that I post from time to time about how wikis can enable organization performance and increase organizational clarity.  (For example see here, here and here.)

In the interests of full disclosure, my company is centered around a semantic wiki platform (currently optimized for IT groups – see Symcordia.com for more) so I do have a few axes to grind.  But I’m also a true believer in wikis as an enabler of collaboration and performance improvement. This is based upon my experience as a consultant and our client’s experiences using  semantic wikis.  Symcordia™ is built on an underlying Confluence wiki engine, with a variety of plug-ins that add semantic properties, sortable tables, page ratings and so on.

From IT Leadership to a Rock and Roll Band!

I’ve also posted before on lessons from the performing arts – see here.  Now, I’m adding to my business and consulting experience through my ‘non-day job’ as a member of a rock and roll band.  We are using Symcordia to enable our development and learning – both for the band (organizational learning) and its members (individual learning).

The Importance of Passion as an Ingredient for Collaboration

I was excited to get into this as it combined two of my greatest passions – wiki-enablement of growth and learning, and playing rock and roll!  In the words of the band Cheap Trick – this feels like Heaven Tonight!  (My business partner, Roy Youngman, created an excellent post on the importance of passion to collaboration.)

As you read this, think about interest groups you might be part of at work – a special project team, a six sigma team or whatever.  How could you use a wiki to enable development and learning to increase their effectiveness and ignite some passion for their work?

Here’s the Back Story

Necessity, as they say, is the mother of invention.  We started the band – a conglomeration of 4 very passionate musicians – as a vehicle to cover classic rock songs.  Over the first week or so, we found ourselves trading emails, mostly with lists of songs to cover, styles and genres to try, suggestions for band names, and potential dates to meet for practice sessions.

Having spent several years of my career successfully using wikis as a way to escape from endless email streams and knowledge lost in Windows folders, I found this both inefficient and frustrating.  I tried to keep track of all the suggestions, consolidate them and publish them as “the list” of stuff we’d work on, but it was all but impossible to do.  The list kept changing – both in content and purpose (some of the song ideas were aspirational, some were deadly serious, some were deliberately frivolous).

I had this nightmare vision of us turning up for our first practice, with no collective idea of what we were working on – we’d each prepared a different set of parts for a different set of songs!  Each band member is more or less multi-instrumental, but when 4 band members have each prepared the same lead guitar part, and nobody has worked up the bass part, keyboard part, etc., there’s a train wreck in the making!

I believed there was a better way, so I quickly (initially about 3 hours work) built a band wiki using my company’s Symcordia™ platform and got the band members onto it.

Why a Wiki for a Band?

A band has several characteristics that make a wiki a great enabler:

  1. Playing in a band is a highly collaborative endeavor.  Wikis are inherently collaboration tools.
  2. Playing in a band demands shared knowledge:  What are we going to play?  Which key should we play it in?  Who will take which parts (e.g., lead vocal, harmony vocal)?  Wikis are a fabulous way of capturing and sharing knowledge.
  3. A band must develop and grow – or it dies on the vine.  Wikis are wonderful enablers of individual and collective growth and learning – they can put at your fingertips all that you need in terms of knowledge and tools to develop and grow – things like musical scores, YouTube tutorials, song lyrics.
  4. For a developing band, history and shared experience is crucial to learning: What did we try and why?  What worked well – and not so well?  A wiki is an ideal vehicle for capturing history and creating shared learning.
  5. A band depends on all sorts of creative decisions:  What’s the best sequence of songs for a given context?  Which settings worked best for amplifiers, mixing boards and effects pedals?  A wiki is a great way of enabling and capturing those decisions and the logic behind them – one place to keep a ‘single version of the truth.’

Please join me for Part 2 of this post in the next week or so – I’ll cover the basic design for the wiki, screen shots of how we are using it – especially, how we are leveraging the semantic properties, and our early experiences.

Graphic courtesy of Cox Mpoperi Wilson Education Consultants

Related articles
Enhanced by Zemanta

Corollary to my Post About the Value of LinkedIn Groups


Last week I posted something of a “rant,” questioning the value LinkedIn Groups.  I’ve received more email (though no comments on the blog!) about this post than any since I started blogging 5 years ago!  Many of these messages agreed with my observations, some did not.  One of the most insightful led me to post this – not as a retraction or correction, per se, but as a corollary.

The Value of Giving

One participant in one of the LinkedIn groups in which I participate – and it’s important to note that he is one of the most active participants – reminded me that there is one other aspect of the”ROI” on time and effort invested in LinkedIn groups I had ignored.  He wrote:

LinkedIn groups, like any other social medium, offer us a way to not only fully blossom into who we truly are, but they also provide an invaluable channel for others to connect with us.  …the true value of what we do is not really in what we receive, but in what we give…”

Of course, he is absolutely correct about the value of giving! I have given in terms of my time blogging and on LinkedIn (and other media) for the reason he cites – I get tremendous value from the act itself.  My blogging and my activities on social media help me think through and process how I am seeing and making sense of the world around me.  His email humbled me for ignoring this crucial aspect of the value of participation in groups such as LinkedIn.

My Lame Defense

In my defense, my rant about the value of LinkedIn groups was intended to be a message to the spammers and to all those who only want to “take” and never to “give.”  In some respects, I let my anger at them get the better of me – I probably should written the post – taken a deep breath – and then deleted it!

In the world of blogging, it is considered bad behavior to delete or change a post once published.  (And there have been a few posts over my 5 years that I wish I had not published, or wanted to rewrite!)  And, frankly, I’m not sure I would delete the rant even if it was standard practice to do so.  But my reader’s email to me was spot on – and I am glad to be able to add this corollary, saying what was left unsaid in the original post.

Related articles
Enhanced by Zemanta

Systems Thinking and Process Improvement – Pearls of Wisdom from Russ Ackoff


The late Dr. Russell Ackoff was described by Steven Brand as “the Einstein of Problem Solving”.  If you have ever brushed with the magic of Systems Thinking, you probably know who Russ Ackoff was.  He’s been described as a Renaissance Man, architect, city planner, philosopher, behavioral scientist.  He is considered the father of organizational systems theory and especially, Systems Thinking.

A nod to Alex Mathews and his excellent The Enterprise Advocate blog for coming across this excellent presentation.

 

If you are involved in any type of improvement effort, ask yourself (and your teammates) – are we approaching this with a whole systems perspective?  If not (the likely case!), what can you do about it?

Image courtesy of The Open University

Related articles
Enhanced by Zemanta

Who Owns the IT Operating Model?


I get into some great conversations with readers of my blog – often, however, they are ‘offline’ – i.e., via email or by phone, rather than through comments on posts.  I’ve been in such an exchange that I’d like to bring to the blog.  It’s around the question of, “Who owns the IT Operating Model?”

What Do We Mean By “Own”?

The specific question I initially got from my reader was:

Who owns the IT Operating Model within the organization?”

My initial response got into the issue of what we mean by “ownership” of an Operating Model.

In terms of practical implications, I like to think of the IT Operating Model as being “owned” by the IT leadership team – often with specific responsibilities allocated by domain (e.g., strategy, governance, delivery) to individual members of the IT leadership team. If it means, “who is responsible for its creation and effectiveness”, I’d say it really is the CIO.

In a subsequent email, the reader clarified his question as:

Who owns and updates “the story” – the document that explains how the organization works.

He went on to give his view that:

This owner must most definitely understand the entire organization and be a “listener” for change because if something changes how the organization operates then the model must be adjusted. This owner must be at the table with the leadership as well. I thought whoever owns strategy and planning would be the most logical home for this information.

I thought his suggestion that the owner of Strategy and Planning should own the IT Operating Model was fine, but I added the following caveat:

The IT Operating Model owner must have the respect of the organization, passion around the IT Operating Model, and some good instincts and/or experience with managing organizational change.”

The IT Operating Model Is Not Just About the IT Organization!

The reader’s comment, “if something changes how the organization operates” runs the risk of missing the fact that an IT Operating Model should be a model for all aspects of Information Technology.  Increasingly, many elements of the model will be outside of the IT organization, so there is an important element of business access to and ownership of the IT Operating Model.  For example, self-service guides and policies around “Bring Your Own Device” (BYOD) lend themselves to being part of the IT Operating Model.

The IT Operating Model Is Not a Document!

But what really struck me about the reader’s questions was his clarification that he was trying to determine “Who owns and updates ‘the story’ – the document that explains how the organization works.”  In other words, the IT Operating Model should be expressed in a document.

Documents Don’t Work As Means of Expressing Operating Models!

Documents are a lousy way to express Operating Models!

  • Documents create organizational confusion!  Where is the document?  Is this the latest version?  Why is its content inconsistent with other documents?
  • Documents reinforce organizational silos!  Who needs to know this?  Who should own it?  Who should review it?
  • Documents proliferate and deteriorate over time!  Multiple changes that are hard to track, linkages that break, definitions and terms that become lost over time.
  • People are disinclined to “read” or “use” documents – especially at the “moment of truth” when they are most relevant/mot important/most needed!

Documents Don’t Work As Means of Improving Operating Models!

For all the reasons above, and many more, documents are a lousy vehicle for engaging people in continuous improvement.  That’s why Wikipedia chose a wiki as the ideal platform for engaging the world in its remarkable achievement in capturing human knowledge.

From Static Documents to a Living Wiki!

That’s also why my partner and I have been helping clients with IT strategy and/or Operating Model changes implement them through wikis.  As a wiki, everyone can participate in the use and continuous improvement of the IT Operating Model.  The model becomes elevated from an abstract concept to a management tool and capability!  For more on this, please check out the video presentation on this page.

Related articles
Enhanced by Zemanta

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


This is the 3rd in a series on assessing IT Capabilities.  (See Part 1 and Part 2)

A Quick Recap

Part 1 introduced some assessment principles I’ve found to be important.  Part 2 defined the term IT Capability, presented a potential landscape, or normative model, if you will, for IT Capabilities, and discussed ways to determine what IT Capabilities are needed.

In this part we will examine assessment dimensions, options and ratings.

Assessment Dimensions

Figure 1 – Capability Assessment Dimensions

Figure 1 shows a capability assessment approach that uses 4 top-level dimensions – Purpose, Commitment, Ability and Accountability. Each dimension is decomposed into lower (leaf) level dimensions.  Purpose, for example, is a function of how clearly and effectively the service(s) produced by a capability are defined, and how clearly the goals for that capability and principles by which the capability operates are defined.

Note, there is a hierarchy implied among the top-level dimensions.  It is unreasonable to expect management commitment to a given capability if the purpose and goals for that capability are unclear or inappropriate.  It is unlikely that appropriate ability is in place without the necessary management commitment.  It is unreasonable to expect clarity of accountability for a given capability if ability is lacking.   In practice, I don’t usually disclose this hierarchical relationship until the assessment is underway, when I do use it as a validation mechanism.  For example, if the assessment team is scoring Accountability as fully in place, when they’ve scored Purpose or Commitment or Ability as not in place or only partially in place, then I know I need to challenge the team, and probe for the inconsistency.

Assessment Options

The multi-level assessment dimensions provide several options for the assessment method:

  1. Assess a capability at the top-level, but use the leaf levels to clarify what is meant by the top-level.  For example, I can assess the degree to which the Purpose of a given capability is in place by thinking about the effectiveness and clarity of the Service Definition for that capability, and the quality of the Goals and Guiding Principles for that capability.
  2. Assess a capability at the leaf level dimensions.
  3. Mix and match between top-level and leaf level dimension based upon the needs (purpose and goals of the assessment) and feasibility (available time, available knowledge) of the assessment situation.

Assessment Ratings

For any capability, for each dimension, a rating can be assessed as follows – the capability dimension is:

  • Fully in place – this is our universal practice and will be found to be used consistently, with few, if any, exceptions.
  • Mostly in place – this is common practice, though is not universal or not consistent, or there are frequent exceptions.  We know how to do this well – but we need to get better in practice.
  • Partially in place – this is not common practice, though we have many of the necessary characteristics, but not all of them.  We have some work to do to strengthen the capability as it exists as common practice.
  • Not in place – we have few, if any, of the necessary characteristics.  We have a great deal of work to do to develop this capability.

Note, there is clearly room for interpretation in these ratings.  This is more art than science, and for most IT capabilities, we are not dealing with highly mature processes and statistical process control!  From my experience, that is ok, and is why in Part 1 of this series that I said that my preference is to use a facilitated self-assessment approach – pull together a team of practitioners, customers and subject matter experts and facilitate them through the assessment.  It is usually the dialog this generates that has the most value, and leads to the insight and commitment from the team to initiate and sustain improvement efforts.  More on this in Part 4.

Assessment Dimension Descriptions

Below are brief descriptions for each top-level and leaf level assessment dimension.

Purpose

Are purposes and goals for the capability clearly defined and well understood?

  • Service/Product Definition
    • Is there a clear definition of the business purpose served by the capability and how this service/product integrates or links with other services and products?
    • Is there a clear definition of business outcomes for the service?
    • Have the service providers been identified? (e.g., dedicated internal service providers, external service providers, project team responsibility)
  • Goals and Guiding Principles
    • Are the appropriate opportunities to use the capability defined?
    • Are the goals established for use of the capability and/or its service providers?

Commitment

Has organizational commitment been demonstrated in terms of senior sponsorship and management responsibilities?

  • Sponsorship
    • Is there adequate understanding, support and management commitment to sustain the use of the capabilities and/or services?
    • Is there commitment by example?
  • Delivery Management
    • Is qualified management in place to provide oversight and direction for delivering the capability or service?
    • Are mechanisms in place to ensure that service delivery will improve over time?
  • Change Management
    • Is a change management strategy and plan in place to overcome issues of organizational resistance?

Ability

Have the baseline processes, role requirements, enabling technologies and deployment capabilities been established?

  • Process Definition
    • Has a documented process been implemented to guide work activities?
  • Roles and Competencies
    • Are required competencies and specific areas of specialization defined?
    • Are appropriate service providers identified and trained?
    • Are training/skill development processes defined and provided?
  • Tools and Technologies
    • Are tools and technologies in place to enable effective execution of the work processes?
  • Deployment
    • Are the service providers organized, ready, and able to provide service?
    • Are charging and cost allocation mechanisms in place?

Accountability

Have criteria for success and related consequences been defined?

  • Performance Management
    • Have measurable criteria for individual and group performance been defined?
    • Have measurable criteria for evaluating business results been defined?
    • Have necessary measurement/assessment approaches been instituted?
  • Consequence Management
    • Has a program to ensure usage been established?
    • Are the rewards for success and penalties for failure defined, communicated and implemented?
    • Have individual roles been defined including their inter-dependencies and how performance contributes to overall success?

 

Please join me for the 4th and final part in this series!  And please do weigh in with your own experiences, observations or questions!

 

Graphic courtesy of Tarun Trikha.com

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