As you know, here I try and promote the concept that building a foundation within your IT department that will allow you to setup standards, enforce them, and to ultimately give your development team the structure they need to succeed and to respond quickly to the business needs without sacrificing Object Oriented principles. Whether your IT staff is offshore, on site, or some combination of the two, there are common principles that apply that will ultimately help the entity you support save money by lower development costs, and ultimately better business tools.
From the feedback I receive, there is one common thing that is almost always overlooked. Selling these principles to the business sponsors.
I use the term selling loosely in that it can mean selling the idea of purchasing a software utility that can help you become more efficient (i.e. TFS, MOSS, Wiki) or selling a change in a process. I used Wiki as an example because sometimes selling new software is more about implementation planning and time as it is the actual cost.
Let's consider this fictitious scenario:
A company's IT department has some good architects and designers in various parts of the world, each with their own set of skills and own set of ideas. Every small to medium size company always has at least a few on their team that are well schooled in OO principles whether it deals with .NET development, Java development, SQL development, Oracle development, etc. Typically these developers are used more to keep the wheels on instead of leveraging their skills to help the IT department as a whole become more efficient and structured.
Let's say the SQL developer (we'll call him Corky) has an idea to create code blocks for common routines that are called from various applications but in different ways. He figures it would take him about two days to develop and test the code blocks in his scope and maybe another day to draft a technical document describing its usage. Being that he wants to follow the process of running ideas through the proper channels, he proposed the idea to his manager (Kim). Kim said it sounded good, but she wanted him to present the idea governance board for approval with her. Corky did the presentation and after being unable to answer questions regarding possible issues with certain environments and the implementation cost to each application that utilizes his new code blocks he got a big fat NO.
I think this has probably happened to all of us. You have a great idea that seems like a no brainer, taking to the approving body, and they turn it down.
The problem is that most of us in IT are poor salespeople. We fail to look at things from the business point of view. We know that our idea will help them in the long run, but we need to understand that they are thinking about what can help them today. If they know you are spending three days working on code blocks, and that other developers will be tied up implementing your idea, they see this as taking away from their current ongoing projects that are more closely tied to business solutions.
I am certainly not qualified to give you definitive advice on how to make your ideas "stick", but here are some suggestions.
- Be good to your end users
If you need approval for an idea, it isn't a good idea to make those you are presenting your idea to feel stupid. Typically the decision makers have less low level technical acumen than yourself. Present your ideas in a way that makes business sense. For example Corky could have started his presentation by saying that he can "recover 200 man hours each year which will give us time to setup that email notification system that you wanted and that we quoted 180 hours for" by implementing his code block idea, instead of saying, "this will standardize our SQL process". See the difference?
In addition, always treat your end users and business sponsors like a customer who gets the full service treatment. Respond quickly to their requests whether or not you can help them right away. Try not to pass the buck. Take responsibility even if the problem is not in your area or focus. It will payoff in the long run. - Go beyond the walls of IT and learn the business
I probably should have put this in front of number one, for in order to present things in a business sense, you have to understand the business. This is a good idea and goes beyond the scope of making your ideas stick. If you don't understand the business, you can't deliver optimum technology solutions.
To understand the business, try to inject yourself into as many meetings and projects that require heavy interaction with the business. You can also use problem/resolution moments to get to know the business users. If you have been involved in delivering a business solution, make sure to check with the end users periodically to see how things are going. In fact you should probably setup periodic meetings. Ask them how everything else is going. Maybe you can learn things that you don't know. Finally, you should always read everything you can about your company. Whether it is their quarterly financial report or their newsletter. All of things can help you learn the business. - Understand the organization's structure and goals
In addition to understanding your organization works and operates, you need to have a good understanding of their goals. This involves becoming intimately aware of the culture of the company. What does it stand for? What is their vision? Do they want to go global? Are their immediate concerns financial in nature, for example cutting costs? Be careful here. You cannot base all of your ideas on what will save money. One of the functions of any successful IT company is to create value that helps differentiate the business. - Build trust with your boss
For fear of impugning the above three points, I will not say that this is the most important thing you can do to help to make your ideas stick. Oh what the heck, I will say that.
If you have a good idea that you want to implement across the IT organization, sooner or later someone will ask your boss about the plan privately. If he doesn't trust you, you can forget about getting anything to stick. It is critical to always be honest with your boss. Never try and BS him or her with technical jargon that really doesn't make sense. Surprisingly I have found many who simply dismiss anyone who doesn't write code 9 hours a day as someone who doesn't understand technology. Don't fall into that trap. It is likely that your boss understands very well the technology. Just because he or she isn't familiar with the latest way to use delegates doesn't mean they don't understand how that concept can help the software.
Also, avoid the temptation to sweep bad news about a project or assignment under the rug. It's better to over share than to under share. Management doesn't like it when information feels filtered, like something is being hidden. In that vein, it is almost never a good idea to try and go around your boss. Sometimes ambitious IT folks think they can get ahead by going around. Again, if you want to build trust you need to follow the chain of command. It will help you in more ways than just building trust.
It must be said that in the end, you have to produce. You have to have some successes in the bank that your boss knows about and this takes time. NEVER walk into a new job and start pushing for changes, no matter how obvious they seem.
The idea (pun intended) here is that putting a new process, idea, software or game plan in place needs buy in. You can't simply think something is a good idea and expect it to get adopted. That only gets you half way to first base. You really have to get outside of your comfort area and press other buttons then your used to press if you really are trying to help the company with your plans.
Here are some references
