Category Archives: Next Generation Enterprise

Digital Business and the Fate of the IT Organization


Social-MediaInformationWeek just published an excellent article titled “Goodbye IT, Hello Digital Business.” The article presents a compelling case for “Digital Business” as a lens into what the more information and IT-savvy companies are doing. It presents some good case studies from Digital Business leaders in the retail industry. It also presents some interesting statistics on emerging platforms for building customer ties, on the main opportunities for today’s CIOs and how IT teams are interacting directly with customers.

Are IT Organizations Asleep at the Digital Switch?

I found the statistics InformationWeek presented as both believable based on my consulting experience, and disturbing! The numbers reinforce the facts that:

  • The majority of IT organizational focus and energy continues to be consumed by legacy solutions, keeping the metaphorical “lights on and trains running on time.”
  • The IT organization typically does not play a major role in business innovation.
  • The IT organization is slow to enter the world of mobile computing.
  • Many IT staff don’t have the customer-facing skills and business knowledge to play in the emerging Digital Business space.

The statistics indicate a move in the right direction – no surprise there.  But the shift is slow – rewarding the early movers with the advantage of a differentiated experience for their customers and for their employees – especially for those IT staff that are involved in these frontier applications. The early movers, through business experimentation and studying success stories are building their digital capabilities.

Accelerating the Shift

Exploiting Digital Business is not just about innovation, agile channels, mobile computing and social media – it has profound implications for the IT organization and its context – the IT Operating Model. I’ve posted before about how IT Operating Models must change for what I called Enterprise 2.0 – aka, Digital Business.  (See here and here.)

Some companies are accelerating the shift through IT Transformation programs – reorganizing, rethinking IT processes and value streams, re-skilling the IT organization and, in some cases, radical outsourcing initiatives. Other are using ‘skunkworks’ approaches to learn and build credibility through early business experiments. Some have the most progressive and promising Digital Business initiatives happening in the shadows – outside the purview of their IT organizations. I find that to be a dreadful indictment of the IT leadership! If that is not a wake-up call for a new CIO, I don’t know what is!

Digital Business is Literally Business-IT Convergence

I’ve posted before on the concept of Business-IT Convergence. In many respects, Digital Business is all about the convergence of IT with the business – business products and services become digital, and IT capabilities – historically located in an IT organization – converge with business capabilities. Some IT professionals and leaders will see this as very threatening. Others will see it as the solution to many perennial problems associated with the ‘us’ versus ‘them’ of the business-IT relationship.

What do you think? How is Digital Business impacting your work life?

Image source courtesy of Devicix

Related articles
Enhanced by Zemanta
About these ads

Driving Business-IT Convergence – The Evolving Role of the Business Relationship Manager (Part 2 of 2)


cloudIn Part 1 of this 2-part series I defined the BRM role – with the caveat that it is by no means standardized.  In fact, as far as IT Service Management standards such as ITIL® and ISO/IEC 20000 are formalizing the existence of the Business Relationship Manager (BRM) role and corresponding process as a new best practice, they are selling the role short in terms of its potential strategic impact to business.  I went on to describe the typical BRM in terms of their purposes, goals, responsibilities and accountabilities.  To the title of this post, I introduced the shift from business-IT Alignment to Convergence and why this is so important as every aspect of business strategy and operations is increasingly dependent upon information and IT.   Today, the BRM operates at the leading edge of the convergence movement – a movement being accelerated by the ‘consumerization of IT‘, digitization of everything, and by the “Internet of Things.”

In part 2 of this 2-part series, I’d like to discuss needed BRM competencies, how the BRM role changes over time with increasing maturity (of both the BRM and her business partner) and how the way that the BRM engages with the business partner shifts the nature of the relationship from one of order taker to that of strategic partner.

Typical Competencies Required of the BRM

Drives Value Realization

This might be the most important competency for a BRM.  It includes knowing how to surface, clarify and promote the best value-delivering opportunities for IT investments and assets, and how to ensure that these actually deliver on their promised value – delivered in ways that are felt and seen.  This requires skills in Program Management (with implied Project Management skills), Portfolio Management, influence, persuasion, communication, finance and organizational change.

Understands Business Environment

Driving value realization also requires a great understanding of the business, its ecosystem and its competitive landscape.  Successful BRMs have a keen sense of the top strategic business and IT issues – both short and long term, and how these issues relate to initiatives in their industry.  In short, they understand the “business of the business.”  They are viewed by business leaders as a proactive partner in finding the right solutions to business needs and not as a mere “order takers” for IT services.

Aligns IT with the Business

First, let me say that some readers will fume at the subheading.  “IT and the Business are one and the same!” they shout.  While this may reflect a laudable perspective (and one that will gradually materialize as IT-business convergence takes place) it is rarely, if ever, the case today.  Unless your business is information technology, then “business” is where profits are generated, and IT organizations work in support of that.

With that digression out of the way, alignment can be a tricky concept, and in some respects sounds inconsistent with my argument for business-IT convergence.  But alignment represents the necessary table stakes – business leaders and IT leaders need to be ‘on the same page’ in terms of mission, vision, values and goals for both IT and the business – and how these relate to each other.  Mismatches in any of these can spell disaster to the ability to build and sustain value-producing business-IT relationships, let alone converge business and IT capabilities.

Successful BRMs work closely with business leaders to predict demand for IT services and to manage that demand.  They take the lead in highlighting competing objectives.  They are effective at managing the flow of demand through negotiations and seek to iron out demand/supply disconnects between IT and business leaders.  Most important, they constantly seek ways to foster convergence – empowering business leaders – teaching them to fish, as it were, rather than always fish for them!

Manages Relationships

Any role with the word “relationship” in the title has to imply a high level of competence at creating, sustaining and developing strong relationships among stakeholders – especially between business units and the IT groups that support them.  Relationship skills do not come naturally, and are not easily developed in some people.  Effective BRMs are able to build and maintain relationships with senior IT and business leaders.  They are seen as a value-added participant in strategic business-level discussions (i.e., worthy of a “seat at the table”).  Successful BRMs are not shy in speaking up when the demand for IT services outpaces supply ability or capacity.

Manages Organizational Change

Another tough set of skills and behaviors to master!  This requires deep understanding of the organizational levers for making change (people, process, and technology) and how IT and business strategies translate into practical plans of action for change.

The successful facilitator of change engages in discussion with IT and business leaders on the intended and unintended consequences of change, and is willing to confront senior executive sponsors if they are not “walking the talk” and proactively leading the change themselves.  They understand the total cost – both technical and human – of end-to-end implementation.  They can surface the hidden costs and potential obstacles that could derail the change.

They have the ability to identify key stakeholders at the outset of a project, to assign decision-making roles, and ultimately hold leaders accountable for results.  They think and act in terms of outcomes, not deliverables.

Manages Projects and Programs

Successful BRMs typically have several years of project and, ideally, program management experience under their belts.  They have demonstrated competency in project management fundamentals and in the complexities of program management. They demonstrate the ability to get things done through others, even though they may lack ultimate authority.

Effective Communication

Successful BRMs are recognized for their ability to listen, speak, write and communicate clearly and effectively. They demonstrate the ability to negotiate win-win, or at least buy-in, in situations where there are opposing viewpoints.  They are effective at influencing those that they hold no real power over.  They have the ability to recognize and surface disconnects between IT and business leaders and are able to resolve problems through difficult confrontations.

Financial Savvy

Successful BRMs have good knowledge of finance and accounting – they know their ROIs from their NPVs and know how to build a business case that is compelling.  They understand Portfolio Management and have at least basic knowledge of Options theory.  They understand the financial drivers of the business and the drivers of the industry within which the company operates.

The BRM Maturity Journey

BRM Maturity - The Merlyn Group

The graphic above shows how the quality of the Business Partner experience grows and the BRMs maturity increases.

Ad Hoc Relationship

At the lowest maturity level, the BRM role has typically not been formalized.  As such it is being handled in an ad hoc way – the ‘squeaky wheel’ Business Partner gets the most attention.  Or, in some cases, the least demanding Business Partner, regardless of their potential to use IT for high value purposes get the most attention.

Order Taker Relationship

I see this most frequently. Typically, IT supply has been badly broken and the business-IT relationship is hostile, so the BRM role is introduced to “patch things up!”  The BRM, in her ignorance, believes the best way to improve the relationship is to say “yes” to any and all business demands.  This is nearly always a losing proposition.  IT can’t meet the demand, and if they did, there’s little to no business value to be gained.

Advisor

This is a more constructive and productive relationship, where the Business Partner sees the BRM as an advisor.  By this time, there has usually been some formalization of the BRM role and its rules of engagement.  There’s also been some level of training for the BRM – or at least some thought put into the selection of people for the role.

Strategic Partner

The ‘Holy Grail’ of BRM implementations.  This should be the clear ambition – one that is understood and shared by the BRM and her Business Partner – with the recognition that you aren’t a Strategic Partner because you say you are, or because you want to be.  You reach that elevated position because you’ve earned it – and because your Business Partner sees you that way.

IT Matures as the BRM Role Matures

At the risk of pointing out the obvious, the BRM role does not act in isolation.  It is inextricably linked to IT supply.  If IT supply is broken, the BRM role will be limited, and might not even make it to Order Taker.  This, from my experience, is a common situation.  Things are bad, so the BRM role is introduced.  Unless supply improves, the BRM is doomed to failure – and may actually make things worse.  Promises are made and expectations set that cannot be kept.  On top of lousy supply, the BRM is seen by the business partner as ‘overhead’ – yet more evidence that the IT team is clueless, always adding cost without demonstrating value!

To reach the Holy Grail of Strategic Partner, IT supply has to be excellent – both with steady state services (networks, email, help desk, etc.) and with solution delivery (projects and programs).  The “strategic” BRM needs IT supply to work flawlessly.  IT supply needs the BRM to suppress low value demand while stimulating demand that delivers real business value.  That way, everyone is happy and a virtuous cycle is sustained.

Image courtesy of TradeArabia

Related articles
Enhanced by Zemanta

Resolving the CIO Paradox


Last week I posted a review of the excellent book, “The CIO Paradox: Battling the Contradictions of IT Leadership” by Martha Heller.  Martha examines the CIO role, stakeholders, staff and future, and provides a rich trove of practices shared by leading CIO’s.

Reading the book and writing the review got me thinking about the current state of IT leadership, and where this is going in the next few years.  After all, this blog, started back in 2007, is titled “IT Organization Circa 2017″ and was originally intended to explore just that topic!

The CIO Role is Essentially “Unnatural”!

I first became aware of this fact back in 1980, when reading Alvin Toffler‘s remarkably prophetic book, The Third Wave.  (I had the privilege of having dinner with Mr. Toffler early in the 1980′s and talking with him at depth about the coming implications for IT leadership, further reinforcing my beliefs around this).  In the book, Toffler argues that Second Wave economies (Industrial Revolution, late 17th century through the mid-20th century) were largely driven by an unnatural breach between “consuming” and “producing.”  He pointed out that in the first wave economies (Agrarian Revolution) most of us produced for ourselves what we needed to consume.  The Industrial Revolution tore production and consumption apart – we worked in offices and factories to earn the money to buy the goods and services that came out of the offices and factories.  Toffler further argued that in the third wave, technologies would “heal” the breach, creating what he called “prosumers.”

The very notion of the IT professional, grouped into IT organizations, managed by CIOs in order to help consumers of IT is inherently very “second wave.”  In fact, over the last 60 years or so, we have seen more and more examples of IT “Prosumerism.”  The first spreadsheets (Visicalc, et al) allowed someone with virtually no IT training to create financial models that a few years earlier could only be produced by teams of expert programmers.  Desktop publishing allowed anyone to get into the publishing business.  YouTube, et al allows anyone to create and publish their own videos, and today high quality movies are produced by amateurs on relatively low cost consumer equipment.

The forces behind this IT prosumer revolution are not going away – rather they are leading to an exponential growth of the IT prosumer – a trend which some people refer to as the “consumerization of IT.”

CIO as Enabler or Barrier?

So, what’s a poor, embattled CIO to do?  On the one hand, the CIO has an obligation to protect a company’s assets against the continuous and growing threats from hackers, viruses, criminals and bad technologies.  On the other hand, the CIO and her IT organization must constantly, even aggressively be preparing for and pushing people towards IT “prosumption.”

As an IT leader, how much of your time and actions are devoted to protecting those who use IT from it’s perils, versus creating the infrastructure and an educated business community that can safely exploit information and IT for competitive advantage?

Related articles
Enhanced by Zemanta

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


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

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

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

The CIO Paradox

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

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

She almost always got the same response:

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

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

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

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

Your Role

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

Your Stakeholders

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

Your Organization

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

Your Industry

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

Leading and Interesting Practices

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

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

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

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

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

Two “Killer Practices”

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

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

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

Enhanced by Zemanta

Does Cloud+Consumerization Doom the Federated IT Operating Model?


The Federated IT Operating Model is Under Threat!

Today, most organizations employ some sort of Federated IT Operating Model.  Wikipedia defines a federation as:

…characterized by a union of partially self-governing states or regions united by a central (federal) government. In a federation, the self-governing status of the component states, as well as the division of power between them and the central government, are typically constitutionally entrenched and may not be altered by a unilateral decision of the latter.”

Typically, enterprise-wide or common applications, initiatives and infrastructure are a centralized (federal) responsibility, while local applications and activities are under the control of business units or functions.  This “federal rights/states rights” model has infinite variations.  Definitions of “common,” “enterprise-wide” or “infrastructure” are subject to interpretation, and these tend to change over time, with changing business conditions, leadership, technology and other forces.  There’s also inevitably a “shadow IT” phenomenon – sometimes quite large – where much IT activity happens outside the realm of IT governance.

Just as in countries with a federal governance model, the competing forces between state and federal rights pull and push over time, leading to an ebb and flow of centralization and decentralization.  This can be healthy – like an accordion, making sweet music as the parts are squeezed together or pulled apart.  It’s never static, but constantly responding to the forces of change – just as all living systems “breathe” in some way or another, and have their seasonal variations.

But every now and again, new forces surface and combine together to disrupt the gentle ebb and flow – the so-called Arab Spring comes to mind.

The New Forces of Change

IT governance is undergoing such a confluence of new forces.  These include:

  • Cloud computing – it is easier, faster and cheaper (on the face of it) to leverage the cloud to host applications and provide IT services (e.g., storage, transaction processing, data analytics) rather than have your federal IT group provide these services.  Much of this activity takes place in the “Shadow IT” realm.
  • Mobile computing – more of us are doing more via smart phones and tablets.  This exposes us to mobile applications and the many “app stores” including Apple’s and Google.  Getting an app is as simple as clicking a button – and many apps are free, or cheap enough to add to your mobile phone bill without feeling any pain.
  • The shift in the personal computing operating system – from Windows, et al, which can be controlled by the central (federal) IT department, to technologies such as Apple’s iOS and Google’s Android which are much harder (perhaps impossible?) to control centrally.  The genie is already out of the bottle, and it’s not going back any time soon!
  • Economic climate – the economic climate facing most businesses, whether in the US or just about anywhere else is in the doldrums.  This keeps people scrutinizing costs, prepared to make short term economic moves, even if at the expense of the longer term, and trying just about anything to get “unstuck”!  Such a climate tends not to favor centralization and federal power (just ask President Obama’s campaign advisers!) but empowers local forces and factions.

Beware the Unintended Consequences

So, what to do about it?  Here’s three options:

  1. Take a laissez-faire approach – a path of least resistance.
  2. Push back, hunker down and reinforce the federal model with more controls and stronger sanctions for “shadow” behavior.
  3. Adopt a “mutual adjustment” approach that navigates the stormy waters to constantly find the optimal balance.

From my perspective and experience, Option 1 has potential (likely?) unintended consequences.  We saw this when many central IT groups were slow to respond to the emergence of the Personal Computer.  When they did respond, it was generally via Option 2 – they tried to constrain them.  That drove a lot of rogue and shadow behavior and set many companies IT efforts back several years.

For most of us, Option 3 is the practical and pragmatic solution.  Let’s face it, there are all sorts of unknowns in terms of how these forces will play out over time.  We need some form of centralized coordination of infrastructure. However, the terms “coordination” and “infrastructure” must be defined clearly and re-defined from time to time as we gain experience with cloud computing and consumerization of IT.  There is not a right and wrong here – but a critical need for organizational clarity so that you are setting the bounds of infrastructure clearly and in a way that is appropriate to the times and to your business context.

Seven Steps to a Mutually Adjusting IT Operating Model

I believe IT leaders must approach this in the same way they would approach any needed change:

  1. Create and “market” a compelling end state vision.
  2. Surface and “sell” the cost of status quo or of going down the wrong path.
  3. Define a credible and palatable path to the future.
  4. Enroll key stakeholders in joining together on that path.
  5. Engage selected key stakeholders in the governance model.
  6. Surface and celebrate successes along the way.
  7. Take action to discourage deviations from the path.

Image courtesy of Charles Ayoub

Related articles
Enhanced by Zemanta

The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 3


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
Enhanced by Zemanta

The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 2


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.

Enhanced by Zemanta

Changing the Culture of an IT Organization – One Wiki Page at a Time!


I’ve been a student of IT organizational culture since I began my management consulting career some 30+ years ago.  It’s wrong, of course, to generalize too broadly, but I’ve worked with literally hundreds of large enterprise IT organizations (i.e., IT organizations of 250+ members) and have seen more commonalities than differences.  Of course, within any IT organization, there are sub-cultures – architects are not the same as operations people or as solution developers – but again, there are more common threads than sharp differences.

Prevent Bad Change…

For all the change that IT organizations bring about for their customers and clients, IT people are generally resistant to change.  I think this resistance is deeply rooted in a couple of factors:

  1. IT environments are full of technical complexity – layers upon layers of technology containing multitudes of interfaces and dependencies.  Change something over here and something over their is impacted – sometimes in subtle ways that may not be evident for some time, or until some other seemingly unrelated change is made.
  2. IT professionals thrive by taking complex situations and reducing them down – ultimately, to zeroes and ones.  There’s no room for ambiguity in a digital system – as such IT specialists are conditioned to abhor ambiguity.  And yet change is full of ambiguity – what ‘has been’ is no longer, and what ‘will be’ is not yet stabilized.  The natural inclination, then, is to drive out the ambiguity, and typically, the fastest, safest path to achieve that is to revert to the status quo – ending the change before damage is done (or the changed state it reached!)

Meet the Culture Where it is – Or Where You Want it to Go?

This inherent tendency to ‘prevent bad change’ creates some tough dilemma’s when introducing social networking and collaboration capabilities such as Wikis.  Wikis thrive best where a culture is open and emergent – “enabling good change,” if you will.  As you design the governance mechanisms for a Wiki, you have some interesting choices.  For example:

  • Do you allow people to create their own pages?  Or do you put controls on who creates and who edits pages?
  • Do you allow all spaces to be open to anyone in the organization?  Or do you allow for “private” spaces, where a select few (such as an IT leadership team) collaborate?
  • Do you allow people to display avatars that are humorous or ironic?  Or do you insist on “corporate photographs” from people’s security badges?
  • Do you allow people to write in their unique voices – even if a little rough around the edges?  Or do you have a Wiki Gardener monitor pages and clean up the rough edges?

To be clear, I’m not talking about allowing people to violate corporate codes of integrity – potentially offensive or inflammatory graphics or text is clearly out of bounds and violations of such codes of conduct should swiftly be managed as performance management issues.  I’m talking about an open and emergent Wiki environment – complete with the bumps and hiccups it may contain, versus a more closed and structured Wiki, protected from potential ‘voices of dissent’ or the raising of challenging or tough issues.

Governance Designed to Meet the Culture Where it is

You can take the position that Wiki governance should be designed for the current state:  “We are locked down, deeply concerned about security and privacy.  We have to have special ‘standards of conduct’ and controls to keep things structured and secure.”

Governance Designed to Help Shift the Culture

Or, do you take the position that the governance should be designed with an eye to the desired future state: “We encourage open dialog and a thriving ‘community of adults’ – keep within our corporate code of integrity and help make the Wiki a safe, valuable and fun place to grow and share our enterprise knowledge about IT.”

Given the people responsible for approving Wiki governance will probably not have significant experience with the more open model, their inclination will be to ‘play it safe’ and design for the current state.  Unfortunately, that is likely to perpetuate the current culture and probably prevent the Wiki from becoming what they want it to become.  It make take one or two strong, visionary leaders to take the leap of faith, and allow a governance model that reflects their aspirations for the culture.

Graphic courtesy of Positive Change

Enhanced by Zemanta

More Hurdles in the Shift from Documents to Wikis


Last week, I posted about The Painful But Rewarding Shift from Documents to Wikis.  In the post I shared some of the lessons my partner and I have learned from our experiences helping IT organizations shift to a Wiki approach for creating organizational clarity and getting people in the organization to engage in continuous improvement.  I will continue with this theme in this post.

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

Enhanced by Zemanta

The Painful But Rewarding Shift from Documents to Wikis


I posted recently on the question, Can Social Media Significantly Improve the Ways IT Work Is Performed?  The post began to share some of the lessons learned as I continue to work with IT organizations that are pushing into the “social media” age and using tools such as Wikis and Social Networking to drive IT performance improvement.

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

Enhanced by Zemanta