Using the word “strategy” could have shortened the title of this article.  Unfortunately, the word started with several meanings and now, thanks to its constant misapplication, has none.   If you want your IT projects to sell up the chain easily and to achieve measurable business results, you’re going to have to hear the word “strategy” more often than your own name.  Here is a definition of strategy that will cut through miles of dust for anyone in a for-profit business:

Strategy:  A plan with identified short, medium and long-term goals related to revenue growth, cost reduction, company value, market evaluation and opportunity cost.  For the plan to be a strategy it must balance the natural antagonism between short, medium and long term needs and be prepared to generate a relatively positive result under all reasonable circumstances.

The herd of cats will immediate yowl over this definition.  It lacks a reference to competition, price leadership, differentiation, and focus; there are no stars or cows or dogs or question marks; it lumps functional, business and corporate strategy into one big bucket….  The cats are all correct in their criticism.  Please lambaste me via email ([email protected]).  Feel free to blame me for everything that is wrong with this definition.  Just make sure the discussion eventually comes back around to making money, saving money and building the company.

Finding the Goals

IT is concerned with systems.  These systems share one common trait; they all have inputs and outputs.  A company or division has a similar structure.  Its inputs and outputs are in the form of monies, goods, services and waste.  Theoretically the company or division adds some value to the inputs that is reflected in some of the outputs.  Like any system, the interface constraints, throughput and capacities of the system limit its capacity to add value.  Time and culture are major factors in this because today’s values and needs may not be the same tomorrow.  This caveat holds true for a place or group of people as well.

So the questions for the IT decision maker are, “What business inputs and outputs will be changed by this new system or by maintenance of an existing system?  What will it cost to make that difference?  When will those changes produce a net benefit greater than other alternatives?  Will the users recognize and accept the path to benefit?  What is the impact in the short, medium and long term?” Oh, and I almost forgot, “Does this support the company’s strategic objectives and, more importantly, its strategic maneuverability?”  There goes that word again.

Hopefully, your executive leadership is considering several dimensions (including time) in their strategic process.  Unless something is very wrong, the process will produce a return at some point.  If you find that revenue growth, cost reduction or company value aren’t among today’s priorities, you’ll need to find out what today’s priorities are and how they relate to those goals in the future.  Without this insight it will not be possible to assign priority and value to any proactive IT spending.  Strength of will, reference to competitive trends and FUD (fear, uncertainty and doubt) campaigns will work to get a project through but it’s a bumpy ride with dangerous turns and an unfamiliar destination.  Most effective people like a clean win when they can get it.

Aiming for the Goal

Once you have an idea of where your company wants to be at what points in time, you can establish the benefits that a system or systems can deliver toward that goal.  The trouble you’ll run into is that identifying, establishing trace-ability for, and quantifying these benefits in detail is often a gigantic job.  It gets more complex when you add time and change to the equation.  This is the point that makes most IT shops choose to be excellent at reactive development rather than confront the job of taming the beast.  This is also a good time to scream the word, “POLITICS” at the top of your lungs.

Go to the Center of Danger and There You Will Find Safety

Encourage the measurement of your systems from the point of view of strategic and financial decision-makers.  Present your plans in a form they can use (with your help).  Team with them in structuring the internal value proposition of IT efforts and support them in presenting it in their language. 

These questions and ideas all boil down to the same pattern: leverage the core competencies of other departments and decision-makers whenever possible.

1)     Did you find a strategy when you went looking for one?  (See the above definition of strategy - that’s the one I’m talking about).

a.      If yes, then someone should have an idea of the how much money the strategy is projected to bring in and how much is projected to go out at what times.  Support or improve these numbers with systems and everybody wins.  Look at the features of the system with an eye toward quantifying each feature according to its part in the big picture.

b.      If no, assume an approach that adds company value, increases revenue or decrease cost every year is the best approach for IT.  Measure every quarter and make sure that no two consecutive quarters produce a net loss.  Get help from the accounting and finance side of your company to do this appropriately.

2)     Does your accounting department use the FASB 86 rules for GAAP:

a.      FASB 86 allows companies to capitalize new applications and expense maintenance on existing applications.

b.      Discuss the accounting impact of the project life cycle with the appropriate people.  There may be a method of accounting for your IT expenditures that gives you more flexibility and/or affords more benefit to the company.

3)     Does your leadership use NPV (Net Present Value) analysis to make decisions about internal investments such as IT projects?

a.      If yes, get in contact with the analyst(s) responsible for this work and step through their evaluation process.  You might find that the risk to the organization of not investing in IT projects is outside of the constraints of their model.  It’s unlikely that an 8% bond is worth more to your company than a working email system but that’s the type of result you can get with NPV if you’re not careful.

b.      If no, find out how the future (and opportunity cost) fit into the decision process for IT projects.  Your leadership may not understand that IT projects are investments in the future with a pay-off they can count on.  If they don’t get it, paint them a picture.

4)     Does your company have detailed knowledge of its processes and their costs and benefits?

a.      If yes, that information is gold.  Get it and use it.

b.      If no, work process discovery into the requirements gathering phases of your projects and give ownership of the process documents back to the manager(s) in charge of it.  Version control the process documents.  If you use more sophisticated process mapping tools - you probably don’t need any of this advice.

5)     Does your company use any metrics (measures) that are already associated with financial assumptions?

a.      If yes, get to know these well and stay on the lookout for ways of improving their accuracy and availability.

b.      If no, you will need to identify a minimum set that will help in understanding the financial impact of things that may be improved with technology but are not currently measured in a way that would show its benefit.

Paint a Picture of the Goal Achieved

What do you do when a number of constituents with varying levels of power need to commit to a coordinated approach to a potentially chaotic situation that might win them major benefits and will cost them serious effort?  For the last 17,000 years you had to paint them a picture on a wall.  Who are you to buck tradition?

System Context Diagrams consistent with the work of Tom DeMarco and James and Suzanne Robertson are an excellent way to get people with varying levels of technical sophistication on the same page.  The great thing about their methods is that anything that flows in a direction can be modeled as a system.  This level of flexibility is necessary if you’re going to define the flow of information, monies and goods between your company or division and others. 

These flows can be modeled in increasing detail through departments and/or enterprise systems right down to a piece of stored data.  Color coding or other methods can be used to depict changes through time.  Anything not requiring immediate attention can be left at a higher level of detail without losing a sense of its connection to more detailed matters.

Everything that flows between two objects has a cost and a benefit to the company.  Even receiving funds has costs and benefits associated with it such as systems, labor, and more particular issues like float.  Having a clear idea of the net value of each of these flows gives you several immediate benefits:

• More detailed flows on which a given evaluated flow depends can be assigned a dollar value based on what part they play in the evaluated flow’s capacity and throughput.

• Cross department initiatives such as CRM, Enterprise Portals or Workflow Engines can be quantified in a way that maps out to the touch-points of the company and across to the flows between departments.  This makes it easier to assign a dollar value to features and functionality.

• Requirements gathering and analysis efforts can incorporate financial measures that relate to specification details.

• Bottlenecks can be mapped to their dollar impact.

• The organizational impact of change can be better understood and quantified.

• Areas of the company that may be bleeding for lack of automation but not in line for the “flavor of the month” initiative can be identified and served at the appropriate level of financial commitment.

• Process and system changes resulting from strategic alterations can be better planned and understood.

• Function Point Analysis and other costing methodologies can be reused for benefit measurement.

• IT status reporting can incorporate financial impact in a detailed way that shows the upside.

• Return on Investment will not require rocket science.

Hit the Target & Measure how close you are to the Bull’s-Eye

Most planners are obsessed with whatever facts they can get their hands on about their domain of inquiry.  Build the measurement of a given system’s value into the system if at all possible.  If not, find ways of collecting credible and useful data on its value.  When you discuss these ideas with strategic, accounting and finance people, look into what data they will need to validate the assumptions you will make to create the model.  This factual data will be vital to the future use of these types of methods.

Regular delivery of this type of information will train your organization to think of IT as a source of measurable benefits.  IT costs will be seen in a new light.  Objective measures will alter the political landscape in a way that, at least, provides a common view of a system’s value.

Start Where You Can

These methods are only one means of many to map IT projects to the top and bottom line.  The most important step is to discuss measurable value with the people who measure it.  The most important message to take from this article is that it is possible to connect IT projects to making and saving money for your company without going crazy trying.

Tim Rohde is the Business Intelligence Practice Manager for One, Inc. - Los Angeles.  Tim is an instructor for DCI’s eCRM and eB2B Universities - the only national accreditation program for these disciplines.  As a board member and instructor, he is also assisting Cal State Fullerton in designing and implementing an eCRM accreditation program.  Tim leads a team of business consultants responsible for operational strategy, business analysis, systems analysis, change management and project cost justification for leading clients in entertainment, travel, commercial real estate, healthcare and technology.