At Diamond, we are in the early stages of analyzing survey data from our 2010 Diamond Digital IQ study, a multi-industry study of the strategic use of IT.  The respondents are equally distributed between business and IT leaders. For more details on what to expect, have a look at the DDIQ results from the last two years and a summary published by CIO Insight.

To whet your appetites, I wanted to share one of the questions and its results.  In the complex, global and distributed business world in which we live, we wanted to know as a percentage, how much of an enterprise’s total IT spend resided in the CIO’s budget.  For the purposes of this question, I only included the results from the IT leaders with the thought that it would be the most accurate.  Here are the results:

Forty-one percent of those surveyed said that 30% or more of their companies’ IT spend lived elsewhere.  Only 37% said that they controlled between 90-100%.  This is certainly a complex question to analyze and understand given the complex business structures, sourcing approaches and IT service models.  I wonder if there are other indications here of an emerging trend to distribute more IT capability?

Stay tuned for an early view of other results and the complete analysis.

Get it Just Right by Jaci Berkopec

A recent InfoWorld article by Bob Lewis questions the IT organization concept of “running IT as a business.”  Paraphrasing, he poses several problems with it:

1. No one inside your company is your customer
2. IT’s costs are always higher than external options
3. Building software that “meets customer requirements” is short-sighted and reactive
4. Software product focus limits enterprise wide thinking and shared investment
5. It creates more organizational and relationship barriers and is seen as a vendor not a partner
6. Running IT as a business implies that chargebacks are used and are often used as a substitute for good management and governance

While I agree that many of these would be problems with an IT organization who takes the “run IT as a business” to the extreme, very few organizations out there have actually attempted that.  Instead, they have tried to become more “business-like” in their attitudes, strategies, planning, investment analysis, project management, measurement, etc.  The primary goal in “running IT LIKE a business” is to improve the business-IT communication (I hate that “business-IT” thing, but we have to deal with it for now…) and reduce the translations from business need to value delivered.

I would also argue that any software or services business organized like Lewis suggests wouldn’t be in business for very long, and therefore, it’s a worst-case model.  Most decent businesses (and IT organizations) have learned how to treat their customers as more than transactions, bring ideas to the table, have meaningful design discussions, and understand that innovation is critical to growth.

The Business of IT

So, instead of trying to apply “run IT as a business” literally, what can an organization do to improve its business savvy and think more like other parts of the business?  Here are some ideas based on what Diamond has seen from successful IT organizations:

Lewis and I agree on at least one thing: IT should become more integrated with the business, not less.  Running IT like a business is all about that.

by Chris Curran and Jim Quick

Portfolio management was all the rage 5-6 years ago, driven in part by some good management thinking from people like Peter Weill at MIT CISR and Dr. Howard Rubin and in part by some software tool vendors.  Back then, most organizations added some kind of portfolio thinking or at least dabbled with it.  While most of the interest seemed to be in the IT organization, some organizations actually drove portfolio thinking up higher in the organization where it belongs, where a complete view of an business investment can be calculated and evaluated.  Those organizations who didn’t find value in portfolio management likely found it too complex, too much overhead or too theoretical.  However, we believe that as organizations are preparing to come out of the recession, they are thinking more broadly about the types of investments they will need to make to support business growth.  As a result, some are re-looking at portfolio management as a way to organize and evaluate.

One of our financial services clients has historically driven its investment planning at the product level – they have 3.  This had served them pretty well until they realized that their customer facing systems had diverged to the point where they not only looked fundamentally different, they were developing software using 3 different technology stacks.  As a new CIO entered, he quickly diagnosed the need for a single view of the projects with special emphasis on cross-business sharing of investment dollars, projects and software assets.  And, he turned to portfolio management as a technique for organizing his thinking.  And, interestingly, the first question asked was to determine the starting portfolios – which, in turn, should be discussed and centered around business capabilities and goals, for starters.

What’s In the Portfolio?

There are 2 questions to ask when designing a portfolio management approach:

1. Which Budget?
2. What Types of Investments?

The IT budget is the scope of most organization’s portfolio management.  However, some have applied it successfully across all business investment (eg, those that have a PMO covering investments business-wide). Successful companies are focused strategic ideas early in their life cycle and utilize portfolio management principles to screen, evaluate, and calculate the total cost of investment (business activities, application development, architecture, infrastructure, and some ongoing costs).  It’s important to keep this process and governance as simple as possible – over-engineering can result in people reverting back to spreadsheet tracking and one-off discussions.

The second question to tackle is what kind of investments will you track within the budget?  The holy grail for us is to talk about the “total” investment made in the billing function, for example.  It would include all the labor, hardware, software, paper, telecom, etc.  This requires access to all of the spend data at a granular enough level to allocate it to a business function and a way to allocate the cost of shared services.  Unfortunately, not many organizations have this data easily available.  So, the default for many, at least in the beginning, is to look only at project-driven investments.

Start With Projects

Projects are an investment ready-made for portfolio management because the planning process usually includes the basic information needed to categorize and evaluate it – cost, duration, benefits, estimated return, risk, etc. – the elements of a standard business case.  Most mature organizations have a robust project proposal and estimating process.  To begin effective portfolio reviews and analysis, you need three kinds of project data:

1. Business Impact – which capabilities required by the business over the next 12-18-24 months are built or enhanced by the project?
2. Financial Case – for the proposed costs, what type of return is projected?  Is it a straight forward ROI business case, an earlier stage pilot to learn more, or an investment needed to remain at competitive parity?  The financial case for different types of investments can be vastly different.  For example, a risky, early stage investment may have no  immediate return but can gather data to drive a more realistic business case.
3. Risk Profile – how hard will the project be for us to pull it off?  do we have the skills, experience and leadership?  What’s the impact to the business if we are delayed?  Are there any external risk factors like customer satisfaction or regulation?

With this kind of data for each proposed project, you can then start to evaluate the mix across various dimensions, such as business capability and risk/return.  The next steps are to add in information about in-flight projects and to measure actual investment returns upon project completion.
photo credit: striatic

One of the fundamental mysteries in the practice of IT management is “why cant we get better at delivering projects?”  Much has been written about the subject, with the balance focusing on the negative – project failure, IT Fail, etc.  A recent article in MIT Sloan Management Review got me thinking about another angle on this question – maybe we are ignoring some fundamental, but less obvious signs that our projects are not positioned for success.  These signs, or weak signals, require different mindsets and toolsets to gather, track and act upon.

In my last post, I outlined a few biases that I have seen in individuals and entire organizations that block our ability to see weak signals that threaten IT project success.  The next step is to think about where these important, but weak signals may come from and how to go about gathering intel.

Detecting Weak Signals

Schoemaker and Day propose six ways to gather and interpret weak signals (actually they have 9 items, but the last 3 are more about acting than detecting).  I have added thoughts on how each could apply to IT projects.  Their six weak signal detection methods are:

1. Tap local intelligence
2. Leverage extended networks
3. Mobilize search parties
4. Test multiple hypotheses
5. Canvas the wisdom of the crowd
6. Develop diverse scenarios

Tap Local Intelligence

Project information tends to be distilled like the best vodka, over a series of multiple steps and through many filters.  Any hope to understand what someone on a project team is really thinking or feeling is hopeless through traditional status reporting and meetings.

Management By Walking Around (MBWA) and Toyota’s version, Genchi Genbutsu, are both philosophies that management can learn a lot by listening to the guy on the ground.  In addition to just making time for individual project team members in their work areas, a project sponsor could invite a team member at random to each project status meeting with the goal of hearing their top 3 issues.  If the cultural or political issues of doing this are overwhelming, the project sponsor could do it over lunch a few times a month.  It’s amazing to me how many project execs and sponsors work in different buildings and never make appearances in project facilities.

Leverage Extended Networks

What extended networks exist that apply to IT projects?  Execs of several companies sit on technology vendor advisory boards.  This could be a good channel to get feedback on a vendor’s performance elsewhere and to learn where their expert resources are focused.  The same goes for user group forums and conferences, with the former providing more up-to-date information but probably not as unfiltered.

I can think of several projects where smaller vendors were used but were unable to effectively leverage their few true subject matter experts across all of their clients.  This is not something the vendor would likely tell you and may only be revealed through weak network signals.

Mobilize Search Parties

“SWAT Teams,” quickly deployable teams of experts, are pretty common for large projects and programs once the implementation gets hot and heavy.  One of our healthcare clients used a SWAT team focused on technical architecture that was heavily used across 12+ projects when they were rolling out a new services oriented architecture.  But, this isn’t exactly what Schoemacher and Day are talking about.

This one stumps me a bit.  I’m trying to envision a small team whose mission is to snoop around and look for problems.  One could argue that this is one job that a good program office should perform, but this would only work with seasoned leaders who know what signs to look for.  I’d love to hear any examples of “search parties” that work.

Test Multiple Hypotheses & Develop Diverse Scenarios

Personal and organizational biases often make us “explain away” potential problems as low probability or even impossible.  Asking “what if?” could be useful but only if leadership is willing to dedicate time and potentially money to develop plans for contingencies.  The two scenarios I see most often that would benefit from hypotheses and scenario planning are:

1. Key project leaders get burnt out and leave the project prematurely
2. Small vendors implode

One question is when and how often to develop and test hypotheses.  This can be an important tool but one that won’t typically get focus from project teams.

Canvas the Wisdom of the Crowd

Prediction markets are an intriguing technique for gathering the wisdom of crowds.  While not universally applicable, there are some incredible examples of the accuracy of group predictions outlined in James Suroweicki’s Wisdom of Crowds.

One of my colleagues, Michael Krigsman, who is an authority on IT project failure, has developed a tool through his firm Asuret, that seeks out weak signals from project stakeholders through a survey-like mechanism.  I look forward to piloting it with a few clients.

In summary, there are 3 things I’ve concluded about weak signals:

1. We need to challenge senior business and IT leaders to be more involved with our teams on the ground and act on the signals they get
2. I think that the weak signals theme highlights the need to have seasoned project leadership.  PMP-certified managers just aren’t enough, at least for large and/or complex efforts.
3. There are some techniques that we can apply to gather non-traditional project signals.

Every little bit helps in sniffing out projects that are destined for trouble.  You would think that with 10+ years of project success data from Standish and others, we would have collectively improved things significantly.  This is not the case.

So, I read with interest Paul Shoemaker and George Day’s article in the Spring 2009 MIT Sloan Management Review called How to Make Sense of Weak Signals with an eye toward applying these ideas to large projects (which as we know largely live in IT).

With the lessons of the subprime market crash as their lead-in example, the authors say that managers can be lulled into blindness and respond to weaker signals with the easiest or most convenient response, instead of one that anticipates the worst possible outcome.  In fact, the authors say:

Our own research suggest that fewer than 20% of global companies have sufficient capacity to spot, interpret and act on the weak signals of forthcoming threats and opportunities.

It’s personal and organizational biases that cause blindness in management.  Applied to managing individual projects and sets of related projects (or programs), I think there are some biases worth looking at within each of the organizations with which we work.

In the next post, 6 Ways to Find Weak Signals, I explore some ideas for overcoming our biases by recognizing and processing weak signals that our teams are sending us.

I caught part of a Charlie Rose interview with Jay Rockefeller this morning (episode not online yet) and heard the senator say that pay-per-service healthcare is a bad idea.  Being deeply immersed in the cloud computing discussion that hangs its hat on a similar payment model, I paid more attention than I might normally.  He said it’s bad because it encourages providers to add more services to make more money – regardless of their appropriateness.

One alternate model is a “pay-per-outcome” model like the one the dentist uses for my son’s orthodontia.  For a fixed fee up front, my son gets all of the office visits, hardware, adjustments, etc. until he is done.  This model seems to work best where the overall process is pretty well defined and exceptions to the process are not too costly.

I would propose that the pay-per-service model itself is not the problem in healthcare, but that it’s the particular situation that confuses things.  The healthcare marketplace has complex products and services, a vast and oftentimes confusing provider network, and unclear costs.  Interestingly, this is very similar to the context that surrounds IT services within an enterprise.

I think both of these marketplaces, healthcare and enterprise IT, suffer from:

1. Customers who don’t understand the menu of services available
2. Customers who don’t understand which services map to his or her problem(s)

The result of this situation is a small set of customers (patients, enterprise IT users) who put ultimate trust in their provider and let them determine which services they need and that the right costs will be charged, and a much larger set of customer who are skeptical, confused and vocal.  We can learn some lessons from this debate in the way we lead and manage the IT function.

The Menu of Services

Have you ever seen a list of services and their costs in your doctor’s office?  You better believe that they have this list and an exact reimbursement rate for each.  Why don’t they share it with you?  For you IT leaders out there, do you offer a list of services IN UNDERSTANDABLE TERMS to your customers?  Do you clearly describe the cost of each service?

Applying the Right Service

When you have back pain, does your doctor describe the course of action in terms of the services he will perform?  Does he provide a list of alternatives that includes the cost differences to you?  For IT leaders, do you describe possible services that could be performed to help your business user add more calls into the call center, for example?  Do they clearly understand the alternatives and costs?

In the end, in healthcare and in enterprise IT, improving the overall service model and cost effectiveness depends on transparency, clear language and education.  Are you doing everything you can to improve these things in your organization?

by Chris Curran, Steve Legnine and Rob Boudrow

Lean, an optimization philosophy embodied in the Toyota Production System, is re-gaining popularity among some of our consumer products clients as they continue to search for ways to do more with less. I’ve asked Diamond’s business process expert, Steve Legnine and our IT optimization guru, Rob Boudrow, to work with me on this post to get the best thinking from the process quality world and to make sure we make a solid translation to the IT world.

For some, “Lean” has a negative connotation, especially in the current economic environment. The reality is Lean is about eliminating waste, not operating with fewer resources. Companies are already running with minimal staff, but also have corporate agendas to grow revenues. This is where Lean comes into play, helping companies stop doing non-value added activities and start handling growth.

As a simple but stark example of waste, Steve describes a company whose customer service agents make 12,000 weekly trips to and from the printer only to throw away the paper. Now that’s some serious pork! Imagine the opportunity for additional calls and deeper interaction represented by that wasted time. Not to mention, IT spend associated with printer maintenance and support continues to rise.

I saw another example highlighted in my WSJ iPhone app describing Starbucks and its efforts to apply lean principles to its 11,000 stores. The most important concept for them is identifying wasted motion:

“…reducing waste will free up time for baristas…to interact with customers and improve the Starbucks experience. Motion and work are two different things. Thirty percent of the partners’ time is motion; the walking, reaching, bending…”

So How Does Lean Apply to IT?

Some has been written to apply lean concepts to IT comparing lean with agile, focusing mainly on the software development process versus on IT as a whole. I don’t view the two as similar. Lean describes the ‘what’ – reduce waste, etc. Agile, as an extension, is one way to approach ‘how’ – describing ways to eliminate low value meetings, etc.

When discussing Lean IT, it’s more useful to separate the “what” and “how.” Furthermore, it does not have to be an all or nothing. You don’t have to apply the same level of lean to the entire organization. You could apply agile to the SDLC but leave the help desk alone

Also, before looking for waste in IT processes, we need to understand the processes themselves. In our experience, IT organizations often struggle in getting efficient processes communicated and adopted across their organizations. Inconsistent and ad hoc processes are a root cause of much of the waste. Some examples:

• During a new social media project requiring a flexible approach in dealing with multiple vendors and hosted components, we discovered that our client team did not have a basic understanding of ANY software construction method or approach (Healthcare)
• A CIO asked for an approach for measuring productivity in his development staff and invested $2 million in implementing a tracking and reporting tool. The staff however wasn’t clear on the SDLC process steps or terminology and as a result couldn’t provide any accurate and detailed activity data. (Insurance)
• One client recently discovered that one daily report was producing 5 million printed pages. No one seems to know if anyone actually uses it. They shut it off saving an estimated $18m a year and are waiting to see who screams. (Healthcare)
• A recent diamond project team analyzed service request processes in IT. Out of the 43 request types identified some ~25+ of them required approvals. When pressed on if they have ever declined one of them, many of the request owners shrugged and said never. So, why is there a 3 day fulfillment time because a single person has to approve? (Transportation)

Over the last 5 years or so, adoption has certainly increased in standard processes, especially around ITIL. That said, no studies on core process adoption are above 40% for any of the IT’s major functions.

Forrester 2008 Agile Survey

• 33% using some form of Agile
• 35% using a waterfall approach
• 9% using CMMi

Dimension Data 2008 Study

• Almost 60% are working with ITIL
• Only 10% consider themselves “true practitioners”

I think this data is interesting because organizations seem more interested in optimizing their processes than in defining them in the first place.

Two Kinds of Lean IT Initiatives

Lean initiatives come in two flavors: Quick Hit and Deep Dive. The Quick Hit approach is most appropriate with processes that have obvious trouble spots and those with little variability. The Deep Dive approach is appropriate for established processes where inefficiencies are suspected but are not obvious and for organizations who wish to establish or expand their continuous improvements.

The major point of the table is that if you don’t have well-established core processes, then you are not ready for a Deep Dive Lean program yet. Instead, you should focus your efforts on identifying Lean Quick Hits and implementing more efficient core processes.

Going on a Diet

There are many gaps and delays in how IT organizations communicate internally – Applications to Infrastructure, Architecture to Everyone else, one application team to another. SDLC methodologies are supposed to help, but taking waterfall as an example, it could easily create waste (waiting, breakdowns in communications) if not well engineered.

Once you have defined the priorities, follow one of the many variations of Lean methodology, for example:

1. Build a value stream map
2. Identify opportunities or gaps (see Kaizen Bursts as one technique for capturing ideas)
3. Prioritize the opportunities based on level of complexity and impact
4. Create a baseline to measure impact
5. Fix the easy to implement opportunities with the greatest benefit
6. Review the value stream map and target the next wave of opportunities which may be moderately more difficult to implement, but has the potential for significant benefit

Bottom line is – like Six Sigma, CMMi and other improvement models – Lean is not a formula for success. It requires both subject matter experts who understand how things are and can develop ideas for where waste lives and process optimization experts who analyze work, understand cost-benefit tradeoffs and can plan and execute the improvements.

Obviously, this article just scratches the surface on a very complex topic. The most important thing here is to not jump into a Lean IT effort without understanding the maturity of your core processes and getting the right skills an experience involved in the project. In future posts, we will further explore the topic from an SDLC perspective.

I spent last week at Boy Scout Camp in Oklahoma.  One of the benefits of attending a Scout camp as an adult is the great training opportunities available.  This year, I was able to get Red Cross certifications in First Aid, Wilderness First Aid and CPR during the week – all very important when dealing with boys (and adults) in camps away from good cell phone signals.

As I sit here and take a break from sifting through a week’s worth of email, I was wondering what kind of first aid lessons could be applied to the management of IT.  One of the questions I hear a lot is what role the CIO has in keeping projects out of trouble.  This is especially challenging in large organizations where the CIO has several layers of management (a topic for another post!?)

The main text used in the wilderness first aid class is Mountaineering First Aid, a very comprehensive and practical guide.  It outlines a list of contributing causes to mountaineering and climbing accidents:

Bad judgment using equipment:

• Climbing unroped
• Inadequate equipment/clothing
• No hard hat
• Placing no or inadequate protection

Performance/judgment error:

• Exceeding abilities
• Climbing alone
• Party separated
• Failing to follow directions

Environmental conditions:

• Bad weather
• Darkness
• Falling rocks
• Avalanche

Equipment failure:

• Chock/nut pulled out
• Inadequate belay

Applying First Aid Lessons to Projects

So, using this framework we can discuss analogous issues and considerations that a CIO could apply in planning and running projects.

Most of these preventative ideas center on having the right people with the right skills and experience staffed to projects.  I think that the biggest opportunity in most companies to address this is to create an explicit project staffing function that works with project sponsors and managers to understand the project details and with the various business and IT managers to match the roles to the individuals available.

I am looking forward to your comments and thoughts on this.

Update: Tweaked the CIO Questions to make them more open-ended, per a suggestion by Brunella Longo

This post is about managing the life and death of technologies in an enterprise. Not projects or applications, but the portfolio of the underlying technologies – operating systems, DBMSs, development tools, middleware, etc. These must be managed too or you will find yourself in the same situation as a client CIO of a large retailer did a few years ago.  The servers than ran the in-store processors – the computers in the back office of each store that run the point-of-sale computers, cash management and inventory applications – were discontinued by the vendor.  Not only did the vendor tell him that they would no longer support the servers, they told him that his staff that managed them probably represented the largest pool of skills in the country for the devices!

So, the technologies that underlie our business applications have a shelf life that must be actively managed, with plans to introduce and retire them just like the applications they support.

To get a handle on your technology portfolio, there are 4 basic steps.

1.  Create an inventory of the technology portfolio

The first challenge is to get a list of all of the different technologies you have in use.  Some of the attributes you may want to capture include:

• Component Name and Vendor
• Version or Model
• Component Type – operating system, DBMS, development tool, etc.
• Applications it Supports
• Number of Users Supported
• Amount Spent Per Year (labor + licensing + upgrades)
• Sourcing – internal, hosted, cloud, etc.

If you already have a decent inventory, consider yourself very prepared – most firms don’t in my experience.  Also, anything you can do to tie each component to value, users or processes, the better.  These attributes will help you with prioritization later.

Another dimension of the technology to consider is vendor stability.  While the technology itself may not be obsolete, the vendor may be so small that the component should be considered high risk and flagged for review.  For one of our financial services clients, a small vendor provided the foundation for one of its banking applications and the vendor went bankrupt.  The client ended up with a pile of code and no one who knew anything about its inner workings.  Not good.

2. Map technologies into their stages

The next step is to figure out where each technology sits in its lifecycle.  There is no single, hard-and-fast classification scheme but the technology lifecycle typically is segmented into five or six phases, such as the following:

1. In the Labs
2. Emerging from the Labs (early adopters)
3. Leading Edge
4. State of the Market
5. Last Generation
6. End of Life

Use this, or another classification scheme to describe where you think each technology lies in its lifetime.  There is a bit of art to this as there is no single reference for this kind of thing.  At PwC’s Diamond Advisory Services, we have developed our own database, blending market data with our own observations and experience.

3.  Analyze the portfolio and act

Once you have all of the data pulled together, you need to take some time to digest it and mull over possible changes that you need to work into next year’s plan or maybe something sooner. It might be useful to map your data onto a bell curve. In this example , the size of the circle represents relative cost.

Pay special attention to the technologies at the front and rear of the curve.  For the older technologies in the portfolio:

• How many users are they supporting and how much does it cost?
• What is required to retire it and its related components?

For the bleeding edge technologies:

• Do you really need them or are they toys in someone’s toybox?
• How will you know if they should be used in more core, mission critical applications in the future?

After analyzing, collecting and refining the data and asking a lot of questions, you may be ready to make some changes, either in your annual plan or as a more immediate action.

4.  Create a process to review and refresh the technology portfolio

So that all of this effort is not a “one and done,” you should embed a periodic review into your core planning, architecture and governance processes.  One of my insurance clients gave responsibility for managing the technology portfolio to the Enterprise Architecture function. In fact, they considered this entire process part of their technology innovation process.

Like its applications siblings, managing introduction and retirement of underlying technologies cannot be done alone – it requires coordination across all IT disciplines, including planning, development, architecture and infrastructure.  But it is important to have a coordinator responsible for collecting and analyzing the information and bringing it to the proper leadership forums for discussion.

Some final questions to consider for your organization:

1. Does it even make sense to consider the technology portfolio separately from the applications they support?
2. How much responsibility do we assign to our vendors in helping us identify and manage technology introduction and retirement?
3. Can the old age (and lack of skills, etc.) of a DBMS or middleware component be enough to drive a major application change?

Photo shared by crabchick

Yes, I realize that “doing more with less” is a saying that is used to encapsulate the increased pressure on the enterprise, and the IT function specifically, to keep the business running with less revenue coming in and lower budgets.  But, it bugs me because I think the saying propagates the myths that somehow IT can squeeze even more blood out of the stone, in the same environment in which the business is dissatisfied with IT support, projects continue to be delivered at low success rates, etc.

Hopefully, the early signals from Cisco and others are accurate and we will see the spending pressures release somewhat.  That said, what can a CIO and her leadership teams do to optimize its investments?

You would be surprised how much head-scratching goes on when organizations try to decide which projects do or don’t make sense.  In many cases, it just boils down to which executive sponsor yells the loudest – literally.  There is a better way – make sure that all IT investments can be tracked back to one or more specific business objectives and more detailed capabilities.

Here’s how:

Drive High-level Business Objectives into their Corresponding Business Capabilities

This is the hardest part because it requires not only an initial exercise but a systematic approach to keep it current.  In our practice at PwC, we recommend enterprise architecture as the function to own the business objective to business capability mapping as well as the subsequent links to the underlying systems and infrastructure.  As an example (detailed here), let’s look at Wal-Mart. They have a relentless focus on the customer, which translates into an objective to always have product on-hand.  But this objective does not stand alone – it is supported by several business capabilities, that are in turn, enabled by information technology.

Attach Business Capabilities to Projects in the Portfolio Management Process

Many organizations do their formal project approvals once a year, in the beautifully productive time known as “annual planning.”  In our 2009 Digital IQ study, we found that on average, companies spend over 2.5 man years on this – clearly an area for some re-engineering.

This is a start, but not sufficient because as quickly as things change, the entropy of the organization will tend to forgo the rigorous business capabilities mapping.  But it is worth integrating directly into the process in which projects are defined and approved for two reasons.  First, it will improve the percentage of projects and dollars aligned with the business needs.  Second, it will allow you to directly attribute IT effort to business value (see #3).

Show IT’s Value by Tracking Delivery of Business Capabilities

One of our healthcare clients calls a report they produce, their “under the hood dashboard.”  It’s a great report that tracks IT’s delivery of the business capabilities month-to-month and quarter-to-quarter.  It uses business language and terms defined by the business – terms like those used in the Wal-Mart example.  It has an unfortunate name since us IT-types would like to be thought of as more than mechanics, but it will do because it represents a simple and direct way to show what IT is working on and that it directly contributes to moving the business toward its goals.

No matter what the economic climate is, as IT leaders we should always look for ways to maximize value for investments we make and I believe that these 3 steps are a great start.  Because I don’t think “Doing More with Less” sends the right message, I am hereby re-writing the old saying to “Do the Best with Less.”