How to sucessfully introduce/initiate IT projects in a non-IT org.?

Question

I've been working in an old-fashioned company that has a small IT department and zero experience with project management. I'm having trouble finding the right approach to present IT solutions, transform these solutions into projects and manage them in a way the stakeholders will understand.

The main trouble at the moment has been that every project I propose is not well-received, since it will cost money, time, resources and people will need to be trained in their own jobs (e.g. if I want to introduce a Help Desk solution to our spreadsheet-oriented Help Desk dept.) - and no one likes learning how to do their own job again.

What I'm trying to do presently: show the solution and why it would be good; estimate how long it would take to implement; how many resources the project would need; and how much it would cost (person/hour + software costs + etc). But I'm having trouble to exemplify how much we would "profit" in the long term. Remember, these are non-TI people, so arguing that (e.g.) it's more secure having databases than spreadsheets is not a strong argument, and I don't know how to make it appear strong, so I'm trying to talk in money.

Example: employee A does task X in 2 hours, which is very long, with an IT solution he would take fair less, but I can't precisely estimate he will take 30 minutes - if I could, it would be easier to present the long-term profit to the stakeholders in financial values. He could take 30 minutes, or 15, or 1 hour and 10 minutes - all would present benefits in the long-term, financially speaking, but I can't be precise on how much.

What would be the best way to approach this scenario? Introduce and initiate IT projects successfully, all while communicating the benefits from these in a way non-IT people can understand.

Answer 1

In my opinion, you need to climb higher and talk about your company's standing in its competitive market. Don't sell the IT solution; it is only one of the many enablers to a competitive business. Instead, take a look at how well your company is doing in the market place, its revenue capture as compared to total capture, its sustainability in this very dynamic, technically oriented environment, its performance over the last x number of years, threats of new entrants--both companies and products--ability to innovate, agility, flexibility, etc.

The story begins with your company's true outlook in the next year, next five years, next ten years. If that story looks bleak, then you now have a compelling reason to change and the leaders of the company can sponsor such a change. The cost of change is much less than bankruptcy and closure.

But as I wrote above, the IT solution is only one enabler of likely many that have to evolve to its next version of itself. Do not become IT centric; instead, incorporate IT solutions along with other solutions that enable capability.

You cannot sell anything without a need or want. Establish the need, then sell.

Answer 2

This is a problem in estimation, which is very much a PM skillset. Wish I could provide a good general answer, but the best I can do is pick at a couple of items you mention.

Since we're talking about estimating, let me mention a couple of principles:

• Methodology is more important than accuracy. I've (almost) never been questioned on an estimate if I provide the supporting methodology. THe one time I was questioned was when my estimate was 10**6 larger than the bosses estimate; I showed him the underlying methodology and offered to adjust any factor he found unreasonable. They went with my estimate. Build the spreadsheet identifying your assumptions and show the math.

• PERT - PERT (or more properly PERT estimated time) is magic; if you include PERT in your estimate, everyone assumes you know what you're talking about.

• Security - this is a fascinating research area; I'd recommend you consult the Society for Information Risk Analysis - they have multiple ways to measure security. Most of their methodologies are too complex for simple needs, but they have given me a lot of ground for thought. There are a couple of common ways to measure security:

• Breach cost - the Verizon Data Breach Report provides examples of real world breaches, which permits you to provide some estimates backed by solid data. You can pick your favorite cost/record and use the VDBIR to identify an industry/market segment similar to your own and predict the likelihood and impact of a breach.

• Replacement cost - if you were attacked, what would it cost to recover? The minimum cost is the cost to restore from backup. If you have records of security incidents from the past year, use those costs. (if not, why not?) VDBIR provides values for estimates.

• Technical debt - this is one of the coolest ways, but you've got to be mature. Put simply, once you know you have a flaw/vulnerability estimate how long it will take to fix the problem (ask each programmer to estimate independently and PERT the lot).

• error cost - how many errors did the people make with manual processes? Most errors are security relevant, but most institutions keep better record of errors/quality control. You can use the quality control/ error information as a proxy for security. (not a 1:1 proxy, but the point is that if I can reduce errors by X % then I will reduce security relevant errors by X%).

• Audit cost - how much longer will your next security audit be?

I could go on and on....

How much shorter - again the general principle is to ask the worker, and then PERT the resulting estimates. See if you can get permission to do a timeboxed mockup of the new process and test it. If they're willing to grant you 40 hours for a mockup & test, you can give them real numbers.

Summary and last thought. If you can get permission for one, then make sure you capture lessons learned statistics, etc. You want to finish with, "You gave me 40 hours to make this work; the resulting process will save you 1 hour a month, which will pay off in 3 years. Find me any other investment that will pay off that fast." or something like that.

Other resources that may be helpful: Examine the incentive - I think his observation that change must address a problem that the stakeholders believe to be important is relevant to your problem.

Answer 3

Make a list of all of the potential benefit areas. For each, make an estimate of benefits if you can, in financial terms, over (say) a two year period. Something like "This will save $1,000 dollars per year so over two years it will save the company $2,000 dollars". That's the easy bit.

The more difficult - yet important - bit is where there is no obvious financial benefit. Here's where you need to get creative. Don't create fantasy numbers, but identify non-financial benefits - such as "If we do this, it will allow us to answer helpdesk calls 5 minutes faster". Look for a benefit for the business for this - "This will allow the sales department to deal with 3 more customer calls per day". Ask the boss what that would be worth in increased revenues and profits. Then you have an answer.

If that still doesn't give you what you need, see whether there are other benefit areas. "This bit of software would give the company an opportunity for publicity in the trade press. What is that worth?" - It may not give a direct benefit, but if the boss would pay for that, and you save that cost - voila!

Then add up all of the results and discuss them with multiple stakeholders before formally presenting them.

Sell the benefits first, then estimate the costs. Once you have the support for the project, it will be much easier to get the business to buy into the necessary investment.

Answer 4

Unfortunately this kind of process automation is not a good candiate for IT showing a return on investment.

In fact larger companies tend to use manual labour over automated IT solutions because they are cheaper more flexible and go wrong less spectacularly.

If you are looking for opportunites to introduce an IT project there are a couple of drivers.

1 : regulation. Lots of legal responsiblities that may fall on a company require documented processes and exensive record keeping. An IT system which ensures the process is followed, records the process being followed and reports on it can satisfy those requirements better than a manual process.

2 : New digital markets. Stuff your company isnt currently doing but other companies are. Do you have a website? a mobie website? An app? A mailing list? What about social media? SEO? etc etc all these things dangle the carrot of new untapped profits and require technology.