IT Management Lessons from Scuba Diving

I note in my About page that “from time to time I will digress to my hobby passions because I sometimes find interesting connections or insights from them.”  Well, perhaps its an excuse to indulge a hobby through this blog, but one of those “time’s” has come as I’m on a scuba vacation with plenty of scuba to enjoy, and many relaxing moments to reflect on the hobby, sport and business of scuba diving.

Sensible, Collaboratively-Developed Standards

Scuba diving is fairly well regulated on a global basis and maintains an excellent safety record for recreational divers.  The process entails multiple levels of certification, with each level requiring behaviors that demonstrate that the key skills have been learned.  While there are always rogue operators who will rent anyone a tank of compressed air, and clearly bozos who will use them and dive untrained and uncertified, most recreational divers will pick a licensed dive operator who will insist on seeing and take note of your diver certification before they will rent you an air tank or take you to a dive site.

There is a powerful collaboration between the retail dive shop operators, training operators, dive boat and the equipment manufacturers and with the independent scuba certification agencies.  These agencies provide all levels of diver training, regulate and represent diving professionals such as divemasters and dive instructors, regulate dive operators, participate in research in dive medicine, promote marine conservation, and market diving as a sport.  The largest global agencies are The Professional Association of Diving Instructors (PADI) and the National Association of Underwater Instructors (NAUI).

Lessons for IT Management

Now think about what this in the context of the IT profession:

• Scuba diving has global standards, including the required competencies for open water diving, advanced diving, rescue diving, dive instructor, and so on.  In order to be certified, you must go through standardized training and demonstrate you understand and have acquired the skills.  The IT profession does not (though there are respected certifications for domains such as project management.)
• A diver wishing to rent a tank of air, and/or get a guided dive,  has to show a valid dive certificate to prove they’ve reached a minimum level of competence and safety.  Furthermore, (though this is not enforced) they can ask to see the diver’s log book to see their diving record, including total number of dives, date of last dive, and the kinds of conditions they’ve dived in.  In the IT recruitment process, this is not the case.  We have to judge competence largely by a resume, which often have limited value.  Have you ever seen a resume that said the individual was incompetent at anything?
• Scuba diving has a globally standardized competency model, and associated competency development resources (training, on-line lessons, tutorials, etc.)  What are the global standards for roles such as “business analyst”?  Where are the standardized competency models and certification programs for different roles in the IT profession?  Yes, I know that some certifications do exist, but they are not globally regulated or standardized.  For example, I have  worked with hundreds of people with business analyst titles over the years, and their actual business analysis knowledge and competencies have varied widely.
• There is substantial science behind scuba diving.  In the early 1900’s, studies began to establish the relationship between dive depth and bottom time, and how to avoid the painful and potentially life-threatening decompression sickness (the bends). This research, refined by the US Navy, led to dive tables, one of the fundamental skills for Scuba certification.  IT geeks note, dive computers are available and reasonably inexpensive nowadays to monitor each dive on a continuous basis to figure out the state of dissolved nitrogen in your tissues – the source of the Bends.  The dive computer shows precisely how much time the diver can safely remain in the water, or how long they have to stay on the surface before the next dive.  This is more accurate and much easier than calculating the results using a dive table.  By contrast, tasks such as estimating a solutions delivery project, especially if software development is part of the solution, are typically more the result of rough rules of thumb or often guesswork than any real science!  Many IT projects get the equivalent of the bends, and some suffer life threatening consequences!
• But I think that the biggest insight is that all this regulatory activity, training, and recreational diving takes place on a global scale with minimal fuss and bother.  Why is this?  Divers a passionate about scuba diving!  How can you create jobs for people that foster in them the passion they feel about their favorite hobby or sport?

Is Your IT Organization an Enabler? Or a Preventer?

A really short post today (could have been a Tweet if I were so inclined!)  I got a great comment from a CIO client to my post yesterday on the ROI of Enterprise 2.0.  He said,

One of Dion Hincliffe’s lines definitely hits home for me… “In the end, all one can actually do predictably is enable the possibilities and not prevent them.”   We have said to each other that a lot of this is about making sure we’re seen as the Enabling Department, rather than the Prevention Department.

When Web 2.0 has significantly impacted your company (you either stole a march on your competitors, or they did on you!) will your business partners look back and say,

“IT really inspired us, showed us the way, and enabled us to take advantage of Web 2.0.”

Or, will they be saying (or, at least, thinking),

“Just like the Internet revolution and the Personal Computer revolution, IT was asleep at the switch yet again!  They didn’t see it coming ’till it was too late, and then they put roadblock after roadblock in our way!”

How are you creating a legacy of enablement and innovation?  What more could you be doing?

Don’t Look for ROI on Enterprise 2.0 – Look for Value!

Dion Hinchcliffe had a superb post on Determining the ROI of Enterprise 2.0.  The post cites several authoritative and useful sources on the subject.  It also hypothesizes several reasons for the mostly “wait and see” attitude currently taken by most IT leaders and business managers.

But I mainly want to focus on the business case for Enterprise 2.0 – specifically, the pursuit of Return on Investment – ROI.

The Problem with ROI

Much has been said in the past about the limitations and challenges with ROI as a tool to evaluate many types of IT investments.  Dion’s post links back to an old post, The Case Against the Business Case by the father of the term Enterprise 2.0, Andrew McAfee.  McAfee in turn references the work of Kaplan and Norton and their Strategy Mapping book which points out that the value of intangible assets (human, organizational, and information capital such as databases, information systems, networks, and technology infrastructure):

…derives from their ability to help the organization implement its strategy… Intangible assets such as knowledge and technology seldom have a direct impact on financial outcomes such as increased revenues, lowered costs, and higher profits. Improvements in intangible assets affect financial outcomes through chains of cause-and-effect relationships.”

This is a really important point, but it sets up a very slippery slope. “We can’t attribute any direct financial impact to our Enterprise 2.0 investments…  so we won’t try.”  It’s the “not trying” here that drives me nuts!  It leads to:

1. Lazy thinking… which leads to…
2. Lack of clarity about what outcomes we are trying to drive to with our Enterprise 2.0 initiative… which leads to…
3. Lack of rigor in thinking through what behaviors we are hoping will change in order to realize the targeted outcomes…  which leads to…
4. A “if we build it, they will come” approach to Enterprise 2.0…  which leads to…
5. Failure of the Enterprise 2.0 initiative, “proving” there is no business case!

Value from Enterprise 2.0 can be a Self-Fulfilling Prophecy

Last August I wrote a post titled Measuring the Business Value of IT – Where You Can Win By Simply Trying! My point here was that the discipline of thinking through what we’d like to achieve, and how we might achieve it, dramatically increases our probability of achieving it.  As a trivial case, imagine the following conversation:

Let’s invest $1 Million to increase collaboration across our company.”

“Why?”

“Because we’ll be more innovative and productive.”

“How?”

“Hmmm – good question!  Well, we’ll tap into people’s ideas about how to improve our products and services.  And even how to improve our processes.  We could even tap our customers’ ideas!”

“How will we do that?  What will we need to enable that?  What will we need to shift to those kinds of behaviors?  Are there any aspects of our culture that might inhibit those things happening?”

“Hmmm!  More good questions.  Perhaps we need a bit more definition around what we are trying to do?  Perhaps we need to drive to some clarity on the outcomes we hope to achieve?  Perhaps we need to assess our ability to achieve those outcomes and clarify what will need to change for them to materialize?”

And so on.  Note, we aren’t building a business case in the financial sense.  This is not an ROI exercise – its a business value and outcomes exercise.  And this is the type of analysis that needs to be done to shift from the laissez faire “if we build it” to a more thoughtful, targeted approach.

(Image courtesy of SponsorMap)

Best Buy and Web 2.0

I’ve posted quite a few times on Web 2.0 capabilities as a way to drive new energy, and even innovation, into an IT organization and the company it serves.

The Wikinomics blog (full disclosure – this is affiliated with nGenera Corporation, the company I am with) just posted a very nice piece on how Best Buy is using Web 2.0. The piece features a great little YouTube video – well worth the 4.33 minutes it takes to watch.  (Look for some quick clips of Don Tapscott, Chairman of the nGenera Innovation Network.)

Your IT Organization as a “Geek Squad”?

As you check this out, think about Best Buy’s “Geek Squad” – how could this use of Web 2.0 play out for your company, and how might you position your IT organization as your company’s “Geek Squad”?

Of course, a few years back, no self-respecting CIO would want to think of his or her organization as their “geek squad” but I think Best Buy has successfully legitimized the term.  Their Geek Squad (a Best Buy subsidiary and a registered trademark/protected brand) has been a valuable differentiator for Best Buy – by and large enhancing the shopping experience, adding value to the store’s capabilities, and helping consumers install and use many of the products that Best Buy sells.

Are your IT staff seen this way?  Are they a differentiator and a value add?  Do they enhance the value of IT’s products and services?

Your Web 2.0 Experience

How does the social networking experience in your company match up against the Best Buy experience?  How could you get closer to the benefits Best Buy is touting in this video clip?

Supposing You Funded IT Like a Charitable Donation?

I’ve had this IT funding fantasy for years (I know, it’s really sad that my more exciting fantasies are to do with IT funding scenarios!) Supposing the CIO had to do a fund drive every year or every six months the way our local National Public Radio stations had to operate in order to fund certain IT activities?

I actually hate the NPR fund drives, but I love what privately funded radio brings compared to all other forms of news and quality radio programming  in the USA, and I realize that the funding model is necessary and ultimately important to the NPR mission.

Listening to my local radio station’s NPR funding appeal for a couple of weeks twice a year always gets me thinking about IT funding and my “IT Charitable Donation Fantasy.”  I’m not suggesting this is the way to fund all IT activities – far from it.  I believe that funding, for good or bad, drives behavior, so if we want responsible business behavior around IT assets and activities, we need to think through the desired behaviors and how funding models promote or detract from those behaviors.

Three Distinct IT Funding Pools

It is useful to carve IT spending into 3 broad categories:

1. IT infrastructure.  This should be defined very broadly to include all shared IT capability.  To borrow from Prof. Peter Weill’s definition, IT infrastructure is the base foundation of IT capability budgeted for, centrally coordinated and shared across the enterprise.  I don’t see this being funded through a charity-like, voluntary basis.  Like all infrastructures, nobody really wants to fund it, and few understand the technology details, risk management, capacity planning and other implications that render IT infrastructure either reliable and supportive of the business mission on the one hand,  or unstable and get in the way of the business mission on the other.  I think IT infrastructure is best funded as a kind of tax – in a way that fairly represents the proportional value to the organization that uses it.  Depending upon the nature of the business, this might be a function of headcount, divisional revenue, or some other factor.  And, as an aside, the CIO should be looking to continuously improve the cost per unit of infrastructure over time.
2. Business Solutions.  These should essentially be funded by the business units that require them and will benefit  from them.  If more than one business unit, then the combination of business units will fund the solution in proportion to the degree of benefit or value each derives.  This will never be pure science and will typically involve some kind of negotiation between the parties.  By the way, this type of activity should have a robust value realization approach to go along with the funding.  (I’ve posted on value realization quite a bit in the past – if you are not familiar with this material, please either search my blog for “value realization” or drop me a line, and I’ll send you the links.)
3. Innovation/Research and Development.  This is the part of the IT budget that I think lends itself best to a voluntary funding model.  The most common funding practice I come across for this category of activity is “stealth funding” – i.e., the CIO squirrels away funds from other activities, and runs them below the radar – some unspent training dollars here; some savings from a renegotiated vendor contract there; some money left over from a project that came in under budgets, and so on.  The problem with stealth funding is that it is unpredictable, and it hides from the customer base the fact that money for innovation and R&D is actually necessary, and a sign of a healthy IT organization.

Fund Raising for IT R&D

So, how might this work?  First, the CIO needs to decide a funding target for IT Innovation and R&D.  This might be something between 1% and 5%.  Then build a business case – how will the funds be used?  Why should the business care – how might they benefit?  Typically, these funds will be invested in a mini-portfolio of activities, from low-risk to high-risk, and from short-term to long-term.  Will there be an expected payback on the whole portfolio?

For those business heads that chose to participate, will they get any special treatment compared with those who chose not to participate?  (This is a thorny question!  NPR does not threaten to cut me off listening to the wonderful Morning Edition or All Things Considered, or any of their great weekend shows should I not ante up each year for “membership.”)  For the CIO, I’m not sure how best to play this out.  I think some special treatment might be the ability to participate in business experiments that are associated with the R&D activities, but there may be other quid pro quos for those who pony up to the R&D fund.

Comments?  Questions?

So, what do you think?  How “fantastic” is my IT funding fantasy?  Are any of you doing anything like this?  How is it working?  Could it work?  Answers on a postcard, please!

An IT PMO Glossary

I’ve been working with a couple of clients around PMO’s and the thorny space of Portfolio and Program Management.  Not coincidentally, this continues to prove to be an area of great leverage for organizations trying to drive up their business-IT maturity (and with that, increase the business value delivered through IT investments, assets and capabilities.)  It also continues to be among the most popular topics on which I blog.

Each client quickly found the need to get themselves aligned around the terminology, and asked me to create a simple Glossary that would help them differentiate and standardize on the various terms that are central to IT Portfolio Management.

To that end, I offer here a “starting point” for such a glossary.  Of course, in our industry, where terminology is used inconsistently, and where opinions about meanings tend to differ widely, I realize that this exercise is fraught with danger.  However, I offer this as an initial point of reference.  I’d be delighted to hear any major issues with my use of these terms, and suggestion for modification and for extension to this list.

An IT Portfolio Management Glossary of Terms

(Note:  * Source is Wikipedia)

Term	Definition	Comments
Project Management	Project Management is the discipline of planning, organizing and managing resources to bring about the successful completion of specific project goals and objectives.*	Project Management is typically focused on deliverables, budgets and timelines to meet specific objectives.
Project Management Office	Project Management Office (PMO) is the department or group that defines and maintains the project management standards and processes within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance and metrics on the practice of project management and execution.*	Project Management Office models vary from organizational entities that define the process and standards for others to follow, to those that actually manage projects for the organization.  Considerations as to type of Project Management Office model will include organizational experience and maturity with project management, organizational goals in terms of consistency, commonality and control, and preferences for centralization versus decentralization. PMO’s are sometimes responsible for Project, Program, and in some cases, Portfolio Management.  In such cases, the acronym may be extended to PPM or even PPPM.
Project  Manager	Project Manager is a professional management role typically vested with the responsibility for the planning, execution, and closing of any project.	Some organizations insist on certification (such as by the Project Management Institute) for IT professionals who will manage projects above a certain size or criticality.  Sometimes, Project Managers are physically grouped into a Project or Program Management Office (PMO); other times they are virtually networked into a Project or Program Management Community of Practice, and sometimes they are simply expected (or at least, encouraged) to follow the processes, standards and methods laid down by the PMO without being part of the PMO organization or community.
Program Management	Program (or Programme) Management is the process of managing multiple interdependent projects that lead towards an improvement in an organization’s performance.*	Projects deliver outputs; programs create outcomes. A project might deliver a new factory, hospital or IT system. By combining these projects with other deliverables and changes, their programs might deliver increased income from a new product, shorter waiting lists at the hospital or reduced operating costs due to improved technology.  Program management is concerned with doing the right projects, whereas project management is about doing projects right. Successful projects deliver on time, to budget and to specification. An organization should select the group of programs that most take it towards its strategic aims whilst remaining within its capacity to deliver the changes* Many enterprise IT organizations tackle large, complex efforts that combine the delivery of software elements, new and changed business models, and overall changes to organizational structure and capabilities. Typically these efforts involve several parallel projects, and managers find that “traditional” project management approaches fall short for such undertakings. Consequently, many IT professionals are turning to the substantial body of experience, and the smaller body of documentation, that supports the discipline of program management. This discipline describes principles, strategies, and desirable results for managing large-scale efforts comprising parallel projects. (Source: IBM White Paper: Program Management – Different from Project Management)
Program Management Office	A Program Management Office is the department or group that strives to standardize and introduce economies of repetition in the execution of projects and programs. The PMO is the source of documentation, guidance and metrics on the practice of project and program management and execution.	The term PMO sometimes refers only to Project Management, other times to both Project and Program Management, and in some cases extends to Portfolio Management. .  In such cases, the acronym may be extended to PPM or even PPPM.
Program Manager	A Program Manager is a professional management role typically vested with the responsibility of coordinating multiple interdependent projects that lead towards an improvement in an organization’s performance. Program Managers have ultimate responsibility for the organizational performance outcomes.	Program Managers are highly qualified and experience Project Managers who have also mastered the disciplines associated with managing complex, inter-dependant groups of projects that collectively lead to improvements in an organization’s performance.  In addition to project management excellence, they are highly proficient in organizational change management, managing up as well as down through the organization.
IT Portfolio Management	IT portfolio management is the application of systematic management to large classes of items managed by enterprise Information Technology (IT) capabilities. Examples of IT portfolios would be planned initiatives, projects, and ongoing IT services (such as application support). The promise of IT portfolio management is the quantification of previously mysterious IT efforts, enabling measurement and objective evaluation of investment scenarios.*	IT Portfolio Management is founded on Modern Portfolio Theory which proposes how rational investors will use diversification to optimize their portfolios.  When applied to IT, Portfolio Management proposes how the organization (assuming it is acting in a rational way towards its investments) uses diversification to optimize its IT investments.  In this case, optimization may include balancing: Short term and long term investments. Low risk, low return against high risk, potentially higher return initiatives. Common and shared (i.e., IT infrastructure) against business unit specific investments. Investments by major business process. Creating new capability versus maintaining existing capability. Investing in IT process and capabilities (i.e., improving the “business of IT”) versus investing in IT capability for the business. IT portfolio management is the primary means to elevate IT decision making and investment prioritization to a business issue.  In this context, IT portfolio management includes a top down decision making framework, implying that: Senior executives have debated, considered and reached consensus about their IT investment portfolio strategy. This, in turn, implies that senior executives have considered and agreed to a business-IT strategy. They have wrestled with the thorny questions about “level of optimization” of IT investments – whether this should be a business unit or function (implying a conglomerate or holding company model) or the enterprise (implying a more integrated business model. If they balance by business process, that the major business processes have been defined, and their importance to business strategy execution determined. * They are able to monitor the gaps between their actual IT investments by portfolio category, against their target, or “model” portfolio, and can make adjustments as necessary.
Portfolio Management Office	See Program Management Office	IT Portfolio Management Offices are rare.  Rather, Portfolio Management is seen as a responsibility of business-IT governance, and the highest levels of business-IT investment decision-making.  As such, disciplines and groups such as PMO’s (or PPMO’s) are invaluable tools in support of effective IT Portfolio Management.