Member Q&A – How Can I Keep the Execs From Derailing My IT Funding?

Member Question
I often find that senior people in my organization don't really understand the business implications of our infrastructure projects. They know there are weak points that need to be addressed, but they reason, why spend on those areas when you can get more "bang for the buck" investing in new business areas instead? I feel like they're constantly trying to derail funding for these programs. How can I prevent this? The obvious answer is that you need to "do some stakeholder management" to win them over, but what if you can't get that close to them, let alone face to face?

—Greg, Project Manager

Greg's plight struck a familiar chord with many of our members. Here's what they had to say.

Write a whitepaper - If they won't listen, maybe they'll read ...
Emphasize the cost savings
Apply risk management to demonstrate true value
Do a Cost-Benefit Analysis, and know when to stop talking!
Lead by example
Speak their language - Money talks
It's a zero sum game - show them the true cost tradeoff
Business Continuity, thou art a jewel
Make the risks visible - everywhere!
Try consulting - Sometimes it feels like you're banging your head against the wall because you are
Put your project sponsor to work
There are no IT projects, just business projects
What's your business case? - Are the infrastructure changes really a business requirement?
What's in it for them?

Jim Wilson, Advisory Systems Engineer for County of San Mateo, California

Since you say that you can't get close to, or even face-to-face with the stakeholders, I would suggest that you prepare a white paper on infrastructure improvement for the organization. In your paper, detail the improvements needed, explain why they are needed and what could happen if the improvements are not made, and show what impact that would have on the business—certainly there will be a cost to the business if the improvements aren't made. You need to show (and don't be afraid to include diagrams in your paper) that these people are being penny wise and pound foolish—without telling them directly that they are. They can pay a little now, or they can pay a lot more later. If you can support your points with some statistics, include them. You need to show them the improvements are needed, and that they are basically playing Russian roulette in their putting off improvements.

At the conclusion of your paper you might propose either a one-time capital project to make all needed infrastructure improvements at once, or an incremental approach of several smaller projects that would accomplish the same results over a reasonable time period. You might propose that each project contain a mandated percentage that goes to infrastructure improvement. They may spend a little now, and get less "bang for their buck" as they see it, but they will pay far less than they would if they continue to ignore the problem, only to have it rear its ugly head and bite the company hard.

Once you finish your paper, review it with a fine-toothed comb and have others you work with also review it. You want this thing to be the most professional paper you can produce. Make sure it is clear and concise and not too lengthy, but not so short that you don't make your point or fail to impress upon them the urgency of the matter. Also, make sure it has a nice cover that looks interesting and will entice readers. Once it's ready to go, distribute to all the stakeholders and include your own management. If there are others who are above these stakeholders that control finding, make sure they get included in your distribution as well.

If, after reading your white paper, they continue to resist making those improvements, you should take it to corporate management. Find someone who understands risk management and see if you can get upper management to mandate the improvements. If upper management is unwilling, you've done your best. The only thing you can do then is to continue doing your best work as usual, try evangelizing for the cause... and wait for the beast to bite. Hopefully it won't come to that.

Good luck.

Summer Diengott, formerly an Engineering Project Manager at Walmart.com

Three years of experience as an Engineering Project Manager taught me that if you convert everything to money, it will be heard (or not heard - if it turns out it's actually not important).

Typically, infastructure and engineering projects benefit themselves through Cost Savings - something most business users are interested in hearing about.

• Maintenance Projects - measure the cost saved in lower effort for all future development
• Upgrade Projects - measaure the cost savings in ease of future transitions
• Automation of Manual Stuff - measured in time saved

etc. etc. etc.

Director, Project Management at a major food services firm

When it comes to justifying projects and prioritizing them there are a number of factors that need to be considered. Business value and financial payback is one that everyone uses however there are others and these provide mechanisms to justify projects with no obvious financial payback.

The approach that I have used successfully is an extension of standard risk management practices in project management. You look at the risk of an event happening (say a 10% chance that it will happen in the next 2 years). You determine the business (and financial impact) if that risk event occurs (say 10 million dollars in lost profitability). The financial value of that project is then 10% times $10 Million or $1 Million. Some projects with no benefits are to mitigate risks that, if the risk event occurred would result in the failure of the business.

Many infrastructure projects are required to mitigate risk. By translating these into financial value they can then be assessed and validated based on financial metrics and then prioritized on a direct basis against projects that improve profitability.

Denny Brian of Decisive Analytics Corporation

In past experiences with a major regional telephone company, when funding became an issue, the one thing that always worked for me was to do a cost-benefit analysis. Numbers seem to be easier to understand than logical discussion. I once had to justify spending almost $1M for a fiber installation. I prepared a multi-slide presentation on why we should spend the money but when I got to the slide that showed the cost vs. the revenue, the VP said, "I don't see an issue here. Do it!" Although I still had about a dozen slides to go, I gathered my slides, thanked the VP, and stepped away from the podium.

I know when it comes to budgets, people become very territorial. What success I have had probably came from "lobbying" stakeholders individually and getting verbal support before going into any budget discussions. It is very time consuming to do it that way, though, so I guess you have to decide ahead of time if it is worth the effort. Also, individuals are most concerned with their own projects—what's in it for me?—so if there is any way you can show a benefit to their project by supporting your request, bring that to their attention.

Randy Englund, Project Management Consultancy

To answer Greg's question, a best practice for every organization is to decide upon a set of "strategic buckets" that, when accomplished through projects, helps the organization meet its agreed upon goals. New business areas would be one bucket, infrastructure projects another, perhaps current product engineering is another. Decide upon a desired mix across buckets, a mix that provides a competitive advantage and meets organizational commitments. For example, 50% of resources to new business, 30% to CPE, and 15% to infrastructure. (Leave 5% uncommitted to handle unforeseen opportunities.)

Therefore, 15% of the organization's total budget is earmarked for infrastructure projects. Greg's projects then only have to compete against other infrastructure projects to get funded, up to the 15% limit. Projects within the bucket are prioritized according to agreed upon criteria that assess how well projects contribute to meeting organizational strategic goals. Greg needs to know the criteria and do an exemplary job presenting his project to get the most "bang for the buck" within his category.

This process is all very well and good but still begs the question, what can Greg do if the system is not set up this way? My suggestion is to act as though it is and try to make such a process work within his area of purview. Push upwards to ask management to do their part. Suggest a process that is consonant with his organization's culture. Provide answers that envision how such a process contributes to greater success. Implement a scaled down version of this project portfolio system within his areas of responsibility, and make it work. With small wins under his belt, demonstrating greater effectiveness and efficiency, get the attention of other stakeholders who are hungry for similar performance gains. He is then in a position to describe how this system of strategic buckets and desired mix can benefit the whole organization.

The process requires that managers work together to discuss, agree upon, implement, and update a set of goals, buckets, mix, and criteria. This is probably the hardest part and may require outside facilitation to make happen.

The point is, DO SOMETHING. Don't just complain about it.

"Marius"

The higher up in an organisation you go, the more people think in terms of money (the bottom line).

As you go down the ranks, thinking in terms of function (and common sense) appear again.

I would recommend that Greg approaches the issue in terms of cash, i.e. he should define his needs in terms of life cycle costs and ROI, not in terms of function.

If he speaks their language they will listen.

Julia Gubina, a Six Sigma Project Manager in Russia

Yes, stakeholder management is the thing, but try to support every of your explanation to them by facts and figures. Are the senior people (meaning 'managers') ready to invest money into the business development from one side, and lose (usually) quite a lot of money because they didn't improve the 'inside part' of the organisation? It's almost a zero sum game.

In this case Change Management attitude is the most difficult part of each project. When my project group organized a meeting for decision-makers and presented to them real figures obtained from the process, we succeeded in changing their vision a bit. Still, if they want to increase the revenue by business development [it's 95% certain they] don't want to lose money.

If your project has clear deliverables from some financial point of view - you are on the right way to discuss it with those senior people.

Alasdair Elder, IT Programme Manager in the UK

How about asking the Senior Management to review their Business Continuity plans and find them discovering that most of the infrastructure is there to support the business – day-to-day.

Without it there is no "business as usual" and the core drops out. What happens to the cash flows then?

Getting a voice on "top" table can be difficult sometimes. However with Business Continuity and Risk Management there should be enough executives around that will listen sympathetically to the need to continue to fund (IT) infrastructure. How about proposing an item for the agenda at the next governance committee – entitled "Our Reputation for Keeping the Lights On"?

Perhaps Greg's firm is enjoying a history of solid availability of it services - then it will look odd. The odd breakage, or two, helps enormously to bring the need for solid services into sharp focus. Then the cheque books fall open.

Scot McLean

This is always a problem, infrastructure costs increase the cost of doing business and must be passed along when estimating a new project usually reflected in what is charged for labor. However if a resource that is required for a project is not available or is not adequate in some way this is a risk. Identifying the risk and including it in the project plan is one way to get visibility on it.

As Project Managers we tend to focus on execution, however we can't execute the project if another company or team was perceived to have provided a better value to the customer and are doing the project instead of us, it is a competitive world after all. The job of the business end of the company is to balance having the necessary resources with the costs of doing business. This tends to create a us and them mentality, when in fact we have the same goal; get and execute well the project. Identifying lack of infrastructure as risk in the project plan helps communicate to management the consequences of their decisions.

Dana Weber, formerly with an oilfield service company

Greg,

I feel your pain, and in a corporate environment I too tried to champion projects to increase efficiency and eliminate hidden mistakes that were costing overhead. I gave up, after 16 years, because until the idea is conceived by the top managers/exeutives, it will not be supported.

Then, when they have the "New, Revolutionary" idea you have been pushing, they will promote one of the "good old boys" no matter how unqualified, and back him up with all their influence, to accomplish what they kept you from doing.

Sorry to be realistic, but I am now consulting at twice the income, dealing with folks that are looking for ways to improve their profits through internal efficiency.

Phil Spencer, Project Planning and Administration Manager, Orlando Sentinel Communications

Do you do a cost-benefit analysis on all your projects including infrastructure projects. For example if it is a project to create redundancy in your core router you would need to gather some statistics on past failures and couple that with the cost of loss revenue should you have a complete failure.

I must admit that I can't say we do it for every project (though we should), but we have done it for specific infrastructure projects to show that there is a positive return on the investment.

While the "bang for the buck" may be adding revenue, the infrastructure projects are key to maintaining current revenue. If you can paint the picture of how much revenue you would loose for an outage of X time and the likelihood of such an outage happening in the next year with the current infrastructure then you can probably calculate a return that would rival their projects. Of course, if you can't show that then it may be that you don't need to do the project and simply respond to the situation when it happens.

If it's the case that Greg is the consultant buried in the project then I think it isn't his issue but the Project Sponsor's issue. Greg may be the one to pull the information together, but it has to be the Project Sponsor who gives Greg the support to ask for the information and help him make his case.

John Burke in the UK:

When we used to face this problem, which doesn't occur now, we found the magic words and needs of 'Business Continuity' were of great help.

Whilst justifications such as equipment renewal, technology roadmaps, asset recycling programmes, etc help in forming a business case, they don't in themselves add any tangible value to the bottom line.

Instead, use operational risk and Business Continuity and the primary justification—focus on what is the risk to the bottom line of NOT doing the project rather than (or as well as) what value it will bring.

I think they'd be much more willing to support the project if they new what was at stake to lose. And if you can't show what the risk of not doing the project is, then should you be doing it at all??

Over this time we've been able to educate people on the value of the infrastructure and the risk of leaving it behind in terms of investment. I believe that people have now bought in to this on the basis that you can't move forward if the underlying tools aren't in place be it IT infrastructure, legislative adherence, processes fit for purpose, etc; in the same way a train stops when it runs out of track.

There is also greater understanding and focus around Business Continuity now anyway - this later emphasis has happened separately to anything the IT function has done as businesses' generally have an agenda with risk, BC, corporate governance, etc as hot topics (through focus such as natural disasters, terrorism, Sarbannes-Oxley etc). What we've been able to do is link the justification for 'enabling' projects into this wider business context through the concept that there are no IT projects, just business projects.

Alan Douglas at Centennial College in Canada:

The obvious answer, to my mind, is not "stakeholder management," but something more direct and to the point – A business case for the project, outlining, in detail (including dollars and cents impact for those so inclined), the "business implications of our infrastructure projects." If that isn't possible, then it just may be true that it's not a BUSINESS REQUIREMENT. As someone who has to pinch pennies because this Community College depends primarily on Ministry funding -- We don't have the fund-raising mechanics, nor the appeal, that universities do -- I have to constantly remind my staff that the College's strategic and business plans are the drivers for IT's strategic and business plans. If we cannot justify an infrastructure project by relating it to the College's current business plan, the project will die a natural death. With extremely limited funding, we can't afford to initiate "nice-to-have" infrastructure projects, based solely on the desire to have the "latest and greatest" technology. In the College environment, everything we do has to support and improve the "student experience" – from their ability to register, pay and choose their courses online, through improvements to security, privacy, accessibility and reliability of the network and applications, including on-line teaching and learning tools. This is the basis for justifying an infrastructure project -- not "stakeholder management." (Gawd, how I hate that term ... It smacks of "blue smoke and mirrors" sales techniques.)

Kashif Gul Kazi, 360training.com

I got in the same situations and soon found my answer. Mostly senior people do not understand the business implication [of infrastructure projects] and obviously don't have much time. The only way they understand is when you present your material in a good way, starting off the point and then slowly come on to your point.

1. Ask questions with them first (maybe they have a good reason, depends upon their experience).
2. Try to compile their answer on the spot and ask another question while discussing.

My result 1: I have faced similar conditions and finaly found they have good reason to bypass these issues.

My result 2: For some business processes they only got my point when they faced that problem, so keep the solution with you for the right time.

In my experience asking for time to hear your case is "waiting for a lifetime" (as senior people has no interest to hear you on that topic). The best way to start is, start discussion on a topic of senior people's interest and then show them benefits how your case [can] help them, then get them to understand your case in detail but in well prepared presentation format in a short time (no long times, should summarize case in few minutes).

©Copyright 2000-2008 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy