The Britt-Webb Family

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

This post was inspired by some recent discussion on the IT Operating Models Group on LinkedIn.  Pär Nilsson, the Group’s moderator, posted the question:

What do you see as the cornerstone of an IT operating model?”

This question created some interesting discussion, from the insightful to the disdainful (but accurate!) observation that:

Operating Model is one of those buzz phrases that can mean different things to different people.”

Every IT Organization Has an Operating Model!

One of the noteworthy aspects of the discussion was that several participants seemed to view an IT Operating Model as something you may or may not choose to have.  I think that’s wrong – all IT organizations have an IT Operating Model.  The only questions, for me, are the degree to which the IT Operating Model is:

1. Effective? (i.e., delivers what the business needs in the most effective ways)
2. Efficient? (i.e., makes the best possible use of assets and resources)
3. Clear to all those that depend upon it? (i.e., stakeholders in and members of the IT organization)
4. Healthy (i.e., continuously improving and sustainable)

Way Beyond the Organization Chart!

In many IT organizations, the only explicit manifestation of the Operating Model is an organization chart!  This is an incredibly limited (and limiting!) way of expressing an Operating Model.  It says who reports to whom, but not what gets done or how it gets done.  It tells you nothing about decision rights, key metrics or the portfolio of services.  It tells you nothing about needed competencies or rules of engagement between functions and groups, or between the IT organization and its clients/customers/partners.

So, wherever you are, you do have an IT Operating Model.  You might not understand it.  It might be implicit rather than explicit. It might be badly broken.  But you still have one or you would not be able to ‘operate’.

The Cornerstone is Context-Dependent!

My response to the initial question was:

I think that all depends on the business context and business demand maturity against IT supply maturity. For example, for some environments, IT processes are the cornerstone; for others, it is business-IT governance; for others it is figuring out the proper balance between IT services that should be shared across business units, versus those that should be embedded in business units.  Ultimately, all these aspects (and many more!) are key – but you can’t address them all in one go, so figuring out where to start is the first trick!”

The Keys Are Organizational Clarity and Health

So, I believe that the keys to IT organizational performance are:

1. Defining what a healthy IT Operating Model would deliver – we might call this the IT Strategy
2. Defining how a healthy IT Operating Model would deliver that IT Strategy
3. Ensuring that the IT Operating Model is clear and transparent to its primary stakeholders

And I further believe that very best way to achieve these is to engage those primary stakeholders in:

1. Clarifying the IT Strategy
2. Clarifying the IT Operating Model
3. Continuously improving the IT Strategy and Operating Model

Web 2.0, Anybody?

And it won’t surprise any of my clients, colleagues or regular readers that I believe that the tools, technologies and sensibilities sometimes referred to as Web 2.0 can be an excellent enabler of IT Strategy and Operating Model clarification and continuous refinement.

Graphic courtesy of Kinsale

Related articles

• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 2 (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 3 (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance (vaughanmerlyn.com)
• Exploring an IT Operating Model for Enterprise 2.0 – Part 2

The term ‘collaboration’ gets thrown about as something inherently valuable and worthwhile – an end in itself, rather than a means to an end.  In reality, collaboration in of itself is:

a). Unlikely to happen
b). Unlikely to create anything of value

So Many Collaboration Platforms, So Little Collaboration!

Collaboration platforms are everywhere!  Most IT shops have at least one collaboration platform (usually SharePoint) and often several others.  And some people do participate.  The question is, with what result?  The answer often is little that is really worthwhile, and even less that can truly be called “collaboration.”

I used to wonder if there was something in our human nature that inherently resisted collaboration.  Of course, the opposite is true – human beings are both inherently gregarious and naturally collaborative – it’s in our instinct for survival.  The reason I was seeing so little collaboration on collaboration platforms was not that people did not want to collaborate – it’s that they did not understand (or believe in, or want) the purpose for collaboration.

The Collaboration Context

Alan Kay is credited with one of my favorite quotes, “Context is worth 80 IQ points!” In the case of collaboration, context not just the extra IQ points – it’s the whole enchilada of collaboration!

Several years ago, while I was an Executive Vice President at the The Concours Group – a management consulting, research and executive education firm, we were acquired by a company that had developed a collaboration platform.  Our new management was very keen for us to “eat our own dog food” and encouraged everyone in the company to get on the platform and ‘collaborate.’

I found this to be an interesting and enlightening experiment.  Most of us did indeed get on the platform.  Thoughts were posted and commented upon.  Interest groups popped up.  We had a ‘social reputation’ system, and I was proud the day my avatar suddenly listed me as a “Docent”, though I could not find out what that actually meant in this context!  After an early spike, usage dropped.

After a while, someone introduced Yammer into the firm.  A new groundswell of so-called “collaboration” surfaced, but after a while, that too dropped.  I observed that in spite of putting time and energy into “collaboration”, in reality, people were engaging in conversations that, while they may have been interesting, never went anywhere.  Conclusions were never drawn, deliverables were never created, insights never extracted, lessons never learned and applied.

The problem was not the tool – it was a lack of context.  There was no clear purpose or intent to the collaboration.

So, What’s Your Collaborative Intent?

• Are you trying to engage people in problem solving?  For example, stakeholders and/or subject matter experts might be invited to review and expand upon a cause-effect analysis.
• Are you trying to create a deliverable, such as a project proposal?  People might work together on creating the proposal, perhaps each working on their own section, but reviewing and commenting on others sections such that the whole is coherently structured and internally consistent.  Or you might wish to get everyone’s input to the whole proposal, rather than have people focus on their section.
• Do you want a community of practice or interest to capture and evolve a body of knowledge – best practices, templates, examples of how to do something, such as charter a project?
• Are you creating an ‘operating manual’ for an organization, with processes, roles, competencies, rules of engagement, and so on?  Perhaps people will be encouraged to not only create and/or refine the knowledge content, but will also rate the content based upon usability, clarity or how well the organization handles a given situation.
• Are you encouraging people to share across organizational silos – looking for points of leverage or redundancy?

Each of these ‘collaborative intents’ implies a specific goal or set of goals.  And each goal, in turn, might lend itself to a different type of collaboration mechanism.  While content or document management systems might be great for managing ‘documents of record’, they might not be so effective at encouraging multiple authorship.  In fact, document-centric tools tend to deepen and strengthen the traditional document mindset, where a document is something you email around to people to get their input.

It’s all a question of context – what are you hoping to gain through collaboration?  Is the goal clear?  Do those that must participate understand and believe in the goal?

Graphic courtesy of diagoal

Related articles

• The Semantic Wiki – Driving IT Organizational Clarity and Performance (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 2 (vaughanmerlyn.com)
• The maturation of enterprise social collaboration (blogs.computerworlduk.com)

I was talking to a senior IT leader at a global company this week, who said, “Our leadership team really needs to schedule some time to talk about strategic issues.  Our weekly IT Leadership Team meetings are consumed by tactical and operational stuff!”

This struck me as odd – and unfortunate!  “Tactical and operational stuff” should be on auto-pilot.  IT processes and management systems should take care of most things.  When I hear that an IT leadership team is consumed by the tactical and operational, my first reaction is that it is not a leadership team – it is a management team – a very different beast.

Leadership versus Management

Much has been written about the distinctions between leadership and management, so I won’t go far into this here.  For me, leadership is about influencing people, whether you have managerial authority over them or not.  Management is about exercising authority.  This basic distinction has important ramifications.  Leaders focus on the longer term and typically are concerned with achieving higher levels of performance for an organization.  Managers are more focused on the shorter term and on achieving agreed performance goals and objectives.

So, to recognize that “our leadership team doesn’t talk about strategic issues” is to recognize that it really isn’t a leadership team, it’s a management team.  That may be ok.  I worked with the CIO and his team at a major financial services company a while back.  They had been through a multi-year transformation under a new CIO.  The CIO and his team had been very ‘hands on’ and directive.  The results had been very positive, and the business clients of IT were impressed by the gains made from the transformation.  But, like many transformations I have seen, their performance improvement efforts had plateaued.  Managers and workers in the IT organization felt dis-empowered, so there was no real culture of continuous improvement.  The results of the annual engagement survey showed significantly lower employee engagement in IT than anywhere else in the company.

I raised the subject at an IT leadership team meeting, posing the question, “Are you a leadership team?  Or a management team?”  Consensus was quickly reached that they were a management team, with this finding justified by the sorry state of IT prior to the transformation, and the need for the top people in IT to drive change.

Which Do You Need – Leadership or Management?

I think that was a valid justification in their situation.  But the follow-up question, “What do you need to be now – a management or a leadership team?’ was much more contentious – especially as we drilled into what behavioral shifts would be implied if they did shift into a true leadership role.  For example, could they really trust their IT managers to manage?  If not, would they replace them with those they did trust to manage?

Dealing with this question and it’s implications became a major theme of my work with that team for the balance of the consulting engagement.  Great managers often have a hard time transitioning to a leadership role.  Great management teams have an even harder time transitioning to leadership teams – team members mutually reinforce each other’s instinct to be directive and in the details.

Have you fallen into the management trap?  How much time do you spend leading versus managing?

Graphic courtesy of Anthem Athletic Association

Related articles

• The IT Payoff From Years of Belt Tightening – Lower Costs, and High Dysfunctionality! (vaughanmerlyn.com)
• 4 Questions You Should Ask About Your Leadership (ChrisLoCurto.com)
• Managing a Virtual Team – HBR (bjconquest.com)

Mature IT organizations rightfully resist labels that separate them from the businesses they serve.  Any discussion of “IT” as distinct from “business” is anathema – a position I wholeheartedly support.  “Us and Them” made a fine title for a progressive rock tune back in 1973 but is an unhealthy perspective when the “them” is the business where profits are generated, and the “us” is essentially a support function.

Be that as it may, while the intent to resist separating IT and the business is worthy, there is a reality that in most enterprises the business generates revenues and profits while the support functions generate costs (necessary as those costs might be).  So when times are tough (or when a senior executive comes across some anecdote about the wonders of outsourcing IT to Timbuktu) the IT organization comes under pressure to take out costs.  Sooner or later, this comes down to reducing headcount, whether by natural attrition (IT managers represent a significant population ripe for retirement, and many have taken ‘packages’ to do so early) or by downsizing.

Let the Vicious Cycle Begin

And so begins the cycle – IT steps up to the plate and costs are reduced.  Early on, many of the reductions come from increased efficiency – improved Body Mass Index, if you will.  But muscle and bone are also lost, so delivered value is reduced, services are cut back and quality suffers.  The next time cost savings are needed, IT is again a worthy target – why not – they came through last time!  This time, more bone and muscle are lost.  At the risk of pushing the analogy too far, so is the proverbial membership to the gym (e.g., training, productivity and quality improvement programs) where some level of health was being maintained.  Healthy eating gives way to fast food and cola.  Nobody has the bandwidth to deal with the ‘essentials’ of keeping the lights on and trains running on time, let alone break new ground with the consumerization of IT or the move into Enterprise 2.0. Employee engagement suffers and IT performance degrades.

The cycle continues, and sooner or later top management becomes dysfunctional – not sure whether fight or flight are the best response – whether to embark on a full-blown transformation or simply to nibble at the edges with posters celebrating “Team IT” or the new “Agile” method to embrace.  Middle management is too busy to help with a fix – there’s hardly time to do annual performance reviews and budgets, let alone embark on major change programs. And the troops are, for the most part, disengaged – satisfied in accepting a reasonable wage to show up for work, but loath to give of any discretionary effort, or to put passion into their work.  Over time cynicism becomes so deep and wide, it is accepted as the ‘new normal.’  Discussion of organizational problems is all but banned by the IT leadership team – denial is best way to get through the week without the need for anti-depressant medications.

Forget Common Courtesy

In the downward spiral of belt tightening, age old protocols about responding to requests, answering emails, turning up at meetings on time or meeting commitments fall by the wayside.  As the leadership team slides into dysfunctional behavior, middle management follows by example and the troops aren’t far behind.  It’s a slippery slope, and one that’s tough to reverse!

Getting Back On Track

So, what can be done to reverse the slide – to turn the vicious cycle into one that drives increasing performance and leads to higher recognized business value from IT investments, assets and capabilities?  In practice, the catalyst for change is often a new CIO.  It’s not just that the new CIO brings in fresh ideas – it’s more about the energy and optimism they bring to the table.  If they are worthy of being hired into a turnaround position, they know they have a short ‘honeymoon’ period in which to create some visible signs that the slide is being reversed.  They probably negotiated some freedom to make change happen – reminding the executives that hired them that “businesses get the IT they deserve!”

Absent the new CIO, with the energy for change they embody and the breathing space they buy, my prognosis, I’m afraid, is not optimistic.  Einstein said, “We can’t solve problems by using the same kind of thinking we used when we created them.”  I think it’s a legitimate stretch to say, “We can’t solve problems with the same leadership that was in place when we created them!”

Image courtesy of Dysfunctional Psychology / Depression

This short post was inspired by Dion Hinchcliffe‘s recent post on the Consumerization of tech: The new enterprise disruptor.

Dion notes:

One trend has emerged with clarity from the discussions this year about the tidal wave of consumer tech moving into the enterprise: It’s profoundly reshaping the IT landscape in most organizations. Just a year ago, Bring-Your-Own-Device (BYOD) was barely on the strategic radar, yet a recent CDW survey of the federal government shows that as of last month, nearly half (44%) of federal employees now use a personal device for work purposes and that 62% of agencies now permit the use of worker provided devices.”

I’m not totally sure I believe the numbers – they seem somewhat aggressive to me given the typically conservative nature of federal government.  But Dion goes on to note:

Though data are still emerging about the trend in all industries, the early numbers in the private sector are even more dramatic, with a new report from Harris Interactive claiming that 81% of firms have already adopted some form of BYOD policy.”

Again, the numbers seem way aggressive per my conversations with IT leaders in the US, but the direction is clear.  And the movement now has its own acronym – BYOD (Bring Your Own Devices)!

A Compelling Argument…

This was the paragraph that most caught my eye:

This new mindset around IT is one where users tend to lead the IT charge. Not always, but increasingly so. They have frequently occurring technology needs on the ground. They also have the resources, time, and urgency to find the technology, or least more than the IT department does. So part of the consumerization story is a pull model of easy-to-access IT. Most of the time, it’s what they find in their browsers or app stores and on the shelf at their local mobile store or online electronics retailer.”

Bingo! The need is with the users. The funding is with the users. The resources are with the users. The urgency is felt by the users! So where is IT in all of this?

IT – The Protectors!

In spite of the rosy data Dion cites, I’m mostly seeing IT leadership either in denial (“This too shall pass!”) or anxiously assessing all possible risks and how to mitigate them.  Clearly, there are all sorts of risks – some of which we have yet to fully understand.  Infoworld’s recent BYOD: A world of pain awaits IT (subtitled: “Seasoned IT pros discuss the slings and arrows IT must endure to embrace bring-your-own-device policies”) lays out a litany of risks facing those who adopt BYOD policies.

The Real IT Choice

I believe the Consumerization of IT should be seen for what it is – a game changer for the world of corporate IT organizations.  One that will shape the future role of corporate IT and the future roles of IT professionals.  One that will unleash the creative power of IT in ways not previously seen, and that will have significant upside economic implications. This blog is titled “IT Organization Circa 2017″. That is 5 years away. I think those 5 years will see a massive shift in the center of mass of enterprise computing. Corporate IT can lead that shift – and stay relevant. Or they can study every nuance of every risk and put up barriers to change.  The change will happen anyway, and they will become all but irrelevant.

 

Related articles

• BYOD: Making sense of the work-personal device blur (infoworld.com)
• The essential strategy guide on the consumerization of IT (infoworld.com)
• Six Myths About the Consumerization of IT (news.dice.com)
• BYOD: A world of pain awaits IT (infoworld.com)
• Consumerization of tech: The new enterprise disruptor (zdnet.com)

My recent post on Questioning the Role of the Business Relationship Manager (BRM) has sparked some interesting discussions. One revolves around the question of “owning” the business-IT relationship. It’s a tricky question for several reasons:

1. “Ownership” is a tricky term in this context – just what does it mean to “own” a relationship?
2. There are at least two sides to any relationship – do all parties to the relationship see it in the same way?  If you “own” the relationship with me, do I recognize that and behave accordingly? Do I need to?
3. Context is everything – what works well for one company/one situation might not work at all for another!

Business-IT Relationship Issues

First, a small anecdote to frame the relationship ownership question. I recall interviewing a business executive about his needs and expectations from his IT organization. He said:

The last time I needed to talk about a possible new IT solution, I set up a meeting with my new Business Relationship Manager. Seven people from IT came to that meeting!  We had to find a conference room and move the meeting!  By the end of the meeting, most of those present had said nothing, but they had all furiously taken notes – presumably each capturing the same things.  No wonder IT costs too much and delivers too little!”

Too Many Cooks…

It’s a familiar situation – understandable but not acceptable! I imagine the seven IT folk included the BRM, a couple of Business Analysts, an Enterprise Architect, Project Manager and a couple of ‘subject matter experts‘.  They all wanted to be there so nobody would miss anything.  Perhaps they thought a “show of force” would impress the business client.  (In fact, it had the opposite effect!)

Too Many Specialists…

Yes – IT is complicated stuff, and ultimately, you have to get it right – 80% availability is not adequate for most IT solutions! This has led to an IT world that is full of specialties.  That is fine – but do all the specialties need to be represented in an initial meeting with the client?  How are the client’s needs best handled in terms of IT relationships?  How can we create an exceptional experience for our client?

The Need for a Single ‘Focus’ of Contact

The needs of both the business group and the IT organization are best served when there is a single ‘focus’ of contact – an individual who shepherds all contacts between business and IT.  This is one of the roles of the BRM.  Note, they are not a “Single Point of Contact” (SPOC), but they do “own” the business-IT relationship.  This means:

1. They are accountable for the success of the business-IT relationship.
2. As such, they need to be aware of all contacts between business and IT.  So, if I’m an Enterprise Architect, and I run into a business executive in a corridor and he mentions some specific need or IT issue, it is my responsibility to let the BRM know.
3. Similarly, as BRM, if I hear something through my business relationship that the Enterprise Architect should be aware of, it is my responsibility to let them know.

A good model to consider is the one followed by most consulting firms. They typically operate to a ‘rule of engagement’ whereby each client or prospect is ‘owned’ by a specific partner. If someone other than that partner has contact with the client or prospect (which was absolutely fine!) then they must ensure that the partner is aware of that contact.  This is seen as a common courtesy, both to the partner that owned the relationship and to the client – and a means to ensure an efficient, transparent client relationship. More importantly, it fosters strong relationships and a deep client knowledge.

Enabling the Business-IT Relationship

Business executives are not served by specific individuals – they are served by teams representing many facets of IT – operations, solutions delivery, support, training, architecture, and so on.  On the business side, there is typically not just one executive that represents a given business unit or function – there are many.

Taking the friction and noise out of these types of many-to-many business-IT relationships is crucial.  Clarity of the BRM role, their ownership of a given business-IT relationship, and an effective means of capturing and managing the myriad needs and activities are essential mechanisms for a healthy, productive business-IT relationship.

Tools such as Semantic Wikis and Customer Relationship Management solutions such as Salesforce.com can be effective enablers of many-to-many relationships such as those between business and IT, capturing all interactions and facts about the relationship.  Considering the size of IT investments and the business value that is on the line, investments in better managing business-IT relationships seem well-placed!

How clear is business-IT relationship ownership in your organization?  How well does it work?  Could better clarity around relationship ownership and rules of engagement improve the business-IT relationship?

 

Graphic courtesy of SmallBusinessFriends

Related articles

• Questioning the Role of the Business Relationship Manager (vaughanmerlyn.com)

I’ve been part of many organizational transformations over 30 years of management consulting.  Most were with IT organizations, many were with HR organizations and some were transformations to global shared services.

I used to be excited by the idea of an organizational transformation.  When a client or prospective client used the word “transformation” I would salivate!  “Them’s fighting words!”

But nowadays, I generally shy away from the “t” word. Here’s why.

The Trouble With Transformation

There are several reasons why I don’t like the word “transformation”:

• For most of the organization, it can feel demeaning, effectively sending the message, “You aren’t any good and you have to transform!”  That can be a bitter pill to swallow (and is almost always untrue – at least in part.)  Not the best way to enroll people in change!
• From the perspective of 2012, most people have been part of at least one organizational “transformation,” – it was painful and ultimately failed to deliver on its promises.  Announcing yet another transformation typically elicits the response, “Here we go again!” Organizational transformations tend to promise too much and deliver too little.
• Transformation implies a journey from current state to a future state by going through some kind of radical (transformational?) change.  Increasingly, organizations that are healthy, effective and growing in capability are in a state of constant change and adaption.  The current state → transformation → future state model no longer applies, so why delude ourselves and confuse everybody about having a transformation?
• Transformations are highly disruptive. They are disruptive because they assume that someone (or group) knows what the future state will look like – “all we have to do is to transform into that future state from our current state!”

To this last point, the reality is that organizational behavior is way too complex for anyone to “know” what the future state will look like.  Perhaps, way back when, in the days of hierarchical, authoritarian organizations in the early industrial revolution, a determinist approach to operating model design was feasible – especially if you thought you were transforming into a future state that would then be ‘frozen.’  We may well know the characteristics we would like to see in the future state, and the kinds of behaviors we’d like to experience, but exactly how we will get there, and what our Operating Model (processes, roles, rules of engagement, governance, services, metrics, etc.) will look like is far less certain.

I think organizational and operating model design nowadays is more about emergence – point people in the right direction, then get out of their way!  To that end, we need to define that direction:

1. Outcomes we’d like to see
2. Capabilities we need to achieve those outcomes
3. Processes, roles, competencies (i.e., knowledge, skills and behaviors) we need for those capabilities
4. Management and governance systems

Then we need to:

1. Over-communicate items 1 through 4 above – engage people in really understanding, co-developing and creating organizational clarity.
2. Empower them to do what is necessary, make sure they have the right tools and infrastructure and get out of their way.
3. Enable them with a meaningful way to participate in shaping their future – we have found that a semantic wiki can be a great vehicle to achieve this (see this post and the earlier posts (here and here) in the series).

Image courtesy of Wikipedia

Related articles

• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 3 (vaughanmerlyn.com)

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…

While the blustering goes on in the blogosphere, I thought I’d (ahem) cut to the chase and get serious about the Social Business opportunity in, well, spreadsheet terms. I popped into a little discussion  between Adam Holt at Morgan Stanley and Tony Zingale and Bryan LeBlanc  of Jive Software (JIVE).   Although specific business gains directly related to Social Business can’t always be divulged by large companies for a variety of reasons, we can take a look at the category as an investment play  and make some judgments about its viability.

To that end, here are a few key points CEO Zingale and CFO LeBlanc made to the investor community:

•  What’s different about the social business category is there are multiple entry points for a sale.  The sale could come from IT, Sales, Marketing, Customer Support, HR, Corporate Communications or more often than not a  Business Unit.  < Key learning: this is different in software investing.  Buyers abound.

• The Social Business story has reached a tipping point.  No longer are sales “missionary” sales.  There are line item budgets for social business software, and large RFPs are on the market from F1000 companies who are investing in these platforms.    Further, every software company is now incorporating social into its product suite, albeit mostly still relegated to “silo” functional software for specific departmental needs (Sales, HR, etc.)

• Social Software is not a “replacement” category of software like  Salesforce was with Seibel or Workday is with various ERP modules.  This is not a cloud v. on premise alternative. (Jive sells both on and off premise).

• The deals are larger.  Jive closed three million dollar plus deals in the fourth quarter of 2011.  Large institutions in various industry segments (PwC, Thomson Reuters, and Ace Insurance) chose Jive  to introduce a new way of working to their firms.

• Social Business software delivers real value to every knowledge worker in the enterprise. The market opportunity exceeds that of traditional enterprise software which typically serves a discrete business unit function (manufacturing, HR, finance, sales, etc.).

The JIVE call has some interesting nuggets about how JIVE is uniquely poised to compete against the other two main competitors in the enterprise space: IBM and Microsoft, but the essence of the story is about the legitimization of the social business category for the institutional buyer.  More importantly, this investor story is not even about technology and tools. It’s about organizations behaving differently by connecting and engaging with constituents.  The tools will come and go, but the behavioral change is a paradigm shift well worth the early entry.

Jive management took the company public on  December 13.  Since then, the stock has doubled and Jive’s market cap is $1.24B. Institutions hold 82%, so lots of pension funds are betting (not gambling) that social business is real. I’ll side with Wall Street on this one.

 

Example of Semantic Structure for an IT Operating Model

This is the 3rd and final part of a 3-part post.  (See Part 1 here and Part 2 here.)  This short series represents the culmination of 5+ years of work for my business partner, Roy Youngman, and me.

A Quick Recap

In Part 1, I discussed the frustration Roy and I felt with the state of management consulting, where the artifacts we’d leave behind (PowerPoint slides, Word documents, etc.) rarely became part of our client’s organizational fabric.  Also, the middle managers and the ‘troops’ who had to bring to life the strategies and operating models we were developing often did not get exposure to the work until relatively late in the day.  Because they had not been part of the work, they were slow to understand and embrace it.

I explained that we quickly recognized that the technologies and sensibilities of Web 2.0 and social media promised a better way to help our clients – a way that would engage broader and deeper participation by client staff at all levels, and would leave behind a ‘living, breathing’ IT strategy and/or IT operating model, captured as a set of wiki pages.  These pages were developed collaboratively with our clients, so the act of development and deployment essentially became concurrent – defining the IT operating model was part of deploying it, and vice versa.  We determined that a Semantic Wiki would be an ideal technology to support our consulting work – and more importantly, to provide a platform we could leave behind with our clients to empower their organizational collaboration and ongoing refinement and use of the IT strategy and operating model.

In Part 2, I went on to provide historical context for the wikis first introduction in 1995, and enumerated its strengths and weakness that were limiting IT organizations ability to collaborate effectively using traditional wikis. I went on to explain the concepts behind the Semantic Wiki and how these provided an ideal platform for enabling complex organizations such as IT, where multiple, different value propositions have to be supported.

Balancing Order and Chaos

IT organizations are surprisingly complex, supporting two fundamentally different value propositions:

• Core capabilities comprising the critical processes, assets and structures that help run the day-to-day business
• Edge capabilities where innovation, growth and change are cultivated

These distinct value propositions have Operating Model implications, requiring distinct forms of semantic wiki-enablement, as highlighted in Table 1 below.

Value Proposition

Example Capabilities

Needed Wiki Characteristics

Wiki Governance Model

Core

• Operations
• Service Management
• Enterprise Solutions

• Coherent integrated structure
• Stable space
• High integrity

• Globally governed
• Workflow controlled
• Process Owner as key control point

Edge

• Enterprise Architecture
• Product Management
• Departmental Solutions
• Project & Team Spaces
• Business Relationship Management
• Idea Generation

• Consistent modular structure
• Agile
• Support divergent discussion & brainstorming
• Content can migrate to Globally governed

• Domain governed
• Workflow optional
• Domain Owner as key control point

Table 1 – Types of Wiki Space

Globally Governed Space for ‘Core’ Capabilities

Core capabilities such as data center operations, service management and enterprise solutions (e.g., ERP systems) depend upon processes that are standardized, tightly controlled and centrally planned.  Management systems for these types of capability must focus on integrated, reliable, efficient processes and compliance to norms.

A wiki that supports core capabilities must be highly ordered and globally governed.  For example, each process should have a ‘Process Owner,’ with clearly defined accountabilities for maintaining and continuously improving their processes.  They need defined workflow mechanisms, for example, to control the promotion of a material change to a process page from ‘draft’ to ‘pending approval’ to ‘approved’ to ‘operational.’

Domain Governed Space for ‘Edge’ Capabilities

Edge capabilities, on the other hand, depend upon structures that are loosely knit, with agile processes that can rapidly adjust to entrepreneurial initiatives and fast-shifting technologies.   Management systems and organizational culture must foster new product success and the experimentation needed to get there.  Whereas core capabilities epitomize highly ordered environments, the edge represents the place where chaos and order meet and creativity blossoms.

A wiki that facilitates edge capabilities works best with limited structure and control, where, to paraphrase China’s Chairman Mao Zedong, “one thousand flowers bloom”.  Here the underlying semantic model will be centered on problem areas and the process of ideation, with Business Relationship Managers, Product Managers and Architects as the natural choice for the wiki’s points of control.

Today’s wiki platforms are helpful here, but we expect them to evolve to better support techniques such as brainstorming, innovation jams, mind mapping, and provide integration with tools for simulation and modeling, prediction markets, sentiment analysis and ‘light weight’ collaborative project management.

One Space – Two Wiki Models

IT organizational needs can be comfortably addressed in a single Semantic Wiki, with each value proposition having its own underlying semantic model and associated governance structure.   Having both ‘core’ and ‘edge’ capabilities supported in the same wiki space affords important benefits.  For example, everything is discoverable and linkable across the models.  These characteristics are all but impossible to achieve in a traditional document-centric collaboration approach.

If the primary goal of the core is to ‘prevent bad change’, a tightly structured semantic wiki with a robust governance model is a powerful way to support this goal and the organizations that must deliver against it.  If the primary goal of the edge is to ‘create good change’, a loosely governed semantic wiki with ‘sandboxes’ to generate and test ideas is a great way to support this goal.  Today’s leading wiki platforms, with their semantic extensions offer a single, integrated solution that can help drive IT organizational clarity and improve performance.

An Empowered, Continuously Improving IT Organization

Roy and I have found that encapsulating IT strategies and operating models in a semantic wiki has tremendous benefits that are simply not available in the more traditional approach some call, “death by PowerPoint!”  For example:

• A far broader group (and ultimately, the entire IT organization and their clients and partners) can be engaged in the process of strategy and IT operating model development and deployment.
• All the artifacts of strategy and IT operating models (strategy on a a page, key themes, business outcomes, major programs, metrics, processes, and so on) are immediately available to the organization and its stakeholders – this enables continuous improvement and evolution.
• Significant productivity increases result from having these artifacts available as shared wiki pages.  While the term “knowledge management” (KM) has fallen out of favor, the goals of KM continue to be highly relevant, and the end result of building a semantic wiki for the IT organization creates a very robust and powerful KM platform.
• A semantic wiki dramatically decreases email traffic and, more importantly, decreases the time taken to find information and increases the confidence that the information found is the ‘single source of truth’
• Adoption and organizational change management issues can be largely addressed by ensuring that use of the wiki is “in the natural flow of work.”  I will did further into this important concept in a future post!

Related articles

• Changing the Culture of an IT Organization – One Wiki Page at a Time! (vaughanmerlyn.com)
• More Hurdles in the Shift from Documents to Wikis (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 2 (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance (vaughanmerlyn.com)

This is the 2nd in a 3-part post representing the culmination of 5+ years of work for my business partner, Roy Youngman and me.

A Quick Recap

Roy and I had become frustrated with the state of management consulting and the lack of “stickiness” with our consulting work.  In helping clients develop business-IT strategies and realign their IT operating models, the deliverables we would leave behind as the artifacts of the work (usually PowerPoint slides, Word documents, etc.) rarely became part of the client’s organizational fabric.  Another source of frustration was that we’d typically arrive at those deliverables through a series of workshops – usually with the CIO and IT leadership team.  Middle managers and the ‘troops’ who had to bring those strategies and operating models to life often did not get exposure to the work until relatively late in the day.  Because they had not been part of the work, they were slow to understand and embrace it.

As Web 2.0 and social media began to take hold, we started to see and experiment with better ways to help our clients – engaging broader and deeper participation by client staff, and leaving behind a ‘living, breathing’ IT strategy and/or IT operating model, captured as a set of wiki pages developed collaboratively with our clients.  As such, the act of development and deployment became more concurrent.  Defining the IT operating model was part of deploying it, and vice versa.

However, we’d found that IT organizational attempts to improve collaboration and support knowledge management typically met with limited success, and that collaboration tools and platforms deployed by IT were falling short.  While the power and simplicity of wikis were appealing, their ‘one size fits all’ approach was not well suited to supporting an IT operating model.  We closed Part 1 by summarizing the strengths of a wiki, and suggesting that these strengths also create vulnerabilities.

The Proverbial Double-Edged Sword!

A wikis strengths also create vulnerabilities.  For example, the ease with which users can create and edit pages can quickly lead to a chaotic free-for-all, as content becomes subject to the whims of authors and editors, and absent a meaningful underlying structure, pages proliferate.  The lack of review before modifications are accepted can limit the credibility of a given wiki page as a ‘source of truth.’  A process definition, for example, may have been last edited by someone that introduced a serious error – and that error can proliferate as people refer to and use the process with the assumption that the content on the page is valid.

Sites such as Wikipedia mitigate these vulnerabilities through a robust system of editorial administration, oversight and management – enhanced by the ‘law of large numbers.’  In this case, with a sufficiently large universe of editors, the content of any page quickly converges towards a mean, reflecting “the wisdom of the crowd”.  But with an internal wiki – say one used by an IT organization or other shared services function, the law of large numbers does not apply, so without other mechanisms to manage structure and content, the wiki degrades in quality and value over time.

SharePoint as a Common Culprit!

This degradation is commonplace in organizations using Microsoft SharePoint as their collaboration platform.  While typically deployed to support collaboration, the reality quickly scales back to “a place to store documents”, which, in the words of one of my clients, soon degenerates to, “a place to lose documents!”

The other problem with SharePoint is that its strength is also its weakness.  While it is a good document management system, documents in of themselves are rarely the proper end goal of collaboration.  Collaboration is largely about having multiple authors create, evolve and use content, and documents are a poor medium for developing, codifying, and sharing knowledge.  Wikis provide a far more valuable alternative approach.  As my colleague Roy Youngman noted in his blog:

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.  A Wiki approach enhances the discovery of knowledge and exposes the subject matter in the greatest need of improvement.  And the improvement is a constant theme – the very heart and soul of a Wiki.”

Semantic Wikis to the Rescue!

But all is not lost, as the world of Web 2.0 gives way to Web 3.0, tapping into the special properties of the Semantic Web, a term first coined by Tim Berners-Lee.  Tim was the inventor of the World Wide Web and is director of the World Wide Web Consortium (W3C), which oversees the development of proposed Semantic Web standards.

Berners-Lee defines the Semantic Web as, “a web of data that can be processed directly and indirectly by machines.”  A Semantic Web goes beyond the traditional web concept of hyperlinked, human-readable web pages by inserting machine-readable metadata about pages and how they are related to each other.  This enables automated agents to access the Web more intelligently and perform tasks on behalf of users.  As the W3C describes it:

In addition to the classic ‘Web of documents,’ W3C is helping to build a technology stack to support a ‘Web of data,’ the sort of data you find in databases. The ultimate goal of the Web of data is to enable computers to do more useful work and to develop systems that can support trusted interactions over the network.”

In some respects, the Semantic Web is designed to overcome the all too familiar limitations of today’s Web – a proliferation of untrustworthy content that can be hard to navigate and make sense of.  Building on the Semantic Web concept and standards, a Semantic Wiki has an underlying model of the knowledge described in its pages, thereby capturing the meaning of the data within the wiki.

While traditional wikis have structured text and hyperlinks, a Semantic Wiki captures and identifies information about the data within its pages, and the relationships between pages, in ways that can be queried or exported like a database.  While conventional wikis provide users a simple means of expressing data and metadata, typically through tagging, Semantic Wikis include additional ways to express semantic declarations.  They are therefore able to understand and display the relationships between pages or other data.   For example, you can declare the underlying semantic properties of an IT Operating Model, such as:

• Processes require people taking on specific roles
• Roles point to specific competencies people must have to fill them
• Competencies comprise specific Knowledge, Skills and Behaviors
• Metrics define process performance

Having these semantic properties explicitly defined enables wiki governance rules and workflows – for example, someone defining a new process will be prompted to define the associated competencies needed for that process, and an appropriate template can be automatically loaded for defining those competencies, thereby encouraging consistency and quality.  A simple query can highlight roles that are missing, or identify associates who are qualified to fill a given role.

The graphic below shows a partial example of the underlying semantic structure for an IT Operating Model.

Example Semantic Structure for an IT Operating Model

Several wiki platforms offer semantic extensions, including Semantic MediaWiki (which extends MediaWiki, the underlying open source platform that powers Wikipedia) and zAgile’s Wikidsmart extension to Atlassian’s popular and powerful Confluence platform.

In combination with other plug-ins and extensions, such as Page Rating, Social Reputation, Workflow and Task Management, a Semantic Wiki can enable real and meaningful collaboration for IT organizations (or any other environment where collaboration can improve service quality, speed of delivery and organizational clarity.)

I will pick up in the 3rd and final part of this series by discussing the two primary value propositions for an IT organization and how a semantic wiki can provide a single integrated space for enabling these differentiated needs.

This will be Part 1 of a 3-part post.  This short series represents the culmination of 5+ years of work (on top of a 40 year career in IT!) for me and my business partner, Roy Youngman.  The series of posts also marks the formal announcement of The Merlyn Group, LLC, a business venture we actually started one year ago, but have been ‘flying below the radar’ while we worked with our initial clients and technology.

A Little Historical Context

Roy and I started working together at Ernst & Young back in the early 1990′s.  About 5 years ago, we both became very frustrated with the state of management consulting.  The main problem we saw was a lack of “stickiness” with our consulting work.

Most of our consulting work was either helping clients develop business-IT strategies, or helping them realign their IT operating models (processes, services, governance, organization, metrics, and so on), often in support of new Business-IT strategies.  Our deliverables typically comprised PowerPoint slides, Word documents and Excel spreadsheets.  While these all played an important part of informing and aligning our client teams, the artifacts we’d leave behind rarely became part of their organizational fabric.

This was exacerbated by the fact that we’d typically arrive at those deliverables through a series of workshops – usually with the CIO and IT leadership team.  Middle managers and the ‘troops’ who had to bring those strategies and operating models to life often did not get exposure to the work until relatively late in the day.  Because they had not been part of the work, they were slow to understand and embrace it.

A smaller, but no less important concern was the travel involved in all of this.  Post 9-11, travel costs typically added 20% to the cost of an engagement – good for the airlines and hotels, perhaps, but not good for the client and certainly not good for us.  Time lost commuting and the wear and tear on mind and body took their toll.

Enter “Consulting 2.0″…

As the technologies and sensibilities of Web 2.0 and social media began to take hold, Roy and I started to see a better way to help our clients – a way that would engage broader and deeper participation by client staff at all levels, and that would leave behind a ‘living, breathing’ IT strategy and/or IT operating model, captured as a set of wiki pages.  These pages were developed collaboratively with our clients, so the act of development and deployment essentially became concurrent.  Defining the IT operating model was part of deploying it, and vice versa.

This 3-part series of posts will explain how we did this, and highlight some of our key learnings along the way.

The Unmet Promise of Collaboration

We had observed that IT organizational attempts to improve collaboration, enable knowledge management and drive organizational clarity typically met with limited success.  In our research and consulting work, we’d found that limitations with collaboration tools and platforms deployed by IT were a key factor in these disappointing results and that a ‘one size fits all’ approach was all but doomed to failure.  Some aspects of IT require a highly structured and tightly governed approach to enabling collaboration – process management and continuous process improvement, for example.  Other aspects, such as enterprise architecture and business-IT relationship management work best with a looser and more emergent approach.

The Art and Science of Collaboration

The great news was that a new type of tool was emerging – the Semantic Wiki.  We recognized that a semantic wiki would easily accommodate the complexities inherent in IT Operating Models.  But first, let’s review how wikis came about – and how their strengths can create serious limitations for use in an IT organization.

1995 – The Wiki Is Born!

Wikis have been at the heart of collaboration since Ward Cunningham created the first Wiki, known as WikiWikiWeb in 1995.  Ward and co-author Bo Leuf, in their book The Wiki Way: Quick Collaboration on the Web, described the essence of the wiki concept as follows:

• A wiki invites all users to edit any page or to create new pages within the wiki Web site, using only a plain-vanilla Web browser without any extra add-ons.
• A wiki promotes meaningful topic associations between different pages by making page link creation almost intuitively easy and showing whether an intended target page exists or not.
• A wiki is not a carefully crafted site for casual visitors. Instead, it seeks to involve the visitor in an ongoing process of creation and collaboration that constantly changes the Web site landscape.

According to Wikipedia, the world’s best-known and largest wiki:

A wiki enables communities to write documents collaboratively, using a simple markup language and a web browser.  A wiki is essentially a database for creating, browsing, and searching through information. A wiki allows for non-linear, evolving, complex and networked text, argument and interaction.  A defining characteristic of wiki technology is the ease with which pages can be created and updated. Generally, there is no review before modifications are accepted.”

The Wikis Strengths

The keys to a wiki are:

1. The ease with which people can collaboratively create, access and edit documents.
2. The fact that those documents can be hyperlinked to create complex and networked text that allows the reader to navigate both linearly (as with traditional text) and non-linearly (jumping from idea to idea).
3. The ease with which documents can be searched – with the knowledge that you are always looking at the current and only version of the page.
4. As an inherently web-based concept, wikis benefit from evolving Web standards and technologies such as browsers, mark-up languages and even the magical world of open source – enabling Wiki users and developers to participate easily in a rapidly growing ecosystem of plug-ins.

The Proverbial Double-Edged Sword!

But these strengths also create vulnerabilities. Join me for Part 2 of this series, where will will look at the weaknesses of a wiki as an enabler of IT collaboration, and how a semantic wiki overcomes those limitations.

Graphic courtesy of Semantic Wikipedia

Related articles

• More Hurdles in the Shift from Documents to Wikis (vaughanmerlyn.com)
• Changing the Culture of an IT Organization – One Wiki Page at a Time! (vaughanmerlyn.com)