cazh1 » Business Value of IT

The Hegemony of Large Numbers – Ignoring Common Sense

Jim MacLennan — Tue, 01 Mar 2011 02:32:28 +0000

Ok, maybe I’m stretching the meaning there, but that’s a cool sounding title, and what I see as an interesting phenomenon. People get excited about Large Numbers, and think they have meaning and importance simply because they are Large Numbers.

The Law of Large Numbers ...

Big Errors

For example – years ago, when an application manager was whirling around the office in a minor uproar, worrying that that someone accidentally keyed in a $1B line item on an invoice.

That’s $1,000,000,000,000 – for the Unit Price.

Well, come on, that number is so ludicrously high, the error condition sticks out like a sore thumb. A single order like that is 1000 times our annual sales, for goodness sake – no one would let an error like that get all the way through to the month-end closing documents, or the daily sales report, or the AR reports. And no one would believe it if they saw it there.

So just calm down and reverse the error – maybe add a little data entry validation to prevent another such “catastrophic event”. (Note – this was in the days of the S/36 and the AS/400 – the user tabbed out of the data entry field, didn’t use field exit).

We should be more afraid of the small data errors – what if you mistakenly introduced a 10% error by transposing a few numbers – what happens then? Cranky customers, lots of backing out, and a difficult needle in the haystack to find.

Big Benefits

Projects these days need lots of business justification to prioritize above the many others vying for attention. But a benefits statement that claims $100M in costs aren’t getting allocated correctly? Where’s the real benefit here? Not $100M, but making the overall profitability of the products or customers in question more accurate. Not a lot of quantifiable benefit there – but $100,000,0000 looks so impressive.

Or maybe the classic “sales force automation” justifier. If I can make my sales reps just 1% more productive, and annual sales are $100M, then surely we can justify spending $1,000,000 on the Fancy Software System. The big numers make for compelling math – but will you get the sales force to commit to the incremental revenue? A difficult task, typically.

Common Sense Helps

Everyone is busy, everyone working hard and trying to make things happen – and unplanned interruptions or competition for scarce resources (including time!) can lead to interesting reactions to such Large Numbers. Unfortunately, most folks also do not have enough time to pause and reflect on the reality that those numbers are trying to express. Realistic? Rarely.

Just count to 10 … slowly …
(that’s not too large of a number …)

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: benefit, business savvy, errors

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Chargebacks vs. Allocations – Defining IT’s Relationship with the Business

Jim MacLennan — Mon, 17 Jan 2011 01:37:52 +0000

Some IT departments prefer chargebacks, while others do not. My own preference is to allocate IT costs to the business units, based on some reasonable balance of simplicity and accuracy. General services could be allocated by headcount, COGs, or revenues, with each business unit taking their proportional share. Some easily identifiable items might be allocated more directly – maintenance costs for specialized engineering, warehouse management, or financial systems, for example, could be allocated more directly to those departments.

What did I get for this project?

I’ve written before about my opinions in this area – the important strike against chargebacks is that they create a relationship between IT and the business that is confrontational, not collaborative – not the best way to bring value to my employer.

More reasons to consider annual allocations:

Increases IT and Business Agility: Specific projects can start and stop as requirements change, without having to renegotiate costs and resources. This would also help shift thinking from Projects to Programs – fluid collections of deliverables, with teams that can quickly flex when needed.
Shifts the conversation from Costs to Benefits: Instead of scrimping on component costs, business can focus on the benefits they are targeting.
Bolsters the Case for Integrated ERP: A reasonably complete allocation model will put all costs for siloed systems on the business areas that use them; typically, integrated ERP with common technology and less handoffs should streamline this overhead and reduce those costs.

But I know that change can be difficult; I would approach the challenge quantitatively and qualitatively:

How much overhead does this cost negotiation process add? – Make sure project teams record time spent on cost identification and justification, the calendar delays when individual projects are held up for review and approval, and the effort time required to charge the time back to the appropriate cost centers.
How much accuracy does all this chargeback process deliver? – Develop an allocation methodology, and retroactively compute IT allocations for the past 2-3 years; then, compare to the actual charges.
How fluid can a project list become when allowed to respond to demand? – Compare project pipelines between IT organizations of companies that allocate vs. charge back, and the changes over time.

Again, the best reason for allocations is that they shift the IT / Business relationship. When the focus is business outcomes, we are working as Partners, not as Vendor/Customers.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: business alignment, business benefits, business value, chargebacks

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Defining Business Benefits: Hard and Soft

Jim MacLennan — Wed, 07 Jul 2010 03:09:27 +0000

All projects should have a clear objective, a practical plan,
and an understanding of the costs and benefits to get the thing done.

Easy to say, but a lot of project teams struggle to crisply and clearly define specific business benefits. One way to move the process forward would be to have a clear understanding of the types of business benefits you might claim.

Hard benefits come from firm commitments to make measurable differences in the amount of revenue generated or savings realized. When claiming hard benefits, the business manager will actually increase their revenue budget (or reduce their expense budget) because of the impact of this project.

Real, measurable “Top Line”: volume / revenue growth
- “I will be able to sell 10% more …”
- “Market share will grow 2% …”
- “This new product line will generate 5MM pounds incremental sales …”

Real, measurable “Bottom Line”: cost reduction, FTE reduction (people)
- “I will cut 10% of my use of electricity …”
- “I will eliminate two FTEs [positions] …”

Your guess is as good as mine ...

Soft benefits come from the strong belief of the business manager that the benefits will be there – but they may be hesitant to make changes to their budget. The hesitation may be there because there is some risk of attaining the benefits from other factors; or, the savings are based on unsubstantiated estimates (i.e. “educated guesses”, aka onager heuristics). When claiming soft benefits, the business manager may not necessarily increase their revenue budget (or reduce their expense budget), hedging against other factors.

An important type of soft benefits is Cost Avoidance; a project that automates a manual process could allow the company to increase the number of transactions processed without adding incremental headcount. You haven’t reduced the operating budget, but you have enabled more productivity without additional cost – this is cost avoidance, and it is an important soft benefit.

Benefits that are subject to risk could be dealt with by making them soft benefits; if the manager is confident of the magnitude of the savings (”… this will cut 20% off the cost …”) but not of the likelihood of the savings (”… if everything goes our way …”), then you should call the total amount a soft benefit.

Anticipated “Top Line”: volume / revenue growth
- “I will be able to sell 10% more, as long as …”
- “Market share should grow …”
- “This new product line gives us a leg up on 5MM pounds incremental sales …”

Anticipated “Bottom Line”: cost reduction, FTE reduction (people)
- “I will cut 10% of my use of electricity …”
- “I will eliminate two FTEs [positions] …”

Anticipated “Bottom Line”: cost avoidance
- “… this will allow me to process three times the volume …”
- “… this will eliminate downtime …”

Productivity – Many systems projects involve automating manual processes and/or streamlining overly complex processes. Productivity is increased when it takes less time for fewer people to generate more work and more results.

Productivity benefits are quantified as a reduction in the total number of effort-hours per month required to perform a task. We often speak in terms of full time equivalents, or FTEs; to keep the math simple, one FTE is about 2000 hours of work per year.

Productivity is a soft benefit because we do not always remove people from the work force when implementing productivity improvements. Typically, the aim of any automation is to free people up to do other process management or analytical tasks. Note, however, that you can turn productivity into a hard benefit by reducing either overtime or headcount.

Note also that it is difficult to establish a common and fair hourly rate for a worker, due to many factors (including job type and geographical wage rates). For this reason, it is sufficient to express productivity in terms of labor hours saved.

Next: Marching down the P&L and the Balance Sheet

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: budget, business benefits, cost, cost avoidance, finance, Productivity, revenue budget, total cost of ownership

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Calculating the Business Benefit of Effective Training Material (4 of 4)

Jim MacLennan — Mon, 21 Jun 2010 01:36:40 +0000

In previous notes, I’ve written about the importance of training and, by extension, effective training material. It’s a common requirement in many organizations …

Click for the original ...

… well, actually more of a “nice to have”, am I right?

Truly effective training material is difficult to create (at least, to create material that does the job), and difficult to share. Solid, effective training material is easy to recognize – it typically falls in to the “I’ll know it when I see it” category – and the inherent value seems obvious to most; how come so many businesses trim their training budgets and underemphasize these all-important deliverables for their projects?

Part of the problem may be the difficulty in identifying a tangible business benefit. Most projects are subject to some cost-justification pressures, and when hard-dollar business benefits are tough to identify, the project costs must be cut. Unfortunately, this typically sees cuts in time and resources for full system test, training material and knowledge transfer.

Yes, you heard me – “testing the system” can be treated as a “feature” that I choose to omit from a given release …

Show Me the Money

But is it really that difficult to identify real business benefit? Let’s walk through this little thought exercise …

The best way to train someone is to dedicate a knowledgeable person with them, and walk them through the various tasks / operations step by step, one by one.
To replicate that level of TLC, a typical project requirement would be two hours of dedicated trainer time per end user.
Factor in travel time and other things, and you will probably get at most 3 people trained per day per trainer.

So, for an end-user base of 100 people and two trainers, figure on chewing up a solid month of calendar time, and devoting two trainers to a grueling schedule. And, for many companies, there will be some travel involved – that will just stretch everything out.

An excellent way to slash the time required would be to spend a good, solid week of one person’s time to create some training material. Step by step instructions, samples, screen prints, video walk-throughs – you can do a lot with 40 effort hours. At this point, you can ask all 100 people to take this two-hour, self-directed training class some time over the next week.

You’ve cut out all travel expense …
… no need to take two employees off the line for two months to train
… and you’ve slashed time to deliver in half (at least).

Note that I am not counting all sorts of miscellaneous costs like travel, paper, lunches for the classroom … nor am I counting the value of having ready access to the training material for follow-up training.

I know I can tweak the math by doing this stuff in a classroom setting, and spend 10 days (not 100) of the trainers’ time, teaching class sizes of 10 students each. However, that is not a fair comparison, because the time, attention, and immediate feedback that each student receives would not compare to a well–structured, well-written training piece. In addition, the well-written document can be called upon on-demand over the following months, when the original trainers are back on their regular jobs, and the expected / normal level of staff turnover occurs.

Now, since there is such a great payback in this story, it’s absolutely worthwhile to get very good / effective in creating / structuring really effective training material. The cost is typically reasonable, and the training material keeps giving and giving …

Golly, those Business Benefits are hard to define …

Interested in more methods for calculating business benefits? I am putting together a tool and a method for getting to the business benefits for any project – let me know if you are interested!

Previously …

A “New” Critical Requirement for Business Projects
As we continue the deep dive into questions like “how do I get information required to run my business?”, we inevitably get to training …

Capturing Knowledge, and Making in ‘Findable’
If the training material is difficult to locate, and people can’t find it to use it – it might as well not exist.

Capturing Knowledge, and Making in ‘Transferable’
If a knowledgeable trainer is not available, and the training material does not “stand on it’s own” – it might as well not exist.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: business benefits, cost, findability, knowledge transfer, Training, training material

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Business Proposals and The Lesson of Jabberwocky

Jim MacLennan — Mon, 29 Mar 2010 00:10:00 +0000

Twas brillig, and the slithy toves ...

When someone asks my opinion on their writing, I’ll get fairly detailed; I’ve noted in the past that there is a lot of power and influence in the written word, and it’s fairly important to get it done well, or your project proposals just never seem to get off the ground.

This particular proposal suffered from a lack of direction; it didn’t take the reader (the decision maker) through a clear progression. Admittedly, the subject matter was a bit technical and mildly complex; even though this was a proposal for internal IT eyes, the prose didn’t flow, and did not help the reader understand what we are asking for, and why.

I suggested that the subject matter – highly technical services – shouldn’t impact the difficulty we were having in getting the basic idea across. A good way to validate the structure and effectiveness of a written proposal might be to show it to your high school or college-age children. The document should make a cogent argument that a reasonably intelligent person should be able to understand; it doesn’t matter if they understand the technical specifics!

I saw Alice in Wonderland a few weekends ago, and noted that the plot takes a lot from Jabberwocky. Now, I’m not a “Carroll scholar” by any means; I recognized it, was even able to recite most of the lines – but I blame my high school English curriculum. It was [way] back in my sophomore year – we spent a week or so deconstructing the poem, and the teacher pointed out that you don’t need to understand exactly what a jabberwocky is, or what a vorpal blade looks or sounds like – you can identify these foreign-sounding words and concepts (a Jabberwocky is a noun, vorpal is an adjective, and snicker-snak is an alliterative, sounds-like description) in context. You understand the story and the drama in the poem without completely understanding the specifics in the dialog, because it is a well constructed story.

The same goes for this technical proposal. This should be an effective writing piece made to educate; a business proposal, arguing for action or caution, must make an effective argument. The document’s structure has much to do with the success or failure of the proposal – technical details are for a secondary, deep-dive pass, but the basic business argument should be apparent.

Historically, we have seen X
Recently, Y has changed, to Z effect (X is worse than before)
If we take action Q, we can get back to X.
Q will cost J dollars, and bring K benefit within L months

Currently, we are at The As-Is.
Future state will be The To-Be.
We can get there from here if we execute The Action Plan,
at a cost of A dollars and B people’s time over C months.

External Event Alpha requires us to be at future state Beta
We have two alternatives:
- Plan 9, which will cost 10x and require 1 dedicated Framistat – and be delivered in a year
- Plan 10, which will cost 100x and require 5 dedicated Framistats – and be delivered in a month
Due to Factor Gamma, we recommend Plan 10

As a good common sense check for your writing effectiveness – run it past someone outside your team, someone with solid business sense but not necessarily a deep grasp of the details. There are many patterns for laying out persuasive arguments; learn them, before someone takes a vorpal blade to your next project plan.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: abstraction, Alice in Wonderland, benefit, buzzwords, charter document, communicating complexity, communication style, project, proposal writing, vorpal blade, writing

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

If I Told You a Fractal Solution, Could You Change the CEO’s Mind?

Jim MacLennan — Mon, 07 Dec 2009 03:22:00 +0000

As the new year approaches, debates over the “value” of IT and business projects intensify; it’s not holiday stress, but the excitement of the approaching New [fiscal] Year. Lately, I’m hearing more about the struggle to quantify business value, especially when selecting those few projects that will “make the cut”. We will definitely iterate on our scoring framework, adding a cost / benefit template to facilitate more apples-to-apples comparisons between projects (yes, don’t scoff – it is possible – more in a later post …)

However, I think there’s an interesting vision in some people’s minds; a sort of value-optimization Utopia where, even with hundreds of project ideas on the list, the executive team has the insight and ability to select the best projects and fund them appropriately - as long as they all have business values assigned.

I don’t think assigning a value to every proposal is realistic, and certainly not something to aspire to – well, not directly anyway. There are a number of significant hurdles to deal with – the reluctance of people to commit to hard benefits, the lack of suitable productivity metrics for new technologies and methods, and the difficulty of communicating innovations to those who didn’t think it up on their own (ie. close the patent office, we’re done).

Yet, even if you did address all of those problems, and could easily measure impact and communicate effectiveness on 300+ terrific project ideas – how could anyone to claim the ability (or the time!) to rank such a list from “best” to “worst” (or, since I don’t propose projects are bad to begin with – “most best” to “least best”)? Truth is, they don’t – most of the business leaders I’ve worked with have no interest in looking at 300 projects, and would be a tad perturbed if I tried to get them to peruse such a list. Do you appreciate it when your teams bring a thousand problems for you to sort through?

Rules of Thumb

Most people have a favorite way of eating their elephants. Yes, one bite at a time – but where to start? How to carve?

Deliver Small, Iterate, and Evolve: The agile among us would focus on short-term deliverables with small measurable steps to make incremental improvements. Speed and iterations will drive the quality and help focus on those areas of work that have the most short-term promise.

Focus on the Big Rocks: The biggest and toughest problems – or the projects with the most benefit – are sometimes so daunting that they intimidate us into dealing with “the easy stuff”. Clear your calendar and tackle these larger opportunities first, else you’ll never get to them.

Focus on the Constraints: Understand which resources are keeping you from launching multiple projects at once. These are typically people – in key positions, with monopoly knowledge. Simplify things by prioritizing their projects first – but strongly consider launching efforts to remove the constraint, by having them document, train, or automate their knowledge.

Practical Problem Solving

As I proofread this post, it sounds like a checklist for common sense; no surprises, just a different level of detail depending on the organizational level you are speaking with. It’s important to understand the fractal nature of business challenges; no matter where you stand in the organization, the number of items on your ToDo list (and/or the number of challenges you are juggling) is roughly the same. The sooner you can put yourself in the other person’s shoes, and speak to them at the level of detail they (not you) need – the more effective your conversations will be.

Besides, they’re paying you to solve problems, not define them.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags: agile, benefit, business benefits, corporate information systems, cost, executive team, fractal, Inspiration, PMO, portfolio management, project prioritization, Science, TCO, total cost of ownership, upper management

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Business Benefits of Social Networks Exist, but …

Jim MacLennan — Sun, 26 Apr 2009 04:10:00 +0000

When I see / read articles like this, or hear the breathless claims of vendors, pundits, and True Believers, I’ll privately chuckle to myself. All of this stuff – social networking, collaboration, and innovation – are 21st century takes on good old Knowledge Management (KM), circa 1998.

Do these sound like presentations from your recent Enterprise 2.0 conference?

Managing Cultural Change to Create a Knowledge Sharing Environment
Effectively Managing Information Overload in the Information Age
Information Content and Security in Document Management Systems
Using Technology and the Project Management Workbench to Accelerate Product Development Efforts
Shifting the Burden of Knowledge Sharing to All Employees

I dug up an old copy of the proceedings from a 1998 KM conference; if I did a global text replace of “Innovation” for “Knowledge”, I could probably get a bunch of folks to sign up today!

Ok, a little sarcasm is fun, but once you realize the similarities, there are other parallels with 1990′s KM efforts – not the least of which is the identification of business benefits. Anyone involved with projects back then can testify to the difficulty in predicting hard benefits – clearly quantifiable impact on top line or bottom line, derived in a predictable, measurable manner. Sorry, it just didn’t work out that way for KM – and it won’t for Social Networks, either! The hype cycle will prevail …

Hard Benefits of Social Networks Do Not Exist, but …

Why do people insist on expecting a hard business benefit from social networks, or a payback from a project to implement a funny-sounding technology (wiki/blog/tweet) inside the enterprise? Has anyone ever gotten a quantifiable business benefit from participating on Facebook, LinkedIn, mySpace?

Well, yes, actually – plenty of folks have connected with friends / colleagues, collaborated on business ideas, come up with innovative new approaches – actually monetized all the goofy sounding tools. I myself have written about successes, and have made connections I could never have anticipated. Heck, the old KM conference guide has a couple of case studies as well.

Ah, but do you see the pattern? Business benefits are not predictable, they are always opportunistic and anecdotal. Success is characterized by stories of the home runs (rarely accompanied by comparable stats on strikeouts, by the way). You can’t implement a social network within a company or a group, and predict how much and when the profits / savings / growth with start rolling in. You are setting up an environment of opportunity – nothing more.

When I hear people talk about business value or business return of social networks as if they could predict it, I cringe. They’re trying to apply financial controls on something that’s governed by chance – you can’t do it. The incorrect assumption is that you can control good luck – but you can tweak your chances.

Active networkers know – I’m talking about people that have been networking for years, when connections were made face to face. Career coaches would exhort us to get out there and build our professional network – make the office visits, get on their calendar, develop some connections. You have no idea what could happen from any one connection or conversation – nothing might happen or something might happen – you trying to make your own luck.

What is it they say, luck is 10% inspiration and 90% perspiration? Social networking is just automation for some of that 90%. And benefits will happen – just don’t ask me when.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags: Blog, business benefits, business value, collaboration systems, conference, Facebook, innovation, Inspiration, Knowledge Management, LinkedIn, networking, Social Media, Social Networks, Web 2.0, Wiki

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Five More Realities for Driving Business Value from Technology

Jim MacLennan — Thu, 31 Jan 2008 04:26:00 +0000

Dennis McDonald’s recent post listed Ten Realities of Managing and Using Technology to Generate Business Value. I think a few of these items need some elaboration …

Implementing a technology based solution without understanding the costs is a big mistake
Just because you adopt a new technology doesn’t mean the users of your old technology will disappear overnight
Many technology based projects are mostly about business and process change, not about technology
If you’re not in the technology business, you probably should leave developing new technology to others

… and here are five more Realities to add to the list …

Click to enlarge ...

Getting rid of old technology should be a requirement: Woe to the IT department that does not manage the growing complexity of their data center. You can’t keep adding the next server, interface, or application without consciously remembering to turn off and decommission the technology it replaces, else you’ll never get out of the death-spiral of monitoring and patching obsolete technology that stopped delivering value a long time ago.
“Standing pat” is a valid alternative: It may sound like heresy, but when faced with large recurring maintenance fees or hefty upgrade project, IT must always present the do-nothing option – especially for companies strapped for cash in the short and/or medium term. The business may choose to stop paying maintenance on the mission-critical software, but that (typically) does not mean they have to turn it off. It just means no more patches or telephone support, and hefty back-maintenance charges if they ever want to upgrade in the future. There are many business scenarios where this would make sense – you must always provide it as an option, else you will be perceived as a techie, not a business-person.
Automate a mess and you get an automated mess: Not sure where I first heard this, but it’s a terrific way of saying that there ain’t no silver bullets. This stuff isn’t magic – if the underlying business process is complicated and counterproductive, piling on some technology will just make it worse.
The objective is to solve a business problem, not to implement technology: Focus on the end, not the means; if I can do something without technology, I should run (not walk) to that solution. People say things like “we need to upgrade our transportation planning system”. What does that get me? An upgraded transportation planning system. Better to say “we need to implement regional versus local transportation planning, to aggregate spend – and we will do that by upgrading
our transportation planning system to get access to features that make this easy”.
Given enough time and money, I can make a computer do anything: Any developer worth his salt better say that – the real trick is to Pareto the requirements, and figure out if I can do 20% of the work, and get 80% of the benefits.

The best use of technology in business minimizes the complexity – which may mean reducing the technology …

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2008. | Permalink | No comment |
Post tags: business benefits, business value, investment, TCO, Tech Management, total cost of ownership

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Measuring and Reporting IT Value (2 of 2)

Jim MacLennan — Wed, 21 Nov 2007 05:32:00 +0000

My last post generated some interest, so here’s the rest of the examples.

Last time, I wrote about the simplistic approach to measure and report on IT value:

Is your IT group working on the right things?
Are they working on the right things well?
Is your IT spend comparable to industry norms?
Is your IT spend comparable to other measures of company performance?

A bit more detail … balancing quantitative and qualitative …

(Quantitative) To make sure you have business alignment, the strategic objectives of the company should be identified, and all projects / IT investments should be aligned with those objectives. Track the relative size of spend for each of the objectives, and make sure it matches with your priorities (sample in previous post …)
(Qualitative) Regularly (i.e. minimum once per quarter), review this aggregated spend with the business. Conversation around relative priority can easily segue into a “customer satisfaction” review.
(Quantitative) Check with industry groups or research firms to get an idea of the typical measure of IT as a percent of revenue (ex. IT budget of 1.5% revenue is typical for manufacturing firms). Be sure to clarify if this includes depreciation expense or not.
(Quantitative) For many companies, revenue isn’t directly impacted by IT as much as Cost of Goods or SG&A. It may make sense to compare annual growth rate of year IT budget to your company’s gross margin.

Here is a sample graphic showing what I mean …

Click to enlarge ...

For this fictitious manufacturing company, IT costs seem to be in line with industry norms – comfortably less than 1.5%. However, IT costs are growing faster than revenue – not a good sign.

Worse yet – the second graph shows us that our gross margins are flat to declining – more bad news. If I was the IT director at this company, I shouldn’t be surprised by some serious budget pressure going into the new year.

Again, these are made-up numbers to illustrate one scenario. There are also things one can do with the graphs to hide problems or inflate good results – but the CAGR statistics tell the real story, so make sure you know how to calculate growth rates!

Another key point; generally speaking, for most manufacturing companies, IT investment is not as clearly related to revenue as it is to gross margin. In fact, for some companies, revenue increase/decrease is often driven by forces outside of IT’s influence!

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2007. | Permalink | No comment |
Post tags: budget, business conversation, company performance, cost, depreciation expense, gross margin, manufacturing, SG&A, value

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Measuring and Reporting IT Value (1 of 2)

Jim MacLennan — Sat, 17 Nov 2007 05:00:00 +0000

This started off as a quick response to a question on LinkedIn Answers … but I got on a roll …

Here’s a simplistic way to measure and report on IT value:

Is your IT group working on the right things?
Are they working on the right things well?
Is your IT spend comparable to industry norms?
Is your IT spend comparable to other measures of company performance?

A bit more detail … balancing quantitative and qualitative …

(Quantitative) To make sure you have business alignment, the strategic objectives of the company should be identified, and all projects / IT investments should be aligned with those objectives. Track the relative size of spend for each of the objectives, and make sure it matches with your priorities … here’s a sample (I even slipped in some sparklines)…

Click to enlarge ...

(Qualitative) Regularly (i.e. minimum once per quarter), review this aggregated spend with the business. Conversation around relative priority can easily segue into a “customer satisfaction” review.
(Quantitative) Check with industry groups or research firms to get an idea of the typical measure of IT as a percent of revenue (ex. IT budget of 1.5% revenue is typical for manufacturing firms). Be sure to clarify if this includes depreciation expense or not.
(Quantitative) For many companies, revenue isn’t directly impacted by IT as much as Cost of Goods or SG&A. It may make sense to compare annual growth rate of year IT budget to your company’s gross margin.

(I can post examples for the last two if there is interest – please let me know)
(Update – check out the second part of this article here)

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2007. | Permalink | One comment |
Post tags: budget, business alignment, company performance, LinkedIn, manufacturing, SG&A, sparklines

All articles, blog entries, and other content on this site are licensed under a Creative Commons License