Walking Ever Faster Will Not Get You Running!

If, arbitrarily, you pick 3 levels of Business-IT Maturity – say Level 1 = low, Level 2 = medium and Level 3 = high, you will typically find that the things you have to do to get from Level 1 to Level 2 not only won’t get you from Level 2 to Level 3 – they will actually prevent you from reaching Level 3!  The trick is to recognize what these things are, and that you are entering a very different learning curve.  For example, if your solutions delivery process is broken, you need a great deal of rigor and discipline – in the form of Project Management and a Systems Development Life Cycle.  That will get you from “chaotic” (Level 1 in my hypothetical 3-Level scale) to “managed” (mid-Level 2).  But over time you will find the limitations of a “managed” approach to solutions delivery – especially when you need to implement “fuzzier” solutions, such as social media, or business analytics.

One Size Does Not Fit All

With solutions delivery, one-size does not fit all, and the methodology that works well for a relatively easily pre-specified transaction processing system (order-to-cash, for example) will not work well for something that is less predictable and more emergent.  Hanging in there with the “official” methodology (for fear of reverting to the chaotic situation that persuaded you to implement the methodology in the first place!) will frustrate the developers, annoy the business client, and will probably lead to a poor or unworkable solution – which will upset everybody!  What is needed is a finer-grained way of categorizing types of business solutions, and flexibility with methodologies to fit the best approach for a given solution type.

What Worked for Transactional Systems Won’t Work for Innovation Solutions

Collaboration and Knowledge Management initiatives are not readily planned using traditional project management methods – they tend to follow an ‘emergent’ pattern that is typically non-linear and somewhat unpredictable.   A traditional planning style, with detailed deliverables, work steps, activities and due-by dates must give way to a more iterative and organic approach.

Social Media Projects Should be Led

You cannot mandate participation in a community – you can invite participation and create reasons to do so. You cannot schedule a date by which a given percentage of a community will be collaborating on a wiki, for example – you can only set expectations, model desired behaviors, and create good reasons for people to become active users of the wiki.  Then you must reevaluate the results and adjust the approach in the light of experience.

Recognizing the Hard-Won Battle – and the Need to Fight New Battles

It seems that sometimes the battle of getting from Level 1 to Level 2 Business-IT Maturity is so hard won, and the win so apparently fragile, that leaders hang on to the methods that got them to Level 2.  This is about being really good at solving yesterday’s problems.  It’s a different world today, and the ways that technology and information can be exploited for business advantage demand different approaches.  Don’t let the trappings of Level 2 restrict your ability to get to the next level!

When to Edit, When to Comment?

I guess this issue exists equally with Word documents – MS Word has its powerful Reviewing mode with its ability to add comments or to actually edit a document.  The same is true on a Wiki – you can comment on a page, or you can go in and edit the page.  The difference is, we have all been commenting on and editing Word documents for years!  But when you get to a Wiki, you typically don’t have the years of experience, nor do we have the shared but tacit understanding of when commenting makes sense compared with editing.  To the Wiki novice, not feeling sure about when to edit versus comment can freeze you into inaction!  You feel much more ‘exposed’ about making either comments or edits – but edits feel somehow more ‘in your face.’

We have found that a few supporting pages (themselves, a natural fit for a Wiki approach) can be very helpful in covering questions such as “edit or comment”.  Examples include:

• Wiki Collaboration Guidelines and Procedures
• Wiki Manual of Conduct
• Wiki Manual of Style

Additionally, we have found that the gentle guiding hand of a Collaboration Manager and/or a Wiki Gardener can both demonstrate by example and, where appropriate, make adjustments to shift comments to in-line text edits or vice versa.  And, for those who can’t wait to find out the answer by trial and error, we’ve found the general principle is – if you are certain about the change you want to make, go ahead and make it!  The Wiki will let others with an interest in the page see the changes you have made, and they can always be backed out – nothing is ever lost!  If you are less certain, post a comment, quoting the text you want to change (most Wiki tools make that easy to do) and raising the points of discussion that lead you to be tentative about making the change.

Blank Pages Are Intimidating!

I’ve run experiments, creating a new page with an important page title (such as Potential Wiki Governance Principles) and asking folk to “weigh in.”  Perhaps not surprisingly, nobody does.  Add a few threads of text, or a contentious issue (that might be addressed by a principle or two) and people start to weigh in.  As I said, this is not surprising.  People are intimidated by blank pages.  Having said that, as a consultant who has facilitated hundreds of workshops, I know that starting with a “clean sheet” is rarely a good idea.  However, there are situations (and team dynamics) where a clean sheet is exactly the best place to start.  Which is why I ran the ‘blank page’ experiment.  At least one lesson learned would be: you can make things happen in a facilitated workshop that you can’t achieve on a Wiki!

Free, Open (and Risky?) Versus Controlled, Closed (and Safe?)

For whatever reason, my partner and I tend to find ourselves working on social media and collaboration initiatives with companies that have traditionally been somewhat “locked down” and conservative – often in highly regulated industries.  They have an inevitable (and understandable) bias towards controls and regulations – more concerned with “stopping bad things happening” than with “making good things happen!”  Unfortunately, this is not an ideal culture for open collaboration and knowledge exchange!  As much as they want to move to a more open and sharing culture, their natural instinct is to “govern and control.”

Given this, one of the issues we find ourselves coming back to as we navigate the changes inherent in becoming more open and collaborative is, ‘Do we manage the change from the current culture or from the culture we hope to change to?’  The temptation is to draw up a list of rules and create governance bodies and processes to manage the environment.  This is what people expect – but the question is, do such approaches serve to reinforce the current culture as opposed to fostering the desired culture?  Do rules and regulations send a message to people, that, “This is business as usual – be careful, think twice before you write or comment!”  And do such messages, unintended as they may be, tend to shut down otherwise valuable dialog and knowledge exchange?  Do they perpetuate the status quo?

We argue (and have demonstrated) that less rules and regulations are more effective in engaging stakeholders and fostering healthy dialog – without bringing the organization to its knees or being overrun with lawyers!  Of course, someone (the role is often called Wiki Gardener) has to monitor the site and take corrective action when needed.  They have to coach accidental transgressors.  Deliberate or malicious transgression is a performance management issue and must be handled as such – with firm and immediate action.

What have your experience been with Wikis in IT?  How have you handled “rules and regulations”?

Photo courtesy of Bionic Band: Home of Bionic Band Sports

Document Orientation – The Wikis Greatest Enemy!

My colleague and business partner Roy Youngman posted a while back on the question, “Why are Wikis in Corporate IT Rare?”  In the post he posited that most corporations, especially IT departments, are entrenched in a document-oriented approach as the means for developing, codifying, and sharing knowledge.  Roy made an important point that:

Paradoxically, ‘document-orientation’ is both the main reason why Wikis are rare in the corporate world and the main reason why Wikis are great for the corporate world.”

Wiki Benefits – A Solution to the Shackles of Document-Centricity!

Roy went on to explain that:

The Wiki approach addresses almost all the short-comings of ‘document-orientation’.  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.”

From Document to Wiki – Changing Mindsets One Page at a Time!

I’ve been using document-centric tools such as Word and PowerPoint since they first became available in the late 1970′s.  Beyond the simple accessing of Wikipedia, I’ve been actively using Wikis such a MediaWiki and Confluence since 2005.  So I have significant experience both in the traditional world of documents, and the more contemporary world of Wikis.  And I can tell you, the shift from document-centricity to Wikis is non-trivial!  I can also tell, it is HUGELY BENEFICIAL!

Here’s a sampling of the mental hurdles I’ve had to navigate in order to realize the full benefits of a Wiki approach.

When to “Polish” Versus When to “Collaboratively Evolve”?

Historically, when I’ve been creating some kind of deliverable (a Word document Project Charter, or a client project briefing PowerPoint deck for example) I’ve always felt that it has to be polished to a high degree.  Many years ago, a wise and seasoned consultant and mentor advised me to always produce quality documents – both in terms of content and look and feel.  He said, “If it looks shabby and full of typos, how can you expect the client to take it seriously?”  The latter point is not necessarily obvious based on the deliverables I see from many consultants.  As an example, I saw a key deliverable produced by a large consulting firm that was full of typos, grammatical and formatting errors.  The final insult was that a PowerPoint slide misspelled the CIO’s name – in a key presentation that was given to the CIO!

By contrast, when I start to create a Wiki page, I feel almost obliged (and grateful!) to start with a much rougher “draft” and look forward to the ensuing “collaborative polishing” that will emerge.  Sounds obvious, but getting comfortable with a “rough draft” as a starting point did not come easily to me until I began to notice that people were less inclined to collaborate on a document if it looked highly polished and “print ready”.  Learning when to “polish” and when to release “draft” material is not always obvious and is very situationally dependent – demanding a keen sensitivity to the specific context for the document.

Structure, Linking, Tagging and Factoring in a Wiki World

I’ve always paid attention to document structure.  I believe I understand the basic principles of good structure, and learned a lot about logical structure from the powerful Minto Pyramid Principle back in the late 1980′s.  But when you get to a Wiki, things change!  The ability to hot-link across “documents” and to external sources in ways that just don’t work in a document-based world (who knows where any given document will be located?) changes the way you think about structure.

Tagging and Folksonomies create another layer of possibilities (and another layer to think about!) that is rarely used effectively in a traditional document environment.  The concept of factoring, well understood (if not always followed!) by programmers, involves structuring content for maximum reusability, minimum redundancy, and ease of search.  These are typically not considerations in a traditional document approach.

One of the many benefits of a Wiki is that it enables an entire collection of ideas and information to be placed into a single, hyper-linked space.  But if that space is a messy structure, the benefits may quickly erode.  If you aren’t a programmer (or, at least, not a good programmer!) you may need access to a Wiki expert for help in thinking through the structuring of a given space – especially if you are using a Wiki that allows for a hierarchical structure among pages.

Does eMail Traffic Really Reduce?

A client I was working with recently was (appropriately!) paranoid about anything that drove up eMail traffic.  When they learned that the Wiki could send eMail notifications about changes, they were immediately hesitant to utilize this feature.  While it’s natural to want to find ways to reduce eMail traffic, we’ve found that there’s an important distinction between “normal” eMails, that come from people and automatic notifications.  The former typically demands time and activity – responding to the email.  The latter is purely and helpfully informational.  Also, if you aren’t finding the information helpful, then turn off the automatic alerts!

The great news for this client, in addition to discovering that automatic informational eMails in the form of Wiki alerts were far less intrusive and demanding than real eMails from people, was that the transition to a Wiki approach dramatically reduced the person-to-person eMail traffic, as the endless cycle of passing documents around was replaced by collaborative editing of a Wiki.

I’ll look at more of these “mindset changes” associated with the shift to Wikis in upcoming posts.

Image courtesy of Westwood K-8 Technology

My New Venture

The venture is a partnership with my dear friend and long-time colleague, Roy Youngman.  (See Roy’s blog).  Roy and I have been on a fascinating journey over the last 20 years – learning about the levers that impact IT performance and business value.  Back in the 1990′s, I was a Partner at Ernst & Young‘s Center for Business Innovation while Roy led a team at the Center for Information Systems Planning and Delivery, taking what the Innovation Center discovered and developing tools and methods for use by E&Y’s consultants and clients.   Since then, Roy and I worked together at The Concours Group (and nGenera, when they absorbed Concours) and as independent consultants.

Social Tools Shape a Vision…

For the last 5 years, we have focused on driving IT improvement using social media and, though I hesitate to use the term, leveraging Web 2.0 and 3.0 capabilities.  We have worked together on client engagements and multi-company research.  We have worked to improve how management consulting works – a process that has always struck us as a “leaky” and inefficient!

We’ve focused on three questions:

1. How can the business value of IT be increased using the kinds of social tools that are transforming they ways friends and communities interact, share and collaborate?
2. How can social networking and collaboration capabilities be used to increase organizational clarity and drive higher engagement among IT professionals?
3. How can the knowledge transfer process be improved to, within and between our clients?

We’ve worked with various tools (e.g., SharePoint, MediaWiki, Confluence) and with a variety of plug-ins and extensions in support of IT organizations who are trying to improve their performance and the value they deliver to their business clients and customers. We’ve created a meta-model of IT Capabilities.  We’ve created an architecture for a Semantic Wiki, based on this meta-model and populated from our combined 60 years of IT experience.

The ‘learning journey’ has been rewarding, and from it a vision has emerged – one where IT professionals and their customers deliver services through a Web-based social context.  I will use this blog to post about what we have learned and are learning.

In time, we will create a separate web site and provide the means for others to collaborate with us on this journey, but for now we are strictly focused on our client work (and our respective blogs!)

Some Early “Lessons Learned”

Create a baseline quickly

Set the quality bar high, and make rapid, incremental improvements thereafter.  The name of the game is “emergence” – you need sufficient structure to help people have some sense of the destination, but not so much that they can’t participate in shaping the journey.

The most effective way to instill change is through “Pathfinder Projects”

Pathfinder Projects are ones that have to be undertaken anyway (their primary purpose) but that have an explicit secondary purpose of leveraging one or more social capabilities, such as a Wiki (e.g., adding quality content) as an outcome of the project.

Be “in the flow”

The social tools need to be incorporated into the natural work flow.

Take a ‘cascading’ approach to deployment

Deploy in “waves”, starting with IT leadership and Pathfinder Projects, continuing with Process Owners, natural Communities of Practice, and grow from there based upon how the collaborative/social energy flows.  But also be sensitive to naturally emerging opportunities – go to where the puck is going!

Pride in workmanship trumps controls!

It is far more important to instill a pride-in-workmanship than to install a complex review and control process.

Expect a Power-Law distribution

A Power-Law Distribution is expected and good; a few will contribute a lot and some will contribute little, but everyone has something worth contributing.

Leaders demonstrate commitment by example

Leaders must demonstrate their commitment ‘by example’ while avoiding the temptation to criticize (which will be initially easy).

Are you working with Social Tools to improve IT work?  What are you doing and how is it working?

Image courtesy of pcms consulting

What is IT Renewal?

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

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

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

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

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

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

The “Five C’s” of Information Management

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

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

Enabling the “Five C’s” in the Cloud

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

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

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

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

Collaborating on IT Work

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

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

Coordinating Activities in Time and Space

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

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

Connecting People and Ideas

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

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

Co-Creating Experiences

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

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

Coalescing Around Ideas and Reaching Consensus on Decisions

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

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

Summary

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

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

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

Illustration courtesy of Suzanne Lebeda at Adirondack Artists’ Guild

Related articles

• Leveraging the Cloud to Accelerate IT Renewal – Part 2 (vaughanmerlyn.com)

Some Principles for ‘Social’ IT Management

Over the course of several client engagements, Roy and I have developed a short list of principles to guide the way we help a client move towards a ‘social’ approach to IT management:

• Create a baseline quickly, set the quality bar high, and make rapid, incremental improvements thereafter.
  • Rationale: The emergent and more parallel process implied by a social approach can feel a little intimidating at first.  “Will I look like a fool?  How will my co-authors react?”  We’ve found that the best way forward is to “Just do it!”  Get started, and damn the torpedoes!  But also, don’t ask people to begin with a blank slate.  While some clients are o.k. starting from scratch, most prefer a starting point – a straw dog, if you will.  Having said that, it’s important to make it clear that the straw dog is just a starting point – that the expectation is that this will be refined into something we can really use and be proud of!
• Follow a ‘cascading’ approach – deploy in waves, starting with IT leadership, rapidly engage Process Owners, then members of Centers of Excellence, and finally everyone.
  • Rationale: To be frank, there is something “1.0″ about this cascading approach – it’s rather top-down which flies in the face of a truly emergent, egalitarian and collaborative approach.  But most organizations have a hard time jumping from the “1.0″ to the “2.0″ paradigm.  So, we’ve found a “1.5″ approach to be a useful interim state.  It acknowledges the special role of the IT leadership team, and the reality of engaging them first.  It also puts them in a better position of experiencing the new approach and being able to model desired behaviors.  The trick is not to get stuck in a mode where everything has to start with the IT leadership team.  Get the process owners appointed early (they usually already exist, even if that role has not been formalized) and they in turn will engage process teams.  Typically, there are Centers of Excellence or Communities of Practice that are already blogging and participating in wikis (the IT architecture community is often an early adopter) so it is a natural to bring them into the tent.  Just be careful to not shut down their activity by legitimizing it.  They thrive as a 2.0 collaborative community because that was a truly emergent practice for them.  Legitimizing this practice as “leadership sanctioned and monitored” can shut it down, or drive it back underground, so don’t be too heavy handed in this sanctioning – shine a light on it, but not a floodlight!
• It is far more important to instill pride-in-workmanship than to install a complex review and control process.
  • Rationale: Coming from the 1.0 world, it is natural for leadership to want to place controls all over the wiki environment.  I recall one client executive, when I first described the plans for their ‘social’ IT management, looking aghast, and saying, “You aren’t seriously suggesting we’d let stuff go up on the Wiki before it was fully vetted and approved?”  This is a natural reaction, but must be resisted.  The power and wisdom of the crowd to shape and continuously improve is relentless – if you let it be!
• A Power-Law Distribution is expected and good; a few will contribute a lot and some will contribute little, but everyone has something worth contributing.
  • Rationale:  There’s no way around this.  It’s a well-researched and documented phenomenon.  Your major contributions will be limited to a small proportion of the IT organization.  Many will seemingly be bystanders.  The fact that they aren’t in the Wiki every day, participating in discussion threads, creating Wiki pages does not mean they aren’t participating or getting value from the it – they are.  Don’t be put off by it – just accept it and be thankful.
• Leaders must demonstrate their commitment ‘by example’ while avoiding the temptation to criticize (which will be initially easy).
  • Rationale: Early on, people will look to IT leadership to see if they are “walking the talk.”  If they are, others will join the revolution.  If they are not – this too shall pass!
• Consistency is a key to success; if every content page looks different, the Social platform will not create a sustainable social web.
  • Rationale: The emergent properties are a good force to tap, but can be a double-edged sword.  We’ve seen many clients with SharePoint (or Lotus Notes way back) where people were encouraged to participate. And participate they did – in spades!  Before long there were SharePoint sites everywhere – each with their own structure and style.  Pretty soon, the collaboration ecosystem is un-navigable.  You have to strike a balance between emergent and structured – and consistency in style and structure are important to sustain this.  Provide templates to make it easy for people to conform to a common style.  And have active Collaboration Managers and Wiki Gardeners whose role includes encouraging a clean and consistent style.

We will end this 3-part series here – but please keep an eye open for upcoming posts that further explore our work in this space.  Or ping Roy or me for a discussion on how this might apply in your organization.

And, of course, please comment on your thoughts and experiences – this is an emerging space, and we all have lots to learn about social means to improving IT management!

Graphic courtesy of Literate Web

Related articles

• ‘Social’ IT Management – Part 1 (vaughanmerlyn.com)
• ‘Social’ IT Management – Part 2 (vaughanmerlyn.com)
• Who should be in charge of Enterprise 2.0? | ZDNet (zdnet.com)
• Enterprise 2.0: at an Inflection Point – Express Computer (expresscomputeronline.com)

So, What Have We Learned from the Experiments?

We’ve learned that we can use tools like SharePoint, Confluence, and MediaWiki to organize the institutional knowledge of an IT environment, which not only improves organizational clarity, but also empowers IT resources to become greater masters of their fates.  Figure 1 below illustrates an example around process knowledge using an extension of the basic SIPOC technique.

Figure 1

The tool can capture information about IT processes, the roles people play in the performance of a process, the competencies these people need to be successful in those roles, a description of the deliverables a process produces, and much more.  The approach handles best-practices across the IT industry so any one IT department doesn’t have to reinvent-the-wheel.  And the whole thing serves as a collaboration hub that encourages community ownership and continuous improvement of practices, processes and so on.

A Wiki Core

At the core of the collaboration hub is Wiki technology.  We’ve also learned from our recent work that Wikis are rare in IT organizations, in large part because corporate organizations are heavily invested in “documents” as the means for developing, codifying, and sharing knowledge.  Paradoxically, we’ve discovered that this “document-centric” approach is both the main reason why Wikis are rare in the corporate IT world and why Wikis are great for the corporate IT world, so it is worth examining the differences.

From Document-Centric…

Figure 2

Figure 2 above shows how the document-centric approach works. Using MS Office products like Word, a team of people work on a subject (like documenting a process).  Everyone tends to work independently both in the authoring of their assignments or the review of material others have written.  Many versions of the document are created, stored in many places, and passed around in the process.  It is usually a difficult task to consolidate everyone’s input and more often than not, one person has to step forward and take on the bulk of the writing and editing.  When complete, there is little desire or motivation to change it for the better because creating it in the first place was so painful.  So it stagnates.  Eventually, other documents are written that contradict portions of the old document, confusing the few people who do know how to find them and take the time to read them.

…To Wiki-Centric

Figure 3

The Wiki approach shown in Figure 3 above is distinctively different.  Unlike a document, which is designed to be self-contained and read from beginning to end, a Wiki is nonlinear.  Using a design such as that described in Figure 1, the content can be well-factored, thereby minimizing redundancies and preventing contradictions that confuse people.  The nonlinear approach also allows people to focus and contribute to whatever area of expertise each person happens to have.  When multiple people have similar subject knowledge or interests, they find each other naturally in the process and synergy happens.

As a hub, the Wiki enhances the discovery of knowledge and exposes the subject matter in the greatest need of improvement.  The Wiki approach supports “divergent-thinking” (which is essential to allow anything to improve) through focused conversations and social measurement techniques. It also supports “convergent-thinking” (which is essential to ever arrive at clear conclusions) through the version control and workflow features inherent in Wiki technology.  The clear advantage of the Wiki is its ability to depict the best portrayal of knowledge currently available at any time while constantly encouraging a community to expand and improve it.

The contrast between Figures 2 and 3 is dramatic.  Corporate IT has a lot of investment in the document-centric approach.  But the return on that investment has been dismal and most IT people will testify to that.

So why then are Wiki’s still so rare in the Corporate IT world?  As is often the case when dealing with unfamiliar territory, “better the devil you know” is the typical rationale.  Ah, but this excuse is starting to fail in corporate IT departments.  Why? Because other departments throughout the business are discovering the benefits of Wikis and getting ahead of IT – the cat is out of the bag!  Many progressive CIOs have seen this trend and want to create an IT organization that enables Social Business rather than just reacts to it.  They want to better manage and leverage the knowledge trapped in their organizations and in tens of thousands of documents lost in personal and shared drives.

In spite of the inherent difficulties, we applaud such vision and have developed a set of principles we have found helpful in moving to a Social approach to IT management.  We will present next in the third and final post of this series.

Related articles

• ‘Social’ IT Management – Part 1 (vaughanmerlyn.com)
• Seven wiki adoption techniques for the enterprise – Blog the web (sherifmansour.com)
• Wikis: A Beginner’s Look (meredith.wolfwater.com)
• Exploring Semantic Media Wiki (dorai.wordpress.com)
• Jimmy Wales to Announce Wiki 2.0 with Wikia (readwriteweb.com)

I felt the need to comment on his ITIL post because of an assertion he made about organizational change.  I then decided to turn my comment into a post of its own (get ‘em where you can, right?)

People Don’t Hate Change!

Elliot asserted “People hate change. Period!”  I think this is a common misconception – or at least, a misstatement.   People make changes all the time, and for every one person that has a cautious, conservative approach to change, there is at least one other who embraces and even seeks out change!  I’ve seen theories (though not the research to substantiate them!) that in any population, one third are highly receptive to change – may even make the change without being prodded.  One third are highly resistant to change and will fight it tooth and nail.  And one third will look to the other two-thirds and decide which path to follow.  This, of course, is overly simplistic, and probably wrong!  But I have to admit that whenever I’ve suggested the hypothesis to clients, it seems to resonate and match with their own experience, so perhaps there’s something to it?  Anyway, I’ve found it to be a useful framework to use in designing change programs.

People Hate Being Changed!

People don’t hate change, but they don’t like being changed! That’s a key distinction, IMHO.  So, for successful change, engage the people who must change in the change, make clear to them why it’s beneficial to them – the familiar “What’s In It For Me” (WIFM) ingredient and they will flock to it – or at least, one third of them will.  One third will fight it all the way, and the middle third will watch to see how the mythical wind is blowing.

Different Types of Change

Of course, change is a complex and multi-faceted concept, so any generalizations about it are fraught with problems.  For example, changing a simple routine – say, a new way to record your time – is quite different from moving from one boss to another.  Even more extreme is to change culture – to ‘build quality in’ for example, or become ‘customer focused’ as some change programs exhort!  These types of change require that you understand what changed behaviors are expected, believe in the need for those changes, have or can develop the required knowledge, skills and behaviors, and are willing to invest significant personal effort and take personal risk to make the change!

The Importance of Consequences!

Elliot made an excellent point about change and consequences:

If there is a lack of responsibility and consequences, people instinctively return to the old way of doing things.”

If there are no positive consequences for those who embrace the change, and/or no negative consequences for those who reject it, then the middle third in the framework introduced above will likely reject the change, the critical mass will never materialize, and the change is a lost cause.

And this lack of consequences is, from my experience, a very common problem.  I’ve had CIO‘s complain to me, “We aren’t great at implementation and follow through!”  I typically get into the “5 why‘s” routine.  “Why aren’t you good at implementation?”  And I keep asking why until they tell me, “We don’t hold people accountable.” or “There are no consequences for them following through or not.”  One more “why” from me usually gives them the mirror they need to see – they see and recognize the enemy!

Image courtesy of The Rubicon

Various approaches are deployed to bring consistency and effectiveness to Project Management disciplines – Centers of Excellence (CoE), Project (and Program and Portfolio) Management Offices (PMO), certifications (such as PMI), and so on.  But there’s a dirty little secret out there…

Many Projects Are Managed By “Amateurs”

By “amateurs,” I mean people who are operating outside the supposed disciplines, processes and standards of the PMO or CoE.  There are several reasons behind this:

1. In some cases, it is simply a result of project work being deliberately flown ‘under the radar.’  I’ve consulted to IT shops where this is actually an effective way to get things done. It goes hand-in-hand with an “ask forgiveness, not permission” culture!
2. Sometimes it is because the thing isn’t recognized as being a project until it is well underway – or maybe complete – or maybe never!  This is an issue that was recognized by the wonderful Jerry Weinberg in his early books on project management.
3. In other cases, it is wanton disregard for the recommended (or even mandated) standards.  “These standards don’t apply to me.”  “They are too onerous for this particular project.”  “I don’t need them because I know what I’m doing.” And so on.
4. In a few cases, it is sheer ignorance – not being aware that what you are doing IS project management, and would better be performed under the auspices of the rules and guidelines at play.
5. One important driver of “Accidental Project Management” is inflexibility in the “official” Project Management methods.

Not All Projects Are Created Equal

To paraphrase Aldous Huxley, “Not all projects are created equal!”  Some deserve more rigor and discipline than others.  And some deserve different types of discipline.  For example, while many projects are most concerned with deliverables, budgets, resources and so on, planned against target dates, others deal with “softer” and more organic situations, where “emergence” is the key property and where planning by target date is unrealistic.

For example, a project that plans for, “30% of the IT organization will participate in the IT Strategy Wiki by July 31″ is not a valid planning approach.  Social activities work best through a “pull” approach – let’s identify the things that can be done to encourage and facilitate the “pull” and plan those.  The 30% participation may be a reasonable goal and outcome, but it is not a planning parameter in the sense of traditional project management.  To plan assuming that date will be reached is sheer guesswork, and anything else in the plan that depends upon this milestone is at risk.  I guess you call call the planning approach for these more emergent based needs, “Do while…” rather than the more deterministic, “Do until…”

Increasing Project Discipline Without Communism

So, what, if anything, can be done to reign in the Accidental Project Manager?

1. First, decide if it matters.  Identify the real problems that loose project disciplines cause.  One problem may be that it’s the beginning of a slippery slope.  It sends a message that we “have standards and disciplines you should follow, but… (nod and a wink!) it’s ok if you choose not to follow them!  Another problem is that you may have bad projects – projects that suffer through not being well (or consistently) managed, or projects that should not be undertaken.  I often see a cause of waste and dysfunction in my clients in projects that should not be going on, rather than projects that are badly run.  A big problem is the implications ‘out of control’ projects have on resource management.  You just don’t really know what people are working on, and what availability they may have.
2. Second, if you decide it does matter, determine why it is happening?  Don’t make a big deal of this – you may drive the behaviors underground.  Rather, do an informal poll – water cooler chats – ask people to ask people – try to get a sense of why people act outside the “official” practices.

Chances are you will find root causes to be:

• Ignorance (lack of awareness and training)
• Inflexibility in the “official” practices (‘sledgehammers to crack nuts,’ for example)
• Lack of bandwidth in the PMO (“they just don’t have time to help me!”)
• Poor “official” practices (“too bureaucratic, more designed for the benefit of the PMO than for those trying to manage projects!”)

The Problems with Traditional Strategy Formulation Approaches

I think the supporting evidence for my findings lies in the fact that most companies either:

1. Don’t undertake strategy formulation initiatives unless they feel they have to (e.g., 5 or more years have passed since they last conducted a strategy session, or the current strategy is clearly not working!)
2. Do undertake strategy formulation regularly and rigorously (typically annual), with a detailed process spanning many weeks and taking lots of time.  When they are through the effort, everyone breaths a big sigh of relief, and gets back to work – and to executing against the original strategy!

Those in camp 1 above often engage strategy consulting firms.  Nothing inherently wrong in that, except that it can be a high cost route that ends in a good strategy that either:

• Does not fit the firm’s capabilities particularly well, or…
• Does not get sufficient engagement with those in the firm who must understand, buy into and execute against the new strategy.

Those in camp 2 above usually have a full time strategy organization – a small, but expensive group of bright folk who need to justify their existence.  Nothing inherently wrong in that, either, except that:

• The results are often less than inspiring.  They do a good job going through the motions, but the thinking isn’t really very strategic, nor the goals very ambitious.
• The results typically do not get sufficient engagement with those in the firm who must understand, buy into and execute against the new strategy.

Strategy Formulation as a Continuous Process

I believe much better results can be achieved if strategy formulation becomes:

1. A continuous process.
2. A firmwide capability – a strength, even!
3. A collaborative process.

We are living in unprecedented times.  Uncertainty and change are everywhere.  Market conditions can change overnight.  The globally interconnectedness of everything creates a complex environment that behaves in unpredictable ways.

New Possibilities Enable Continuous Strategy

At the same time complexity has increased and predictability decreased, information technologies create new possibilities for a very different approach to strategy formulation:

• From an event to a continuous process enabled by the Internet
• From a “canned” exercise for the select few to a “social” exercise for the many – employees, customers, suppliers, partners
• From lengthy “big bets” with high uncertainty to rapid “business experiments” with low risk
• From a dearth of data to help evaluate strategic options to a plethora of powerful business analytics, predictive modeling and simulation tools to help bring strategy formulation and execution together into a rapid learning model

Some of today’s fastest growing companies have figured this out and are quietly, but aggressively honing their continuous strategic capabilities.  Meanwhile, the large majority of companies are stuck in the old paradigm – afraid to open up the strategy process – just when the need for a shot of innovation and fresh thinking are matters of survival!

What do you think?  Are you in a company that is successfully moving to a more continuous approach to strategy?  Should your company be doing more to make strategy continuous?  How can you help achieve this?

Related articles

• Why do well-formulated strategies fail so often? (normanmarks.wordpress.com)
• Top Ten Management on Strategy-focused Organizations: An Overview of How a Focus on Strategy Can Lead to Corporate Success (bizcovering.com)
• Accepting and Embracing Uncertainty (collings.co.za)