Monthly Archives: January 2011

‘Social’ IT Management – Part 3


In Part 1 of this series on ‘Social’ IT Management, we discussed the inherent complexity of the IT management function, and how a more ‘social’ and emergent approach can represent a better way to manage IT.  In Part 2, we talked about the types of things that would be in a ‘Social’ IT Management Platform and the advantages of such a platform for enabling this social approach.  In this 3rd post in the series, we will discuss some Principles my esteemed colleague, Roy Youngman and I have found helpful in moving to a Social approach to IT management.

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
Enhanced by Zemanta
About these ads

‘Social’ IT Management – Part 2


In Part 1 of this series on ‘Social’ IT Management, my esteemed colleague, Roy Youngman and I discussed the inherent complexity of the IT management function, and how a more ‘social’ and emergent approach can represent a better way to manage IT.  In Part 2, we will briefly discuss the types of things that could be in a ‘Social’ IT Management Platform and the advantages of a Wiki platform for enabling this social approach.  Please watch for the 3rd and final post in the series, where we will discuss some Principles we have found helpful in moving to a Social approach to IT management.

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

‘Social’ IT Management – Part 1


I want to use a multi-part post to discuss some ideas and report on recent experiences in bringing a ‘social’ approach to managing Information Technology.  First, some context.

The Rise of Enterprise 2.0…

The term Enterprise 2.0 first surfaced in 2006, attributed to Harvard Business School Professor Andrew McAfee.  Wikipedia defines Enterprise 2.0 as:

the use of “Web 2.0″ technologies within an organization to enable or streamline business processes while enhancing collaboration – connecting people through the use of social-media tools. Enterprise 2.0 aims to help employees, customers and suppliers collaborate, share, and organize information. Andrew McAfee describes Enterprise 2.0 as “the use of emergent social software platforms within companies, or between companies and their partners or customers”.

The term quickly took hold, spawning speeches and several major conferences dedicated to the subject.  Vendors of social networking tools and platforms proliferated and it seemed we were in for a revolution in the ways business was conducted and managed.

…And Fall of Enterprise 2.0?

Well, it makes a good headline, but I’m not sure “fall” is quite accurate.  However, Enterprise 2.0 has not exactly sustained its momentum, even though there have been some moderate success stories, and, in fact, “social” approaches are gradually creeping into business practices across a wide spectrum of industries.

From ‘Enterprise 2.0′ to ‘Social Business’

Recently, the term “Social” seems to be replacing Enterprise 2.0 as the term du jour to describe business enablement through social-media tools.  See, for example, Harold Jarche‘s excellent piece on Social Business on the Edge of the Chasm, or CIO Magazine’s How ‘Social’ is Taking Over Business.   To quote from the Jarche piece:

Social business is about a shift in how we do work, moving from hierarchies to networks. The highest value work today is the more complex stuff, or the type of work that cannot be automated or outsourced. It’s work that requires creativity and passion. Doing complex work in networks means that information, knowledge and power no longer flow up and down. They flow in all directions. As John Seely Brown said, you can only understand complex systems by marinating in them. This requires social learning. Complex work is not linear. Social business is giving up centralized control and harnessing the power of networks. It is as radical as was Taylor’s Principles of Scientific Management in 1911.”

The IT Organization – The Epitome of Complexity!

As a researcher, student and practitioner of IT organizational design for nearly 35 years, I’ve long recognized the complexity inherent in IT management.  For example:

  • We manage to three very different value propositions – some of what we do is managed according to Operational Excellence principles (e.g., IT operations); some is managed for Customer Intimacy (e.g., business relationships) and some for Product Leadership and Innovation (e.g., opportunity discovery).
  • We have to ensure that new technologies coexist with legacy systems and infrastructures against the relentless drive of Moore’s Law and Gilder’s Law.
  • The economics of sourcing is constantly shifting with the rise of India, China, Eastern Europe, South America and other loci of low cost software development.
  • We have to deal with the ‘consumerization of technology’ as devices such as smart phones and tablet computers cross over from the home/entertainment space to the business realm.
  • We have to deal with immature funding and demand management models that often encourage low-value activity or result in a complex legacy of poorly connected systems.

So, it has seemed to me that tools such as MediaWiki, SharePoint, et al should be excellent enablers of IT Management – recognizing the complex nature of this work, and shifting it towards a more networked and collaborative approach.

Early Experiments in Social IT Management

My valued colleague, Roy Youngman and I have long been frustrated with both the process and deliverables from many of our consulting engagements over the years (we started working together over 20 years ago at Ernst & Young!)  The problem with the process was that we would spend most of our time with the CIO and IT leadership team, some of our time with IT managers, and virtually no time with the people actually doing the work.  This always felt somewhat ‘upside down.’

  • First, we weren’t working with the people who had the detailed knowledge of how things really got done.
  • Second, any changes that had to be introduced as a result of our intervention had to cascade from the CIO and IT leadership team on down.  This was a slow process, often involved massive ‘transformation’ initiatives,  leading to mixed results – some spectacularly successful, others disappointing.  By the time the “troops” heard the messages, they were distorted and there was little to no sense of “what’s in it for me?”  So the typical response was, “Keep your head down – this too shall pass!”  And pass it did, reinforcing the belief that strategic change initiatives can be ignored!
  • Finally, the problem with the deliverables from all this strategy and organization design work was often PowerPoint slides, Visio diagrams and Microsoft Word and Excel documents – hardly the stuff that IT organizations should be managed by!

So Roy and I began doing our IT strategy and organization design engagements differently – typically using SharePoint to change the process from a top-down, hierarchical approach to one more collaborative and engaging, and change the deliverables to ones that ‘live and breathe’ and that are central to the way things are managed – wikis, threaded conversations, process models and so on.

So, What Have We Learned from the Experiments?

Tune into the next post in this series…

Image courtesy of Trident Consulting LLC

Related articles
Enhanced by Zemanta

When Words Just Don’t Cause Change


I was in a heated ‘discussion’ with a client recently.  We had completed an IT strategy refresh and one of the outstanding items was to review their IT Principles.  The IT leadership team had come up with some candidate new Principles, and I was being asked if I thought they were appropriate.

“What Will You Do With The IT Principles?”

I asked, “What will you do with these IT Principles?”  The silence I was met with was palpable.  My client was too polite to say it, but I knew that in the silence he was thinking,  “Vaughan – you complete idiot!  A Principle is a Principle!  Having a Principle is the whole kahuna!  It has nothing to do with ‘what you do with them!”

The Pleasant Reassurance of New Words

This weekend, I saw a post by Seth Godin with the title above.  I knew I was going to like it – I like all Seth’s posts, and I LOVED this title!  This is what I found:

It’s a lot easier for an organization to adopt new words than it is to actually change anything.  Real change is uncomfortable. If it’s not feeling that way, you’ve probably just adopted new words.”

Short, and very sweet!

Giving IT Principles “Teeth”

I’ve posted before on the power of Principles, and in particular on Principles as a Problem Solving Tool.   To recap, there are three keys to making IT Principles valuable:

  1. Pick a few (say between 3 and 9) ‘points of pain’ that you want to try to address.  By ‘points of pain’ I mean something that is a significant performance inhibitor – often, this will mean it keeps surfacing as a root cause of some important dysfunctionality.
  2. Come up with a simple, direct and unambiguous statement that FORCES A CHOICE that would resolve the pain point.
  3. (And this is THE MOST IMPORTANT KEY!) Identify what will have to change in order that behaviors will change to come into line with the Principle.

Let me provide an example.  You have constant tension and debate around how much of the IT budget gets sucked into maintenance.  You’ve had good success getting prioritization of major new initiatives based on business value, but it is ongoing maintenance of existing solutions that is nickel and diming you to death!  You drill into root causes, ask a lot of “why’s” and come up with the recognition that the planning for new initiatives never takes the full life cycle costs into account.

This meets key #1 above – it’s a real point of pain!  You come up with a new IT Principle as follows:

We manage all business solutions and technology investments based upon total value of ownership – including total life cycle costs.”

This meets key #2 above.  But this is where I feared that my client was going to stop.  And this is where Seth’s words of wisdom about words were so salient.  It was going to feel good to the client’s IT leadership team to draft the words in the Principles – to debate over the language.  I imagine that once they’d been agreed upon, they’d be printed on posters or perhaps handy wallet inserts.  And that somehow these words would change things.  They won’t.  We need to address key #3 – what will have to change for us to act in accordance with this principle?

What Has to Change?

As an example:

  • The total cost of ownership of an IT asset and its value-contribution must be periodically calculated and tracked over time.
  • Requires closer alignment between program planning, project estimating,  budgeting and benefits tracking processes.
  • The cost of a new system should include the cost to retire the system it replaces.
  • Application retirement must be an active process.
  • The total cost of ownership must include both the business and technology costs of developing, deploying, and operating business solutions.
  • Costs such as hardware, software, maintenance, security, monitoring, training and on-going support must be included in the total cost of ownership.

These changes will have implications for business-IT governance processes, structures and reporting.  There may need to be new Policies.  There may need to be changes to rewards and recognition.  There may need to be changes to IT audit procedures.  And so on.

Remember, as powerful as words can be, they usually need the strength of structural, process, governance, rewards and recognition change to bring them to reality.  What say you about this?

 

Image courtesy of Drop Ship Access

Related articles
Enhanced by Zemanta

Threats and Opportunities in the Cloud – Coming to a City Near You!


I’ve posted before about Cloud Computing and I am delighted to let you know that I have been invited to speak to this topic at an upcoming CIO Forum Series sponsored by Pariveda Solutions and Microsoft Windows Azure.

I believe that there is an inevitability to the Cloud as a new way to deliver capability and functionality and that the implications are far reaching for IT organizations.  One implication that I am already seeing play out is the disintermediation of the IT organization as businesses look to short cuts and workarounds to get their pet initiatives deployed.  This is not inherently bad, but it is a slippery slope.  Businesses will unwittingly take on risks they don’t understand and ultimately, it will be the responsibility of the CIO to sort out the mess!

Cloud Computing and Business-IT Maturity

I’ve also posted extensively on the Business-IT Maturity Model and for this CIO Forum Series I will be examining the threats and opportunities for Cloud Computing at each level.

The event will be held in 4 US cities as follows (please click on the link for the city you are interested in signing up for to be taken to the appropriate registration page):

Here’s a quick introduction to the events:

Agenda

The agenda for each session will follow the same format:

  • 6:00 – 6:30 Drinks
  • 6:30 – 7:30 Dinner
  • 7:30 – 9:00 Introduction – Threats and Opportunities in the Cloud
  • Business demand and IT supply maturity:
    • Challenges and Opportunities at Level 1: Infrastructure and Core Solutions
    • Challenges and Opportunities at Level 2: Business Process Enablement
    • Challenges and Opportunities at Level 3: Product, Process and Business Model Innovation
  • Understanding the Cloud Provider Landscape
  • Real-World Cloud Cases
    • Level 1 Case: Scaling through Infrastructure On Demand Outsourcing
    • Level 2 Case: Extending reach and enhancing customer experience
    • Level 3 Case: Innovating products and business models
  • Building your Cloud Agenda
  • Panel Discussion
Enhanced by ZemantaPlease join me and my co-presenter, Brian Orrell for what promises to be an informative and enjoyable evening!

Customer Experience, Taming the Remote Control Madness – And a Tale of Advances in End User Programming


I rarely get so excited about technology that I post about it – that’s not this blog’s raison d’être.  However, between being snowed in (a rare occurrence in Atlanta, GA!), being really delighted with a great product that really solves a familiar and widespread problem, and enjoying a very positive series of customer experiences with the product’s vendor, I thought I’d break ranks, as it were, and talk about a product – and how it manifests the evolution of end user programming and what used to be called “user friendliness.”

The Challenge of ‘Best of Breed‘

I think everyone in IT has at some point wrestled with the choice between ‘integrated’ solutions and ‘best in breed’.  The analogy of home entertainment plays out well to illustrate the pros and cons.  I won’t go into this well worn territory – suffice it to say that most of us end up with best of breed, and pay the price of a coffee table full of remote controls and the minor maintenance headaches they bring with them (how many different kinds of batteries can remote control manufacturers find to make our lives miserable?)

An Early Solution

In 2006, my wife and I with our ‘empty nest’ decided it was time to downsize our living situation and move into a town house in a community with shared common areas such as gym, swimming pool, tennis courts, and so on.  To be frank, I was not thrilled with the downsizing plan, but managed to blackmail myself with the idea that we’d get the basement of said town house finished and turned into a home theater and a nice home office (where I spend much of my time).  Strangely, the basement in our town house is where the second story of most homes would be (don’t ask!) so the office has windows with great views into the woods.

With money saved by the down sizing, I went for a pretty high end (for the day) home theater, with best of breed components.  Given the state of the technology in 2006 (HDMI was not very prevalent then), I opted to have a local company source the technology and install it for me.  I also opted for a single remote – the Philips Pronto – a jokingly called ‘programmable’ device.  I remember watching the installation team set up my system.  It took the best part of the day, and for most of that time, one of the install team sat on the floor with a laptop and the Pronto unit, programming and testing to accommodate my flat screen TV, surround sound, Tivo, DVD, etc.  Eventually, they got it all working and – voilà – a single remote controlled everything.  Sort of.  It never did work quite right, but was close enough for my wife and I to live with it.

Along Come the Upgrades…

Live with it, that was, until I needed to upgrade technology.  Add a Blue Ray player, for example, and that’s the end of single remote simplicity!  So, I decided to master programming of the Pronto device.  I was trained in IBM Assembler and Cobol early in my career, but never thought of myself as a programmer.  And programming the Pronto reinforced my “non-programmer” self-perception and my lack of  patience for the arcane or obscure.  I quickly gave up!  It was just too complex and time-consuming.  So I put up with 2 remotes – the Pronto plus Blue Ray player.  Then 3 remotes – the Pronto plus Blue Ray plus Roku.  By Christmas, we had decided to upgrade our flat panel TV with the latest 1080p Plasma.  Goodbye Pronto, hello 6 remotes!

Then Relief!

A little web research convinced me that the Logitech Harmony One was worth a try.  An Amazon ‘one-click’ and 48 hours later, and I was opening the box to my putative problem solver!  What a delight!  Everything from the easy-open, “green” packaging, to the instructions, to the slick look and feel of the device oozed ‘design thinking.’

Programming the device through a web interface (they must have a library of thousand of remotes and their code strings) was as simple as could be.  Once programmed, you have a touch screen device – select the activity you want (watch TV, watch Roku, listen to a CD, watch a DVD, etc.) and the right components are switched on in the right sequence and set to the right inputs and outputs.  If you need to, select the device you want, and the Harmony One remote behaves exactly like that device.  No more batteries – the Harmony One sits in a nice little charging cradle.

And a Reinforcing Customer Experience

Capping my delight, today I got an email from Glenn Rogers, Logitech‘s Director, Customer Experience, inviting me to provide feedback on “How are we doing?”  This was the most thorough and well-designed customer survey I have ever taken!  I’ve found some customer surveys actually frustrate me and lower my opinion of the company seeking input.  This was just the opposite.  They wanted to know about every aspect of how I researched, how I purchased, how I experience opening the package, installing the software, setting up the device, and so on.  I felt like they really cared about me as a customer and what they could do to improve my customer experience.

Not Perfect, But…

I don’t want to pretend that the Logitech Harmony One remote is perfect – there are some minor nits (fed back to them via their survey), but they really are minor.  This is a slick device in every respect and is a great example of how to make ‘programming’ not just user friendly, but actually user seductive!  Congratulations, Logitech!  Want to buy a bunch of old remotes, anyone?

Enhanced by Zemanta

Three Ways To Increase IT Organizational Agility


Back in a September 2010 post, I asked, “How Agile Is Your IT Organization?  How Would You Know?“  The question came about as part of a research project I’m involved in through my affiliation with Formicio.  The aim of the research is to identify the factors that make IT organizations agile and recommend how agility can be developed as a core capability.  (Phase 1 of this research is still open – please feel free to participate by completing a survey here – it should take about 30 minutes, is free, and I believe you will find the questions stimulating!)

What Does ‘Agility’ Mean to an IT Organization?

Wikipedia defines agility as:

The ability to change the body’s position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, endurance and stamina.  In business, agility means the capability of rapidly and efficiently adapting to changes.”

From the perspective of the research project, we defined IT agility as:

The ability to rapidly and easily incorporate new technologies and methods into the way the IT organization operates, thereby having the capability to effectively sense and respond to changing business conditions in a timely manner.”

Why Does Agility Matter to an IT Organization

Simply stated, most business executives I speak to feel that their IT organizations lack agility! To paraphrase the typical response:

Things take too long to get to the point where they are delivering business results, and the IT organization typically seems to be behind the curve on emerging technologies!”

You may disagree with this statement, but I think most of you will agree that it is the common perception of your business executives.  In a world that seeks instant gratification, that is a value that is not typically embraced by IT organizations – and perhaps it should not be?  In a world where the business and competitive context can change almost overnight, increasing IT organizational agility should become an active goal.

So, What Have We Found?

The data is still coming in, and the numbers being crunched, but a couple of early observations:

  1. Your perspectives on Enablers and Barriers to agility depend upon where you sit.  In a federated IT Operating Model (some centralized, some decentralized), those that sit in the central camp tend to see shared IT capabilities as enablers of agility, whereas those in the decentralized units tend to see shared capabilities as inhibitors to agility, and seek more freedom from the ‘mothership’ in order to increase agility.
  2. Even with the definition of IT organizational agility provided as part of the research, its meaning is very squidgy and Rorschach-like – you read into “IT organizational agility” what you want to see.
  3. Fans of Agile Development equate IT organizational agility to Agile Development – they are essentially one and the same to them.  On the other hand, when you drill into what teams are doing with Agile Development, what you find is all over the map.  To some teams, it is a license to take short cuts, no matter what the consequences!
  4. Governance is desperately misunderstood!  This will be a subject of a separate post (or two!), but what I am seeing as I pour over the research findings indicates some governance perceptions that are way off base.  Again, it depends where you sit, but while some see governance as an agility enabler, others (in the same organization!) see it as a major barrier!
  5. The very different perspectives on what is meant by IT organizational agility and why it is important is quite troubling – if you can’t agree on what it means and why you want it, you are unlikely to increase your IT organizational agility!

Three Ways To Increase IT Organizational Agility

So, given those findings, here are three relatively ‘quick wins’ that will at least get your leadership talking in the same direction (excuse the mixed metaphor!)

1. Get clarity on what IT organizational agility means to you.

Don’t get wrapped up in academic definitions – focus on what it means to your organization.

  • What are your business drivers for IT organizational agility?  If you were more agile, what good things would you be capable of that you aren’t today?
  • Complete the tool in our research survey and use the 6 Domains of IT Agility to drive discussion internally on your enablers and barriers to agility.
  • Get to a consensus on the factors that need to be worked on for increased agility.
  • What do you see as the connections between agility and collaboration?
  • What do you see as the connections between agility and knowledge management?
  • What do you see as the connections between agility and Enterprise Architecture?

2. Identify where Agile Development fits in and how you will exploit that without increasing project risk.

Get clarity on Agile Development – what it is, and what it is not!

  • How do you define Agile Development for your organization?
  • When, where and how should you use Agile Development?
  • How will you define and monitor success?
  • What ‘unintended consequences’ will you look for and how will you mitigate against them?
  • What else is needed to increase IT organizational agility above and beyond Agile Development as you’ve define it?

3. Get to a shared understanding of IT Governance.

Get clarity on how you define IT Governance.  Again, don’t get wrapped up in academic definitions – define what it means to your organization.

  • What are the various aspects of organizational governance in your organization? (Don’t be limited by “formal” structures – consider aspects such as empowerment, decision rights, accountabilities, processes, culture of compliance, consequences for compliance or lack thereof.)
  • What is it about your IT governance that enables agility?
  • What is it about your IT governance that inhibits agility?
Enhanced by Zemanta

Changing – or Being Changed? An Important Distinction!


Elliot Ross and his always insightful blog about Strategic Technology for the Small to Medium Enterprise just posted on “ITIL, Value and Culture.” I like Elliot’s blog because of his “small to medium enterprise” perspective – I find it an interesting balance against the large companies I typically work with.

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

Enhanced by Zemanta

A Review of this Blog in 2010


I continue to be highly satisfied with the WordPress blogging platform!  The art of creating a superlative customer experience includes providing things that were not expected, and the bulk of this post summarizing how my blog did, appeared in my in-box courtesy of WordPress – I call that a great customer experience!  Here is what they found:

All In All – It Was a Very Good Year!

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

About 3 million people visit the Taj Mahal every year. This blog was viewed about 50,000 times in 2010. If it were the Taj Mahal, it would take about 6 days for that many people to see it.

 

In 2010, there were 44 new posts, growing the total archive of this blog to 284 posts. There were 90 pictures uploaded, taking up a total of 42mb. That’s about 2 pictures per week.

The busiest day of the year was October 12th with 287 views. The most popular post that day was Project vs. Program vs. Portfolio Management.  (VM note:  This is the most popular post every day!  Which is a shame, as there are other, more useful posts in my blog about Project, Program and Portfolio Management for those interested in these topics!)

Where did they come from?

The top referring sites in 2010 were linkedin.com, google.com, facebook.com, en.wordpress.com, and twitter.com.

Some visitors came searching, mostly for maturity model, mind mapping, discipline, cio vs cto, and leadership.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

Project vs. Program vs. Portfolio Management October 2007
12 comments

2

Exploring an IT Operating Model for Enterprise 2.0 – Part 2 February 2010
5 comments

3

CIO vs. CTO – What’s The Difference? December 2007

4

Mind Mapping as Collaborative Ideation and Problem Solving July 2008
3 comments

5

Business-IT Maturity – a helpful lens for the future? September 2007
3 comments

Enhanced by Zemanta

The Accidental Project Manager


Some IT organizations invest a great deal in the processes and disciplines of Project Management.  As well they should – much of an IT Organization’s work is performed through projects.

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!”)
Enhanced by Zemanta