MakingITclear®

Secrets of the Hiring Process: How to Hire

Harwell — Tue, 07 May 2013 11:00:42 +0000

I’ve hired hundreds of people during my career, and my process has been pretty consistent for all of those hires:

1. Decide on the need for a person in a job. Maybe it’s a replacement for someone who left, or maybe it’s a new position that I need for a project or for an expansion of a functional area.

2. Define the job. I’m not a personal fan of job descriptions, but they’re important for recruiting and for determining a fair level of pay. So I’ll usually put one together, sometimes working with someone in Human Resources (HR). In many cases, the job is similar to another existing job, and so the job definition and salary range are based on that other job. Once in a while, I’ll create a totally new position, and then it takes a bit more thought and effort to define the position and its salary level.

3. Get approval for the position if necessary (this depends on your level in the organization). If the position is already in my budget then this is usually pretty easy. Otherwise the position approval will probably be part of a project proposal. If the project is approved, then the positions associated with the project are approved along with it.

4. Look internally. When I’m creating a position or filling a vacancy, I usually have a pretty good idea whether or not there’s someone already in the organization who can do the job — maybe as a lateral transfer or a promotion. I always look internally first to see if there’s someone who would be good for the position. If not, then I’ll look externally. If I’m not sure, then I’ll look externally while keeping one or more internal candidates in mind.

5. Find candidates. There are three primary sources for external candidates: agencies, direct responses from job postings, and referrals. Good agencies have some advantages: they pre-screen the candidates; if you do a lot of hiring then your agency rep already knows the kind of person you like to hire; and they’re able to respond rapidly, sometimes with candidates who weren’t even actively in the job market. Bad agencies are not worth dealing with — they throw resumes at you without regard to quality, and they’re generally a waste of time. Worse, the bad agencies can try to sue you for fees if you hire someone for whom they sent a resume — even if you didn’t hire because of that resume but got a different resume for the person through other channels (I’ve had it happen).

Direct responses come from job postings you put on your company web site or on public job web sites. Sometimes they’re algorithmically filtered by job selection software, but in the years when I was hiring, the algorithm wasn’t very good. Because the filters aren’t as good as the human processes used by agencies, you’ll get a large variation in the quality of the resumes submitted, and you’ll have to spend more time going through the resumes yourself. You might save an agency fee (or pay a reduced fee to a job web site), but you’ll spend more time on the resume search.

Referrals are a mixed bag. It’s worth mentioning to your friends in other companies that you have a specific need, but in most cases your friends will hold on to their good people, and so the only referrals you’ll get are friends of friends who are in a job search, or sometimes relatives of friends. I’ve had reasonable success getting referrals from my own employees, since they often know someone in another company who’s looking. And it helps if your company pays a bonus for employee referrals who are hired; that cuts your agency fees and provides a good incentive to employees. (A Tip: Pay half the incentive when the person is hired, and pay the other half if the new person and the employee are still with the company a year later. That provides additional motivation for the employee to recommend someone who can do the job well, and it helps retain your employees too.)

6. Select viable candidates to interview. Initial culling of external candidates is done by reviewing resumes. Some people look for a candidate who has done the exact same thing as the job for which you are hiring, but I don’t favor that approach. I look for someone who shows the characteristics I want in an employee, and is positioned to do the job and be challenged by it. Tom Peters calls this the “Hire for attitude, train for skills” approach. Being challenged by a job makes you want to do it well, and it makes you alert to new ways to do a job better. If you’ve done the same job over and over, then you’re not likely to be very creative about doing it yet again.

7. Interview viable candidates. Historically, I’ve found that I interview about 1 in 10 of the people for whom I get resumes if the resumes come from agencies, and I’ll interview about 10 people for every hire. If the resumes haven’t been pre-screened, then I might interview 1 in 20 or even 1 in 50. So I’ll end up reviewing about 100 − 500 resumes for every hire. That may sound like a lot, but when you’re looking at that many resumes, you get to be good at doing a quick first read to eliminate people who obviously don’t fit. Then you go back and read the remaining resumes in more detail to select the best ones to interview.

The interview will usually be in person if the candidate is local, or by phone or Skype if the person is remote. I never hire without an in-person interview, but doing a first interview by phone or Skype saves travel expense and it avoids wasting the candidate’s time on an unnecessary trip.

For me, the interview is the most important part of the hiring process. I eliminate a lot of candidates during the interview because of the attitude they show toward the job or the work. I want someone who can look forward to doing the job, not just do the work because they have to. I want someone who is eager to learn, no matter how advanced or high level the position is. I look for people who are open-minded and curious; responsible but willing to take risks when it’s appropriate; focused on results, but understanding of the human issues that are so important for success. And for most jobs I only consider people who can communicate well.

Sometimes one interview is enough — I have had occasional situations where I made an offer right after the interview. But often I have a good feeling about a person for the job but want to see if any of the other candidates are even better. It’s critical to schedule interviews for all of the candidates during a short period of time so that you can interview a candidate, interview him/her again if necessary in a subsequent visit, and then make an offer quickly. The really good people aren’t on the market very long.

8. Have other people in the company interview each candidate. Usually I’ll arrange to have the candidate talk to other people right after I talk to the person. That way I can stop the process quickly if the candidate is an obvious non-fit, and save the time of the other interviewers.

Sometimes the interviews with other people are a way to get additional viewpoints on the person. Sometimes the other interviews are a way to expose the candidate to the business customer whom the candidate will support. Sometimes, depending on your level in the organization, it’s necessary to have your boss interview the candidate. For “doer” jobs like programmers, I’ve often had the candidate spend some time with one of the other doers who is performing a very similar job. That has three advantages: it gives me some feedback on technical competency from someone who is doing the work day-to-day, it gives the candidate a view of how we actually work on a day-to-day basis, and it gives the doer a feeling of participating in the process.

When a candidate talks to multiple people in the organization in a single interview visit, I’ll try to talk to the candidate again at the end of the visit, with me being the last person to talk to the candidate before he/she leaves for the day. That way I can get feedback from the candidate on how he/she views the position and the interview process. I can deal with any obstacles that might stand in the way of the candidate accepting the position. And it gives me one last opportunity to sell the position and the company to the candidate, even though I’m not sure at this point that I’ll make an offer.

9. Discuss interview viewpoints with all of the people who interviewed the candidate. I’ll do this at least twice: once right after the interview, and again after we’ve had a chance to talk to all of the candidates. Even if the hiring decision is mine alone, I want to get input from other people, and I want them to feel supportive of the decision I’m making.

That’s particularly true for business customers who will work with the candidate after the hire. The business customers need to agree with me that we’re hiring the right person, so that the new hire will be supported by business customers when he/she starts in the job.

10. Select a candidate and check references. If the references hold up to scrutiny, then I’ll move to the next step. If the references raise any questions, then I may need to contact the candidate to get answers or to clarify something I heard.

If I have any doubts about certain areas of the candidate’s past or about his/her qualifications, I’ll go deeper with references. Often the best approach is to ask the references for the names and contact information for other people who may be familiar with the candidate’s work. Then I’ll call these second-level references.

I do this because it is expected that the candidate will list references who will say nice things about the candidate. Otherwise why would this person be given as a reference? But by getting the reference to give me other contacts, I can get around this bias and get in touch with people who might be more likely to be honest and straightforward about the candidate. I’ve occasionally learned a few things this way that disqualified a candidate altogether.

11. Get together with HR and decide on a specific salary offer. This is done carefully to ensure that we pay equitably across all employees — both new and long-term. It’s ultimately my decision, but I appreciate the advice that HR can give me. And often HR has broader information on pay for this job level than I have from my own employees.

12. Make a job offer to the candidate. Sometimes the offer is accepted as is. Sometimes the candidate attempts to negotiate on salary or on some other aspect of the job: start date, vacation time, signing bonus, etc. The policies on some of these things are often set company-wide and so I may or may not have the ability to modify the terms. And frankly, I’ve already put together an offer that I consider fair, and so I’m reluctant to negotiate. I’ll try to be flexible on things like start date, but I rarely change anything other than salary, and I’ve only changed salary amount a few times. To me, the way that the candidate tries to negotiate can be a potential red flag for the way that the candidate will work after he/she is hired. I’ve withdrawn offers to a few people because they didn’t seem to value the offer I made.

Exceptions to this Process
Sometimes the process varies. If a candidate is so far away that an interview trip will be very costly or time-consuming, then I might check references after a phone/Skype interview before I schedule an actual physical interview. Or if the candidate comes to me as a highly-recommended referral from someone I trust, then I might schedule an interview before I see a resume.

I’ve also had a few situations where something in a resume was so different than the norm that I wanted to get an interview even though the resume itself was borderline in its statement of the candidate’s credentials. I’ve interviewed and hired people who didn’t graduate from college because of the amazing commitment they showed in other areas. And I’ve interviewed people with unique backgrounds or experiences (like a helicopter traffic reporter) just because I thought they might make an unusual contribution to the job.

Virtually all of my hiring has been for professional and management jobs. If you are hiring for a job that doesn’t require good written communication (like a retail store clerk, a warehouse worker or a physical laborer), then you can’t always use a resume to screen out bad candidates. In that case the candidate usually just fills out a job application with a basic job history, and then a preliminary interview is conducted to determine job suitability. Essentially the interview is used to capture the information that would normally be part of the resume for a professional person.

Conclusion
If you are a hiring manager, then I hope this description of my own process has provided you with some ideas or insight.

If you are someone looking for a job, then perhaps this gives you a better idea of what you need to do to be hired. In general, the resume gets you an interview, the interview gets you an offer, and the references just keep you honest. It’s always nice to get a direct referral to a hiring manager from someone who knows the applicability of your skills for a position, but in my experience it’s the exception — not the rule.

Failed First-Time Managers: 2 Case Studies

Harwell — Tue, 19 Mar 2013 18:16:41 +0000

I’ve promoted 20 or 30 people into their first manager jobs during my career. Two of those promotions were failures — they did so badly that I had to take them back out of the positions. Here’s what I learned from that experience.

Background
In both cases there was ample evidence that the people were ready for a promotion. Both people had performed well as project leaders where they provided direction to others. Both were respected by their peers and customers, and had good communication skills. Both people had worked for me for a few years, so I had a pretty good idea of what their strengths and weaknesses were.

The First Failure
The first failed manager was promoted into a software development manager position. She had shown good ideas as a project leader, and I expected her to dig right in when she had her own people reporting to her. But I didn’t recognize a problem she had with self-confidence and prioritization.

As a project leader she had to make decisions, and she seemed to cope well with the decision-making process. But apparently her confidence in her project leader decisions was bolstered by the fact that her manager had the final word on those decisions. When she took that manager role, she began to second guess herself. She couldn’t adequately prioritize her time between the important decisions and the trivial ones, and she lost her self-confidence. She got to the point where she would decide something, tell her employees, then change her mind after talking to someone else. Many of those decisions were trivial enough that they didn’t significantly affect project success, but it was unproductive to keep changing her mind, and it began to cause a lot of rework.

I talked to her numerous times about the problem, but she was unable to regain the focus she had as a project leader. Eventually her stress level got too high, and we jointly decided to take her out of the position.

The Second Failure
The second failed manager had been very successful leading infrastructure projects with well-defined objectives. We needed a services manager to lead an organization that was responsible for the overall infrastructure for a large department, and I promoted him into the position.

He had the technical background to understand the area he was responsible for, and he worked well with the employees who reported to him. He initially did well in the position, taking care of infrastructure needs, and prioritizing work based on the needs of the business.

Over a period of several months, however, he began to get overconfident. The customers for his services began to complain that he wouldn’t listen to them, and when I discussed the complaints with him, he took the position that he understood their needs better than they did. I tried various approaches to improve his customer relationships. I tried working with him on defining customer expectations and on better communication. Ultimately, however, I couldn’t get him to understand that he needed to redefine success to include customer perception. I removed him from the position, and transferred him to another area that was more project focused.

What I Learned:
1. Sometimes you can’t tell in advance whether someone will do well in a management role (or any other role). And you can’t wait until you’re 100% positive, because no one is ever sure. There will be failures. You just need to stay on top of the situation and change things if necessary.

2. All first-time managers have to adjust to a new situation. All require support from their manager and some degree of hand-holding. It’s important to meet regularly with a new manager to talk about any questions and difficulties. And it’s important to get independent information from the new manager’s customers, peers and subordinates to get a full picture of what’s going on.

3. The biggest unknown about promoting someone into a first-time manager position is how it will affect the new manager’s self-perception. Some feel inadequate and have trouble with stress, uncertainty and the reactions from their new subordinates. Some let the new implied status and power go to their heads, they become overconfident, and they don’t pay enough attention to the views of their customers and employees. Both reactions can be temporary and can be corrected with time. But different situations demand different levels of tolerance. Sometimes the person has to be taken out of the position if it doesn’t appear that the situation can be corrected in the time available.

4. Even if a first-time manager has to be removed from the management position, that doesn’t mean that the person can’t become a manager later. It’s possible that the person will learn from his or her mistakes and do better in a few years.

5. Taking someone out of a manager position has to be done carefully and announced with tact. The action can be devastating to the ego of the person being removed from the position. If that person is going to continue in your organization then it’s important to explain the change in a way that minimizes the damage to the person’s reputation.

How to Sell to a CIO

Harwell — Mon, 07 Jan 2013 12:45:06 +0000

In 2006 I wrote an article explaining a recommended sales approach for selling to a CIO. The article has been available as a downloadable PDF file since that time, but I thought it might be a good idea to have the text of that article available directly on my blog as well. And after my last article on the Emperor’s New Clothes, I figured this is the right time to share the original 2006 article. If you’re in sales, then this is aimed directly at you. If you’re a CIO (or someone else in IT) being bothered by salespeople, then send your sales reps a link to this article so they’ll figure out how to meet your needs. Here’s the article:

Chief Information Officers (CIOs) have responsibility for choosing the best information technology for use by their company, and then for implementing the technology and supporting it on an ongoing basis. Their job definition calls for them to pay attention to new technology appearing on the market so that they can determine whether use of the new technology will provide benefit to their company.

I’ve known a lot of CIOs over the years, and they all have one thing in common: they’re very busy people. Most CIOs like to hear about new products and services as much as the next person, but because of their position they’re bombarded by salespeople day and night. It gets to the point where they’re afraid to go to industry meetings because they get attacked by salespeople; it’s like movie stars and paparazzi. I know some CIOs who carefully register for industry meetings using a less prestigious job title just so their name tag doesn’t identify them as a target.

The reason for this CIO behavior is obvious: there’s a lot of money in technology sales, and CIOs are key decision-makers for most of those technology sales. If you can’t sell the CIO, then you’re not likely to sell a technology at all. And because there are so many more technology salespeople than CIOs, the CIOs are hopelessly outnumbered, and many of them become reclusive.

This article is written for technology salespeople to help them sell to CIOs. I’m writing the article because someone needs to define the rules of engagement for such a sale. I want to protect CIOs from being badgered, and I figure that if I give you a better way to sell to CIOs then maybe you’ll be more likely to leave them alone when they’re out in public. Most of the badgering comes from bad sales technique, so here’s the right way to sell to CIOs.

The Psychology of a CIO
Let’s start by getting an understanding of the type of person who becomes a CIO. There are two types of CIO: those who come from a technology background and those who don’t. But whether the CIO comes from a technology background or not, the very fact that the person has achieved the office of CIO tells us that the person’s primary motivator is the needs of the business. In very small companies someone may get the title of CIO as a perk when in fact the person just manages the technology infrastructure, but that’s rare. Most CIOs are senior executives, and that means that their focus is on business needs: profit, revenue, productivity, business speed, and shareholder value.

I make this point because the most common mistake I see technology salespeople make is to try to interest a CIO in a new technology because it’s “cool.” Although you might get a brief smile of appreciation for the product’s coolness (after all, CIOs were children once, so they appreciate toys), it’s not going to be enough to make a sale unless there’s an overwhelming business case to be made for the product. No CIO wants to bet their job on something just because it’s cool.

So why would a CIO be interested in your product or service? Companies generally compete on one or more of three factors: product, price or relationship. Most technology companies compete on product: their product is what differentiates them from their competition. A few technology companies – mostly in services – compete on price: the product is pretty much a commodity and they compete by offering the commodity at a lower price than others. And once in a while I see a technology company that competes on relationship: they build a personal relationship with the client and then make sales based on that relationship.

Here’s a warning for anyone trying to sell to a CIO: most CIOs don’t make an initial purchase from a salesperson based on relationship; the initial contact has to be made based on product or price differentiation. That’s partly because CIOs tend to be more tool-oriented than most senior executives (certainly the ones who come from a technology background will be that way) and partly because most CIOs are too busy to allow time for a relationship with a new salesperson to build. So right from the beginning you have to understand why your product or service is better than any other alternative or why it’s comparable to other alternatives but more cost effective (Note that I said “cost effective” – not “cheaper.” It could be more expensive than alternatives if its overall life-cycle cost is lower due to other factors, for example ease of training or low ongoing maintenance.).

Here’s the bottom line on CIOs: They’re way too busy to waste time on anything that won’t provide benefit to their business. So you have to show them what the benefit of your product or service is, and you have to do it quickly, succinctly and convincingly.

Your Leverage: Fear
Experts in advertising often tell us that ads have to appeal to some personal emotion like guilt, flattery, greed, anger, sympathy or fear. From my own experience, fear is the most likely candidate for CIO advertising. CIOs live in constant fear that on the one hand they’ll pin too much hope on an unproven technology or that on the other hand they’ll be humiliated when a competitor gains an advantage by using a technology that the CIO hasn’t approved. Although CIOs learn to live with their fears, they’re constantly trying to strike a balance between reliability and forward thinking. Depending on the CIO and the business, the balance is struck in different places; some CIOs are early adopters, while others lag behind everyone else in implementing a new technology.

The most effective way to motivate a CIO to consider your product or service is to address a CIO’s fear head-on. The message will depend on your product or service. Some products and services are specifically aimed at reducing risk, for example by increasing infrastructure up-time or by handling emergencies. Other products and services are useful in pursuing business objectives of increased performance, decreased time-to-market or lower cost. This second group attacks competitive fears rather than the fear of down time.

The biggest fear of a CIO is that he’ll run out of time; he won’t be able to accomplish his goals before he is replaced. Thus showing a CIO how he can accomplish more in a fixed amount of time is a big attraction, but only if the implementation of the time-saver can be done quickly. It’s virtually impossible to sell a CIO a product or service that takes multiple years to achieve benefit; the CIO will be long gone before the benefit is achieved, and any accolades will fall to the CIO’s successor.

Find a Need and Fill It
This old business slogan is just as true for CIOs as it is for any other customer. But to sell to individual CIOs, you have a “chicken and egg” problem: you can’t get any time in front of the CIO until you convince her that you can fill one of her needs, but you can’t find out her needs without getting time in front of the CIO. There are various approaches you can use to break through this obstacle. Here are a few:

1. Talk to lower-level people in the CIO’s organization to find out what the organization needs. But be careful, since quite often the lower-level people – even if they report directly to the CIO – are more focused on how things are done than on what things should be done. You’ll need to read between the lines, and you’ll need to keep reminding yourself, “How does this need relate to an actual business benefit?” Lower-level people have their own agendas, but it’s the CIO’s agenda you should be interested in.

2. Talk to people who buy the products and services provided by the CIO’s company. Find out how they compare the CIO’s company with the competition, and see if you can discover a competitive disadvantage you can remedy or a competitive advantage you can strengthen.

3. Apply your knowledge of similar IT organizations in similar businesses. Do some research and find something you can offer a CIO that will bring his organization up to the level of excellence achieved by another IT organization.

4. Talk to vendors of products and services that are complementary to your own, looking for a vendor who already sells to the CIO’s company. Gather information about the CIO’s needs from these other vendors.

Once you’ve found a match between a specific CIO need and one of your products or services, write up a brief but compelling case for why the CIO should talk to you. Get specific about dollar benefits, and pay particular attention to how long it will take before payback is achieved. If you can go to a CIO and say something like, “My products can add $10 million to your company’s bottom-line within one year,” there is no way that the CIO will say no to a meeting.

Make the Approach
Ok, so you’ve identified a need, and you’ve developed a great pitch to explain to the CIO how your product or service will provide huge dollar benefit to the CIO’s company within one year. Now how do you get time in front of the CIO to convey your message?

The answer depends on the CIO and the specific company. For smaller companies with only one business location, you can probably approach the CIO directly by sending a letter that outlines your case and that asks for a meeting to discuss your proposal further. A letter works better than an email or a phone call. Incoming calls to a CIO are usually screened by an administrative assistant, and you’re not likely to get through without name recognition. And most people – CIO or not – get hundreds of spam emails a day, so an email out of the blue is not likely to be perceived as positive. Of course, letters are likely to be screened by an administrative assistant as well, but if it’s a personal letter – not just a bulk mailing – then it will probably get through to the CIO.

After the letter is sent, wait a week or so and then call the CIO to set up a meeting. Refer to your letter in the call, and reference the bottom-line value that you can deliver.

For larger companies that have more than one business location, it’s going to be more difficult to talk to the CIO. He’ll be traveling a lot more, and he’s likely to jealously guard his time at his home location. You can still try to contact the CIO directly using a personal letter; your degree of success will depend on how strongly you make your case in the letter. If you don’t get a response, or if you don’t think you’ll have success with a letter, then consider the following alternative ways to get in touch with the CIO:

1. Find someone who knows the CIO, and ask to be introduced. You’ll have a better chance of success if the person doing the introduction is a respected colleague or business associate. If the person is a personal friend of the CIO outside of business, then the introduction will be more suspect, but it might still work out. Do not, however, go over the CIO’s head and contact the CEO or President of the company, even if you know her. You’ll get your CIO meeting, but the CIO will harbor a grudge against you, and you’ll have to work even harder to make the sale.

2. Identify another CIO of equivalent rank (same size company) who knows your products and services and thinks highly of you. Have this other CIO make contact first in an equal-to-equal communication, and then have this other CIO introduce you. This works particularly well if your own company is about the same size (or larger) than the company to which you want to make the sale, and if you can have the CIO of your own company do the introduction. If that isn’t appropriate, then see if you can persuade one of your other CIO customers to introduce you.

3. Sell up the ladder. Start lower down in the CIO’s organization, and introduce yourself to the highest ranking IT person who will listen to you. Make the case for why he should consider doing business with your company, perhaps sell him some smaller product or service, and then persuade him (or his boss) to introduce you to the CIO.

4. Sell to the business users in the CIO’s company. This is a tricky approach, since it can backfire on you just like going over the CIO’s head. But if your company has a product or service which offers significant non-technical benefit, then it’s perfectly valid to sell to the business users instead of the IT organization. However, make it clear from the beginning that you would like to involve the IT organization as well, and ask the business users to invite someone from IT to some of the meetings. Bend over backwards to show any IT attendees that you have their best interests at heart. At an appropriate time, ask to be introduced to the higher management of the IT organization, and eventually the CIO.

Make Your Case
You’ve finally got that appointment with the CIO; now make the most of it. No matter how long the scheduled time is for the appointment, you’ve got no more than about fifteen minutes to convince the CIO that she should do business with you. This is your opportunity to convey the brief but compelling case that you’ve previously put together. Here are some tips:

1. As soon as introductions are done, start with the bottom line. If you can save the CIO’s business $10 million, then say so to get her attention. Then gradually peel back successive layers of your proposal based on the CIO’s interest and questions. Approaching the pitch this way guarantees that you’ll get a strong message across no matter how little time you have. And don’t be surprised if an interruption occurs and your time is cut short; that’s to be expected in a meeting with a time-crunched CIO.

2. Don’t start with background information on your company, except for maybe a sentence or two. The key message isn’t a history of your company – it’s the contribution that your products and services can make to the CIO’s business. That’s why you should start with the bottom line.

3. After presenting the bottom line, substantiate your claim. Provide the facts underlying your figures. Compare the CIO’s situation to other customers or to other companies who have a similar challenge or problem. But be very careful not to reveal information about another customer that might be regarded as confidential by that customer; if the CIO sees you being cavalier with another customer’s information, then he will expect that you won’t keep his own company’s information confidential. That’s a deal killer.

4. There are four messages that you should convey in your meeting:

My products and services can give your company bottom-line benefit.
You can receive the benefit quickly, ideally within the same fiscal year as the expense.
My company is trustworthy; we’re solid, and you can count on us.
I will make your job easier; my products and services will solve more problems than they create.

If you can truthfully and convincingly convey these four messages, then you’ve laid a solid foundation for a sale.

Eliminate Risk
Ok, so now you’ve got the CIO’s attention. You’ve conveyed the four messages, but the CIO will still have doubts; after all, it’s his job that’s on the line. Your next task at the first meeting, and at subsequent meetings, is to reduce or eliminate the risk for the CIO. There are four types of risk that you need to reduce or eliminate:

Financial Risk for the CIO’s company. There needs to be a win-win arrangement between your company and the CIO’s company.
Job Risk for the CIO. There can’t be any way that this will affect the CIO’s job other than positively.
Technical Risk associated with your products and services. The CIO needs to be sure that the products and services will work as proposed.
Future Risk associated with changes in the state of technology over time. The CIO needs to understand how future technology changes will impact the particular products and services that are being proposed.

There are a number of ways in which you can reduce or eliminate these four risks. The specifics depend on the product or services you offer, but here are a few ideas:

1. Offer a free trial of your product or service for a limited scope test (e.g., short-term software licenses for a small test organization, or a service provided to a small subset of the general company population). This reduces Technical Risk, since the CIO’s company will see first hand how well your products and services work. It also reduces Job Risk for the CIO if the test can demonstrate the kinds of benefits that will come from using the product or service. And if the financial benefits can be demonstrated in the trial then it reduces Financial Risk as well.

2. Provide free training for the people involved in the test or trial. If you provide the product or service without the training then the test organization is not likely to use the product or service correctly. Furthermore, you’ll find that once people are trained in the use of a good product or service, they’ll want to continue using it after the trial. The test organization will actively lobby for the sale.

3. Provide reference information about CIOs in other companies who are successfully using your product or service. Contacting the other references will reassure the CIO and will reduce Job Risk and Technical Risk. And if these reference accounts can provide the CIO with specific financial data that show the benefit of the products and services to their companies, then it will reduce Financial Risk as well.

4. Provide white papers written by your company that show how your products and services fit into various IT architectures, both current and future. Case studies with actual customer information (even if the customers are disguised to protect their confidentiality) will make more of an impact. This reduces both Technical Risk and Future Risk.

5. Have the CIO sign a nondisclosure agreement, and then share information with the CIO on future products and services from your company. If it makes sense, and if the size of the deal justifies it, then offer to have the CIO visit your development organization and/or talk to your own CIO, CTO or CEO. Sharing future direction will reduce Future Risk. Having the CIO sign a nondisclosure agreement will protect your company, and it has the added benefit that it makes the CIO feel like an insider; this makes it more likely that the CIO will buy.

6. Reduce Financial Risk by working out a financial proposal for your sale that provides a net positive impact in every fiscal budget year. Ideally the product or service will pay for itself in benefits in the first fiscal year. But if that isn’t possible, then work out a way to finance the purchase (taking the financial accounting guidelines of the CIO’s company into account) to generate positive cash flow for the CIO’s company in every fiscal year. It’s a whole lot easier for a CIO to sell a project when he can show that it impacts the bottom line positively in every upcoming year.

7. If you and your company are absolutely convinced that the bottom-line impact of your product or service will be positive, then contractually make that commitment. This eliminates the CIO’s Financial Risk altogether and makes the purchase a no-brainer. But be careful to specify exactly how the bottom-line impact will be measured, and explicitly state any assumptions underlying the agreement. You need to protect your own company in case the CIO’s company makes major changes in ownership, in commitment, or in underlying conditions that invalidate your guarantee.

Assuring Add-On Sales
Earlier in this article I said that CIOs don’t make an initial purchase from a salesperson based on relationship. However, once the initial sale has been completed, and once the validity of your bottom-line promise has been established, then you’re well on your way to establishing a trusting relationship with the CIO. Continuing to build this trusting relationship will enhance your ability to get add-on sales from the CIO’s company.

But remember that the trusting relationship is very fragile, and it’s based on your continued honesty and your continued ability to deliver bottom-line performance. You can’t slack off just because you’ve got your foot in the door; you have to do your homework on every add-on sale just as you did for the initial sale. If you promise something and don’t deliver it, then your trusting relationship will be over very quickly.

You also need to keep an eye on the politics in the CIO’s company, arrange to meet additional executives, and build trusting relationships with them as well. Sooner or later, the CIO will leave, in spite of the support you’ve given her (or possibly because of it; the CIO may go on to a bigger company). You need to be prepared to start over in building a trusting relationship with the new CIO, aided by your history of success with the company.

Conclusion
The key to guaranteed CIO sales is to:

1. Determine the bottom-line value of your product or service for a CIO before you ever contact the CIO.

2. Get the CIO’s attention by letting the CIO know how much monetary value you offer.

3. Take maximum advantage of the limited time you have with the CIO by focusing on the value, and on conveying that value to the CIO.

4. Reduce or eliminate all of the risks that will prevent the CIO from completing the sale.

5. Once you’ve gotten the sale, focus on building a trusting relationship with the CIO and with other company executives.

Always remember that you’re not selling a product or service – you’re selling the value of your product or service to the CIO’s business. Don’t ever confuse those two things; without business value your product or service is worthless.

The “Emperor’s New Clothes” Trick and How to Deal with It

Harwell — Tue, 11 Dec 2012 12:16:46 +0000

As a child, I read the story “The Emperor’s New Clothes” by Hans Christian Andersen. The story is one of the earliest known accounts of a trick that technology salespeople use all of the time. Let me first recap the story, and then I’ll explain the trick and how to deal with it.

The Plot of the Children’s Story
According to the plot, a pretentious emperor always wants to be seen as superior to everyone else. Some con men convince him that they can make him a new set of clothes that are better than anything he has ever worn. The clothes are incredibly thin and luxurious, and so light that they feel like air. But the clothes have one interesting property: People who are unworthy can’t see them at all.

So the con men get out their weaving equipment and go through the motions of making cloth. The emperor watches the early stages of manufacture, and notices that he can’t see the cloth. But he keeps his mouth shut because speaking out would reveal the emperor as unworthy. The con men continue with their charade, pretending to sew the invisible cloth together until they have an invisible set of clothes.

The con men bring their fake clothes to the emperor in his bedroom. The emperor strips down, and the con men pantomime putting the clothes over the emperor’s head and fastening them in place. “Are they not as light as air like we promised?” they ask. The emperor, too proud to admit that he can’t see anything, agrees that they are definitely very light.

The emperor gets in his open carriage for a trip through the city. The story of the emperor’s clothes has preceded the procession, so everyone watching the king figures they’re just unworthy because they can’t see anything. And no one watching wants to acknowledge this because then everyone would know that they’re unworthy. But then a small child watching the procession cries out, “The emperor has no clothes!” Suddenly everyone, including the emperor, realizes that they’ve been conned.

The Modern Trick
The modern equivalent of this trick is to sell a technology that doesn’t make sense by convincing you that the technology is so advanced that you can’t understand it. The sales people start with a simple yet far-reaching premise, something like “we’ve invented a revolutionary new database technology that will completely eliminate fraud by providing full traceability of all transactions back to their original source.” The target audience for the sales presentation is a group of senior executives in a company that has recently been victim to fraud or, even better, a group of senior executives who work for a competitor to the victim. The executives in the actual victim company will be more suspicious, but their competitors will be naive and yet eager to prevent a similar problem in their own company.

The salespeople schedule a meeting with the executives in the company. IT people are included, but they’re outnumbered by operational executives with no technical background. The CIO will probably bring along one or two database experts, just to make sure there is technology expertise.

The presentation begins. The first part of the presentation attempts to scare the hell out of the audience, reeling off horror story after horror story about fraud and the cost to its victims. Statistics are cited to make it seem likely that there’s no way to escape this problem — it will hit you sooner or later no matter what you do.

Next come some complicated diagrams and charts which “explain” the new innovation. To a non-technology person they look impressive. They’re full of technical terms that are vaguely reminiscent of other technical words that have been thrown around a little bit by your IT department — things like relational database, multi-phase commit, fault-tolerance, multi-threading, and maybe even that most sacred of all current technology terms, “the cloud.”

The appeal of the presentation is emotional — not logical. The salespeople want you to see their software as the only true solution to a problem that’s infecting the entire world. Given the heavy executive weighting of the audience, it’s unlikely that the company’s technology experts will get much opportunity to ask questions. But if they do, the salespeople are well prepared with answers that sound good to the executives but don’t actually address any of the real technical issues. The unspoken message to the technical people is, “this is technology so advanced that we don’t expect a mere mortal like you to understand it. But believe me, it works.”

By the end of the presentation, the executives are ready to sign up. The discussion is not about yes or no but instead about how fast the technology can be implemented. The CIO and the technical people know that there is too much momentum to stop this thing so they instead try to rein in the discussion, offering alternatives like a “proof of concept” or a “limited trial.”

And this is where the most important issue comes to the forefront: How much is the CIO trusted by the executives? If the trust is there, then the momentum of the sales pitch will be broken, and a more rational approach will prevail. Maybe the CIO will assign someone to investigate this technology further, the IT organization will gather information from reputable technology assessment firms like Gartner, and a team will talk with current customers of the technology to get a feel for the real cost/benefit.

But if the trust between the business and IT isn’t there, then there’s a 90% chance that some form of contract will be signed before the end of the week. Some number of months later, the poor CIO will be put in the unenviable position of having to explain to the business executives why this miracle technology couldn’t deliver the promised results for their business. And there’s a very good chance that the CIO won’t survive in the job another two years. After all, if a miracle is promised and it’s not delivered, then whose fault is it? It must be the CIO who didn’t implement it correctly, since it obviously couldn’t be the technology.

Lessons from the Parable

If a concept can’t be explained simply, don’t buy it. Good products are sometimes complex, but there’s no magic to them. Every good yet complex product has a simple explanation for its effectiveness that’s understandable to any knowledgeable buyer. Put your vendors on the spot: Ask them for that simple explanation. And if they can’t provide an acceptable answer, then throw the vendor out.
There are a lot of reasons why it’s important to have trust between your business executives and your IT executives. One of the most important reasons is so the non-technical executives have someone they can trust with technical decisions. If that trust isn’t there, then you’re going to have technical decisions made by non-technical people — not a good thing.
Don’t let the business buy a product whose advantage is high technology if your own technology people don’t agree with the premise.
If something sounds too good to be true, it probably is.

And although my example is an “advanced” database technology, I’ve seen this trick used equally effectively by people selling CRM systems, ERP systems, cloud solutions, and even accounting software. In each case the salespeople promise a magic solution but fail to disclose all of the behind-the-scenes hard work and changes in business processes that are required to successfully implement their product. Even the best products have no magic — the computer systems are just doing something that you could do manually, but the systems are doing it more reliably and millions of times faster. Ultimately it’s not the product that produces the good result — it’s the changes you make in your business to support the product. Don’t let your business people forget that.

Emergencies Aren’t Strategy

Harwell — Tue, 27 Nov 2012 20:49:54 +0000

In a previous article I talked about how there are two reasons for strategy: focus and communication. It seems like companies have a lot of trouble with focus. Particularly in large companies, there’s a tendency to “focus” on everything at once: accomplishing all of your objectives, expanding in all of your markets, increasing revenues in all product lines at the same time that you’re cutting costs in all departments. And of course this defeats the entire idea of focus, which is to concentrate your resources on the few things that are the most important. If everything is important, then nothing is really important.

Some companies and governments have attempted to get around their lack of focus by using emergencies. They declare a certain situation as an emergency, and then go into some sort of lock-down to concentrate all of their labor and money on solving the emergency. This can be successful but it’s self-defeating. It leads to employee burnout, it’s seldom cost-effective, it typically goes after symptoms instead of the underlying core problem, and it has a short-term focus with no support for long-term solutions.

Companies get into trouble when they replace their strategy process with a series of emergencies, jumping from emergency to emergency without ever putting things into perspective. This is everything that strategy shouldn’t be: impromptu, short-lived, wasteful, pushy, and stressful.

A state of emergency should be reserved for those situations when an unexpected event catches you by surprise, or when things you anticipated as possible but improbable suddenly become certain. But probable things shouldn’t be handled as emergencies — they should be handled as part of normal strategy.

If you can’t use your strategy to focus your resources, then you don’t have a strategy — you have a wish list. A wish list isn’t a bad place to start when you put together your strategy, but it’s not the end point. You still have to prioritize the objectives on your wish list, eliminate or defer all but the most important items, and then determine the specific ways you are going to accomplish the remaining important objectives. Then when you assign your resources to those remaining objectives, your strategy will be complete, at least for the moment. You still have to periodically review your strategy, of course. And you have to adjust it to take changing conditions into account. But it’s still the way that you focus your resources at any point in time, and it’s the way that you communicate what’s important to the people with whom you work.

Don’t use emergencies as a substitute for strategy. Do the strategy correctly from the start, and you’ll have far fewer emergencies.

Is Your Strategy a Rifle or a Shotgun?

Harwell — Mon, 12 Nov 2012 23:00:00 +0000

A strategy can be viewed as a way of achieving an objective. A coach’s strategy for the football game might be to attack relentlessly on the ground. A general’s strategy for the battle might be to feint an attack to the center while flanking from the right. A CEO’s strategy for the business might be to become #1 or #2 in every market and to withdraw from markets where her company can’t be #1 or #2. A corrupt politician’s strategy to get elected might be to align with the “smaller government” movement to gain votes while secretly taking money under the table from businesses who need special favors.

The Common Thread
As diverse as these strategies are, they all share one thing: they deal with a limited amount of time and resources by focusing that time and those resources in one particular direction.

The football coach knows that a game only has 60 minutes of play, that his opposing team has the best pass defense in the league, and that his own defensive team isn’t as good as theirs. So he plays to his team’s strengths, and focuses as much playing time as possible to keep the ball on the ground and to chew up the clock by making short gains.

The general knows that his army is a pretty even match for the enemy forces, but he rearranges his troops to move more of his troops to the right, hoping to keep the move secret until he attacks in surprise from that direction. While he’s focusing more of his soldiers on the right side, he’s leaving the left side vulnerable. But he’s betting that the enemy won’t realize the vulnerability until the right side troops overwhelm a significant number of the enemy.

The CEO has done enough research to show that, in these particular markets, only the #1 and #2 competitors get enough market share to be profitable. So by withdrawing from any market in which that #1 or #2 status can’t be achieved, she can focus her investment on increasing the market share and profitability of her #1 and #2 products.

The corrupt politician wants fame and riches. By aligning with the “smaller government” camp, he gets an instant bump in the polls without having to invest time and advertising money in building a name and position for himself. By taking money under the table, he builds a war chest to use for ads against his political opponents, and he lays the groundwork for a stream of income that will lead to the riches he’s coveting.

The Road Not Taken
Every one of these strategies — even the strategy of the ethically challenged politician — deals with choices. And for every choice that’s made, there’s an alternative choice that wasn’t made.

The football coach could have counted on surprise and tried mixing up his plays to catch the opposing team in a moment of weakness. He could have violated the spirit of the game and asked his players to play dirty and try to physically cripple key players on the opposing team.

The general could have counted on sheer will and patriotism to win in a direct confrontation. He could have ordered a full attack right down the middle of enemy forces.

The CEO could have reasoned that no one gets to be #1 or #2 without being #3 or #4 first. She could have invested heavily in advertising or new products for her lesser markets, hoping that she could break through into a #2 position in a few years.

The corrupt politician could have taken an honest and ethical route, counting on his own integrity to capture votes. He could have looked forward to income from the lecture circuit after he retired from a well-respected political career.

If Your “Strategy” Doesn’t Reflect a Choice, It Isn’t a Strategy
It’s not a strategy to tell your team, “Do the best you can” because no trade-offs have been made. It’s not a strategy to tell your army, “Keep calm and carry on” because what’s the alternative, “Panic and run around in circles”? It’s not a strategy to tell your employees, “Increase sales 20% this year” because even though you’re being specific about a goal, you’re not giving them any information about how to make choices. Which sales? How? By doing what?

And it’s not a strategy for the politician to say, “Win the race, then get rich,” because it doesn’t give specifics on how he’s going to win and how he’s going to get rich.

If no choices are being made, then no strategy is involved.

Shotgun or Rifle?
Take a look at what you call the “strategies” for your business. Do they reflect a choice that has been made? Is there an alternative choice that could have been the desired strategy instead? Do the strategies focus resources on one area in preference to another, essentially shutting down one approach while investing resources in the chosen direction?

Committees tend to develop “shotgun strategies”: a laundry list of items that spread effort in a number of different and diverging directions, without a clear preference for one objective over another. Strategies set by one person, or set by a focused group of people, tend to be “rifle strategies” instead. They maximize the time and resources of the business by focusing on a few key things.

Shotguns are used for small game that moves quickly. You cover a large area with the blast and hope that at least a few of the pellets hit a target. Sometimes you shoot at multiple birds in flight, and hope to bring down at least one.

Rifles are used for large game. It takes more power to bring down large game so you have to focus the entire bullet on one key spot. You have to pick a specific target, and concentrate on what it takes to deliver that one target.

If you know where you want to go, and you know how you want to get there, then use a rifle strategy. You can achieve big things for your organization.

If you don’t know where you’re going and you have no idea how to get there, then by all means use a shotgun strategy (although I hesitate in even calling it a strategy). Who knows? You might accidentally be successful. But since shotguns are used for small game, you won’t achieve very much.

What strategy approach are you using? Do you know where you want to go? Have you made choices?

Taking Shadow IT Out of the Shadows, Part 2

Harwell — Mon, 29 Oct 2012 20:06:22 +0000

In my previous post I described Shadow IT and the problems it causes. In this post I’ll describe some approaches that the formal IT organization can take to deal with Shadow IT, and I’ll give you some recommendations.

5 Approaches to Dealing with Shadow IT
Most formal IT organizations take one of five different approaches in dealing with Shadow IT:

Ignore it. This can be dangerous for two reasons. First, since a business organization’s use of Shadow IT is an indication that the business organization is not happy with what your IT organization is providing, ignoring the Shadow IT means that you’re ignoring the fact that the customer organization is unhappy. And second, it’s quite likely that some of the systems purchased or written by the Shadow IT group will end up being “thrown over the wall” into the formal IT organization, or at least require interfaces with formal IT systems. So if you ignore Shadow IT now, then you (or your replacement) will regret it later.
Fight it. This can work if the formal IT organization has enough support from the CEO. To fight Shadow IT successfully, you’ll have to create explicit standards on what can or can’t be purchased, built, or contracted for by the business organizations, and then you’ll have to police those standards rigorously. This works well if IT has a good relationship with the various parts of the business, so the approach’s success is highly dependent on the individual people holding the various positions. But you can’t let down your guard for a second — it’s very easy for a business executive to sneak something in when you’re not looking.
Discourage it. This is a slightly milder version of “Fight it,” and it’s often easier than the “Fight it” approach when IT doesn’t have all the executive support you would like. You still need the explicit standards on what the business can or can’t do, but you have to pick your battles on what you fight and what you ignore.
Work with it. This is a more proactive, positive version of alternatives #2 and #3. You define standards for what the business can or can’t do, and then you define further standards for how the business can do the things that they’re allowed to do. You can assign people to work with the Shadow IT groups to help them with technical decisions. And you can help them choose products and services which meet the business needs while conforming to the basic architectural standards you’ve established for the overall business. The approach is a tightrope walk, though: You’re walking a fine line between control and lack of control, and it takes some serious relationship management to make this approach succeed.
Integrate it. This goes further than #4 in taking Shadow IT out of the shadows and making it an explicit part of your IT strategy. This is kind of like a decentralized approach to corporate IT where certain services and projects are done by the business IT organizations, and certain other services and projects are done by a corporate IT organization. Standards are decided jointly, and enforced by both the business and corporate IT organizations. This can be a very effective way to share technology direction setting across a diverse group of business organizations. But if it’s not done well, it can lead to more Shadow IT, or maybe we should now call it Shadow Shadow IT, since it’s in the darker shadows beyond the shadows.

How an IT Organization can Derive Benefit from Shadow IT
Used properly, Shadow IT can be a supplement to your formal IT budget. Think of it like overflow seating at an event: all of the normal seating is taken, and the overflow seating provides some measure of benefit at a lower level of service. So if you’ve got rigid constraints on your formal IT budget, but you need to accomplish technology objectives that require more money than your budget, Shadow IT can provide a way to achieve some of those objectives using other people’s money. This works best, of course, if you use alternative #4 or #5, and works least well if there is no communication whatsoever between the formal IT organization and the Shadow IT project teams.

It’s easy to get overwhelmed by just managing your formal IT organization, and obviously the coordination and communication with Shadow IT projects will make your life more complex. But if you can’t make a case for moving the budget to your own organization, or if your formal IT organization isn’t trusted enough for the business organizations to give their Shadow IT budgets to you, then you’ll have to do the best you can with the situation you’re given.

Recommendations
No matter which of the five approaches you choose, consider these recommendations:

Don’t let the business disapprove a formal IT project and then let Shadow IT do it anyway. If there are business reasons why a project shouldn’t be done then those business reasons should apply no matter what organization does the project.
Provide IT advisors to Shadow IT organizations to establish realistic expectations on data availability, and to help steer Shadow IT projects toward appropriate standards for software and hardware. The key word here is “help.” Be positive, not negative. You’re an advisor in this case — not a manager. Pick your battles wisely.
Provide a “quick response” capability to do short-term projects without all of the red tape of the bigger projects. Carve out a specific percentage of your overall formal IT budget to be used for these quick response projects. Many of the Shadow IT projects come from frustration with having to live with systems issues that could be fixed fairly quickly, or with systems limitations that could be eliminated with a small amount of resource.
Alternatively, let the Shadow IT people be the quick response providers as long as they conform to the standards set by the formal IT organization. This can be win/win: they get satisfaction using their own people, and you can focus your formal IT resource on doing the bigger projects.

Conclusion
Shadow IT can be your enemy or your friend; it’s all in how you deal with it. Start by getting it out of the shadows — if you don’t know about it, then you’ll never be able to cope with it, no matter which approach you take. Then choose your approach from the five approaches listed above, based on the trust level between the formal IT organization and the individual business organizations, and based on the support level that the formal IT organization is getting from the CEO. In many cases, you’ll find that you need a separate approach for each business organization because your relationship with each business organization is different. But whichever approach you take, keep up the communication between the formal IT organization and the Shadow IT project resources. You may be reporting through different executives, but you’re all trying to make things better for the same company.

Taking Shadow IT Out of the Shadows, Part 1

Harwell — Mon, 22 Oct 2012 20:48:19 +0000

Shadow IT is one of the names for the Information Technology work and expense that’s done outside of the control of the formal IT organization and outside the formal IT budget. It’s more prevalent in some companies than in others, and it often changes over time within a company. I’ve found that the amount of Shadow IT in a business usually varies in inverse proportion to the level of satisfaction the business feels for the formal IT organization. If business people feel that the formal IT organization is providing everything the business needs, then Shadow IT is virtually nonexistent. But if the formal IT organization is failing, then the expenditure on Shadow IT can exceed the formal IT budget.

To understand Shadow IT, imagine yourself as a business executive. You’ve got a job to do and business objectives to achieve. If you feel that the formal IT organization is standing in the way of achieving your goals, then you’ll find another way to be successful, even if it means hiring consultants or utilizing your employees to create your own underground IT organization.

The Good News
Shadow IT has good points and bad points. One of the good points is that Shadow IT demonstrates a real business interest in information technology and in information technology projects. You know the interest is real when the business is willing to invest their own budget to get work done that they feel they can’t get done through normal channels.

The Problem
But Shadow IT also has bad points. Business executives who make their own IT decisions optimize those decisions around their perception of their own short-term needs, and they underestimate the interdependency that their systems have with other corporate systems.

Let’s break down that problem into its three components:

1. Perception of Needs
The focus of a business executive is on his or her own needs — not the needs of the business as a whole. For example, a sales executive will see the need for a sales tracking system or an order entry system or a customer relationship management system, but will not typically step back and look at the bigger picture. Yes, they realize that sales information is required by manufacturing or distribution or service providers downstream. But that won’t be their focus, and so those other needs won’t be a principal part of their system requirements.

For example, I worked with a company in the late 1980’s where the sales organization made its own deal to buy notebook PCs for its sales force. The vendor was pushing WordPerfect word processing software, and so they bundled a copy of the WordPerfect software into the deal. As a result, the sales organization established WordPerfect as a standard for the organization, in spite of the fact that Microsoft Word was used everywhere else in the company. This worked fine for internal sales documents, but created havoc whenever anyone from outside the sales organization needed to review or share documents.

2. Short-term Emphasis
The business executive is usually focused on the current quarter or the current year. Goals are defined that way, and so the business executive is typically looking for quick results.

Rarely do business executives understand or consider all of the long-term implications of a systems purchasing decision or outsourcing decision. They don’t see the problems of supporting a set of diverse software and hardware platforms. They don’t consider the need for a resilient system that has to be available 24×7, and has to be able to handle peak user demand that may be a hundred times greater than the average demand. They don’t see that the simple “off-the-shelf” software they’re purchasing may not adapt to the evolving needs of the business.

The short-term emphasis also leads to quick decisions, and sometimes a desperate business executive will just buy the first solution that he or she sees, without going through any sort of logical analysis of alternatives. Or in many cases the executive will just buy the same solution that he or she used at a previous employer, whether or not it’s the right fit for the current business.

I’ve seen this happen several times. The most notable example was a department executive who was under budget at the end of the year, and ran into a pushy salesperson who offered a bottom-of-the-line enterprise software product at an end-of-quarter special price. Without looking at other alternatives, without doing a pilot of the software to assess its capabilities, and without even considering the need for hardware to run the software, the executive made a mid-six-figure dollar commitment to buy the software and use up his remaining budget for the year. The consequences of the decision would haunt the business for years to come.

3. Systems Interdependency
The business executive often makes simplistic assumptions about data. According to most executives, data is always accurate, consistent, timely, complete, and easily available. A manufacturing executive might buy a scheduling system and assume that existing order data will just flow right into the new system without any changes or validation. But the reality may be very different: data is only as good as the people who enter it, the system that validates it, the format it’s stored in, and the management discipline of other organizations in the company. And feeding data from one system to another may require a tremendous amount of technical expertise and possibly an entirely new system just to do data conversions.

The Cost of Shadow IT
I had a neighbor once who, in preparation for selling her house, brought in a cheap painter to make the outside of the house look nicer. The painter skipped the normal steps of scraping, cleaning and priming the house, and just painted over whatever was there, including dirt and even leaves that adhered to the house. The neighbor was happy with the low price for painting the house, and the house looked good for a few months, but I’m sure the people who bought the house paid the price for my neighbor’s shortcuts.

And so it is with Shadow IT. A professional IT organization has to look at all of the different aspects of information technology use: not just the initial cost of software and hardware, but all of the training, maintenance, customization, integration, infrastructure and support that continues for years to come. Shadow IT is often done following less than professional standards. While the result may be adequate in the short-term, the systems implemented using this approach often fail in the long-term, fall apart when critical people leave the business, or incur large costs later in their life cycle.

Often the Shadow IT projects end up being handed off to the formal IT organization. The formal IT organization then has to go back and fill in all of the gaps left by amateur IT people who took short-cuts, much like the short-cuts taken by my neighbor’s house painter.

And since Shadow IT projects often use hardware and operating system platforms that don’t follow corporate standards, the formal IT organization gets saddled with new platforms that require training and support resources that don’t exist in their organizations.

Thus the short-term savings that may have accrued by using Shadow IT are more than offset by longer-term costs paid by the formal IT group. And ultimately those costs hurt the business bottom line.

Next
In Part 2 I’ll describe the five most common approaches that formal IT organizations take in dealing with Shadow IT, I’ll offer some comments and advice on each approach, and I’ll give you my recommendations.

Why Both Government and IT Need Transparency

Harwell — Mon, 15 Oct 2012 20:00:39 +0000

A lot of people in the United States are against what they call “big government.” Yet most of those people are in favor of government services that they consider essential. In many cases, the concern about big government is not actually a concern about the size of government — it’s more a concern about a government that has gotten out of control, a government that no longer seems to manage its expenses wisely, a government that seems to waste money on things that people consider foolish.

Much the same could be said about many IT organizations. When business people have a negative view of their IT organizations, it’s not a statement that information technology shouldn’t be used in their business — it’s more of a concern that the company’s investment in IT is not being used wisely.

In some cases, self-interest plays a role in criticism of government or IT spending. Some people consider an investment “wise” if it provides benefit to them, and unwise if it provides benefit to someone else instead.

But in most cases, a criticism of IT spending — just like a criticism of government spending — is based on a lack of understanding of exactly where the money is going. The popular term for this is a “lack of transparency.”

What is Transparency?
Transparency can mean different things to different people, but the key elements of successful transparency are:

A simple, clear (thus the word “transparency”) accounting of where the money is going, in high-level terms. For example, x% of the budget to infrastructure, y% of the budget to maintenance, z% of the budget to projects.
An explanation of the high-level terms, showing the next-level breakdown of why the money needs to be spent in those areas. I emphasize the word “why” because it’s critically important for people to understand the business (or government) purpose of funding in an area. If people are going to justify the spending in their own minds, then it’s key for them to understand what would happen if that funding didn’t exist. What services would disappear? How would the world be different if that funding were discontinued?
For projects — which have a beginning, a middle and an end — a sense of where things are in each project. How long is the project supposed to take? What will it cost? How many people are working on the project? When will the project be completed? Will the project finish on schedule? Is the project over or under budget, and why? What has changed during the course of the project that is influencing its status? And most importantly, how will the business (or government) be different after the project is complete? What will be better?
An acknowledgement of current issues. Where are things not going as well as they could? Are certain areas underfunded and thus causing problems in the business (or government)? Are projects stalled due to lack of support or resources? How could additional investment help?
A recognition of opportunities. Are there areas where the need for funding is declining? Are there services which could be discontinued or replaced by something less expensive? Are there areas where outsourcing could help? Are there opportunities to replace an old technology with a newer technology which would make things more effective and/or less expensive?

The Risks of Transparency
Many CIOs oppose transparency because they’re afraid that providing transparency will result in loss of control. They think that if business people know exactly how the IT budget is being spent then the business people will try to micromanage the IT organization. In my personal experience, I have not found that fear to be justified, as long as budgets and project plans are presented in a logical manner that ties financial information to specific business benefits.

Financial transparency runs into trouble when budgets are presented based on expenditures rather than benefits. For example, technical training for IT employees is key to employee development and to successfully keeping up with technology advances. But you should never include technical training as a separate line item in a high-level presentation of IT costs, just as you never include employee retirement benefits as a separate line item. Instead, the technical training cost should be considered part of the cost of having an employee, and so the training cost should be included in the basic employee cost which is associated with each service provided by IT or each project done by IT.

If someone in the business wants to suggest specific changes to your IT budget, then let them make decisions on business benefit — not decisions on how efficient you are at delivering that benefit. So, for example, if they think an infrastructure expense for Internet servers is too high, then let them decide how important it is for the servers to be available all the time — not whether or not you could get by with fewer servers. And if they insist that your costs may be out of line with other providers, then let them suggest an IT project to do an analysis of whether there’s a better way to provide the required capability. That analysis can look at the hardware and software being used and determine whether current technology offers a better, more cost-effective way of delivering that service.

The Key to Successful Transparency
The key to successful use of transparency is to connect every dollar being spent to a specific business benefit. Often that requires restating your financials in a way that doesn’t correspond to your organizational structure. For example, you may have a help desk organization that provides support across a number of different application areas. The cost of that help desk organization should never be presented as a single line item because it will immediately become a target for cuts. Instead, the cost of the help desk should be apportioned out based on the areas of business benefit that it provides. For example, support for users of a Customer Relationship Management system should be rolled into the support cost for that system, and support for desktop applications should be rolled into the support costs for the specific business organizations being supported.

Just to be clear, I’m not talking about charge-backs here, where the cost of these services is cross-charged from IT to the other departments and the money is essentially taken out of the IT budget. I’m merely saying that the budget summary for the IT organization should account for the support costs under the line items for the individual systems or areas being supported. Don’t lump support all together, but instead summarize the support costs under the categories where benefit is provided.

This approach may seem deceitful to some readers, but I’m not advocating this restatement of financials as an attempt to hide costs — the approach actually clarifies costs. If a help desk organization is considered a single expense and the budget is cut, then someone will have to make decisions about which user areas will get a lower level of service. And whichever areas get the lower levels of service, IT will get the blame. My suggested approach allocates the help desk costs to the business areas from the beginning, and lets the business areas themselves make the decisions about help desk cuts by tying those cuts to specific areas of support, thus avoiding IT blame and putting the responsibility where it belongs.

Conclusion
The secret to avoiding the stigma of big government or big IT or any out-of-control spending is to use transparency to make it absolutely clear where the money is going. While people tend to argue about generalities, they’re seldom in doubt about specifics that affect them. By tying each dollar and resource of an IT organization to a specific business benefit, you can make it very clear to everyone that your organization is doing exactly what has been asked of it. If the business wants to cut spending, then the business should be prepared to live with fewer services. And if the business wants more out of IT, then it’s clear that more investment is required.

Transparency gives you a better relationship with the business, and it lets you sleep better at night, knowing that your IT organization is doing exactly what you agreed to do.

4 Advantages of a Portable Expert

Harwell — Tue, 02 Oct 2012 10:25:28 +0000

In my previous post I defined the term “Portable Expert” and I described the two secrets that make portable expertise possible. In this post I’ll give you some examples of portable expertise from my own experience, I’ll list four advantages of hiring a portable expert, and I’ll give you some tips on how to create your own portable experts.

An Example of Portable Expertise
Back in the mid-1980’s I led a group that was responsible for creating new systems for a tax-filing business. We were starting from scratch with no existing investment in hardware or software, so I first had to figure out what hardware and software to buy. I did enough research to determine the front-running candidates, and then did even more research to narrow down my choices. I decided to use an SQL database (somewhat leading edge in the 1980’s) because I knew we needed flexibility in extracting information from huge amounts of data. I also went with a 4GL (fourth general language — a concept that was pretty advanced for the day) for construction of the user interface for our systems.

Next I had to train our programmers in the use of these techniques. I was very much a working manager — not an administrator — so I went through all of the training myself along with my team. I needed to understand the strengths and weaknesses of the software we were using, and I needed to know enough to match up team members with areas in which they would excel.

We needed someone to design the database, and I knew that extensive knowledge of the business was required, so I decided to do the database design myself. I went through advanced SQL training, getting an understanding of how the actual database engine worked in order to optimize the data structure to get maximum performance. I learned data normalization and did enough research to get a practical understanding of when normalization was good and when real world considerations suggested that extreme normalization should not be followed. I also spent many hours evaluating the existing data used in the tax filing business, getting an understanding of data relationships, and constructing a database design that gave us what we needed.

Once the database was designed, I worked with my team to construct a model for transactions. Our 4GL wasn’t literally an object-oriented language, but in effect we designed objects to standardize interface design and to simplify screen construction for the programmers.

This sounds like it might have been a long drawn-out process, but in fact we went from purchase decision to a live system in about ten months. We started with basic transactions and then gradually worked up to the more complex ones, but the system was considered a success right from the start.

This was just one example. I later did similar rapid-development projects for a customer-service system, a browser-based payroll system, and an intranet-based content management system. In each case I developed enough expertise to make purchase decisions, attained enough expertise in the software and tools to be able to direct designers and programmers, and then moved on to the next need.

The Background I Needed
Looking back at the technology-related decisions I had to make in these different examples, it’s clear to me that someone without my base level of experience wouldn’t have been successful. I had many years of software and hardware experience on multiple platforms as a knowledge foundation, and so it wasn’t a huge leap for me to be able to become a temporary expert in the use of a SQL database or in a 4GL or in browser-based systems.

But I’ve also used my portable expertise in non-work-related fields, becoming a temporary expert in several different medical fields when expertise was needed to help make significant life decisions for loved ones. In these cases the most significant obstacle to temporary expertise was the language, but in each case there were probably no more than about fifty new words required to converse intelligently with medical experts in each field.

I found that my experience in applying portable expertise in IT was directly transferrable to the medical challenges I faced. The goal was to become a temporary expert in a narrow field, and to gain enough expertise to make the best-informed decisions. That goal was achieved, and my knowledge was respected by the doctors I worked with during my brief period of expertise.

Hiring a Portable Expert
It’s common practice to hire an expert for certain projects which require experience in a specific area that is unknown to us. Most companies will hire someone who has done exactly what you want to do using the tools you’ve chosen to do it. The result will almost always be mediocre because you’re hiring people who are in a rut. They have done the job so many times that they’re on autopilot. They will do an adequate job but not an exceptional job, because they tend to force a standard solution on you instead of tailoring a solution for your unique needs.

I prefer a different approach. I look for people who have the right base level of knowledge together with portable expertise — people who are experienced in becoming experts in the area in which they need expertise at the moment. They don’t just apply cookie-cutter knowledge, using a one-size-fits-all approach. Instead they look at the specific needs in each specific situation, do enough research to figure out what should be done, and then develop the expertise in that area to be able to optimally solve the problem.

When looking for a portable expert, I look for people who have skills and experience corresponding to the two secrets I mentioned in the prior post:

People who have broad experience in the general area, using a number of different technologies in a number of different business situations
People who have demonstrated portable expertise in the past, achieving temporary expertise in a technology and/or business area, putting that expertise to use, and then moving on to the next challenge

Advantages
I’ve found that I get better results hiring portable experts than I do hiring highly specialized experts. With a portable expert you have the advantage that:

You won’t try to fit a square peg into a round hole just because you have an expert in square pegs
You’ll get a good solution even if requirements take you away from your original definition of need
Your solution can evolve in a different direction rather than be constrained by the expertise limits of the original team
You’ll usually find that your result has a lower cost because you can exclude some components of the typical one-size-fits-all solution from your implementation and just do the things that are important

The overall key is flexibility: you’re not locked into a specific approach just because you’ve hired a particular type of expert.

Build Your Own Portable Expert
Portable experts don’t always come from outside your organization. You can build your own portable experts by implementing a few simple business philosophies:

Rotate your people through different jobs in different areas. Give them a broad exposure to the business and to different technologies.
Train your employees to recognize concepts in the work they do — not just to learn procedures by rote. Help them understand why things are done the way they’re done, and what would happen if things were done differently.
Teach people how to do technology transfer, and take learnings from other technologies or industries and adapt them for the use of your business. To understand technology transfer, they need to understand the concepts underlying the use of a technology. This means you need to hire thinkers — not just people who follow directions.

Portable expertise is like taking a single tool and replacing it with a Swiss army knife. It gives you a way to maximize your success without having to constantly switch from one hired consultant to another. It lets your business “travel light” and get the important things accomplished quickly. And using internal portable experts gives you continuity in your business processes, and lets you evolve your business in reasonable steps instead of jumping from one solution to the next, making drastic changes at every jump.

Conclusion
The next time you are about to bring in a specialized expert, consider whether you can use a portable expert instead — maybe even someone within your own organization. You might find that portable expertise gives you a more satisfactory solution at lower cost. And you’ll certainly appreciate the flexibility that portable expertise gives your business.