Got an Idea? Put on your salesman hat!

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.

1. 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.
   
2. 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.
   
3. 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.
   
4. 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

• Four Secrets to Becoming a Rising IT Star
• Made to Stick: Why Some Ideas Survive and others Die by Chip Heath

Team Foundation Server Initial Implementation Strategy - Overcoming Inherit Obstacles

Although our company is currently going through the approval process for purchasing and deploying Team Foundation Server (TFS), we have already gone through an Application Life cycle Management review and have begun the process of conceptually applying some TFS features against some of our challenges.

One thing is for sure. TFS is a tool that can help just about any company that has an IT component become more efficient. However if you are thinking about venturing into these murky waters you have several obstacles to overcome.

Certainly you will have to deal with those individuals who are averse to change. Everyone knows people in their organization who are comfortable in their current process domain and are afraid that a change may introduce some discomfort, or worse are limited in their skill set and are afraid that a new process may expose some of those limitations.

I think it is critical that before you introduce TFS or any major change that requires adaptation and adoption you should ensure to those individuals effected that you EXPECT there to be some training and that they should not be afraid of venturing into uncharted territory. In fact the only way to learn new things is to get out of that comfort zone.

---

"By nature man hates change. Seldom will he quit his old home till it has actually fallen around his ears.... ...Thomas Carlyle (1795 - 1881) British historian and essayist

---

If you are able to get beyond the change adaption/adoption hurdles, you still have a long way to realizing your goal of implementing TFS, but I can't overstate the importance of these first hurdles.

Once you get everyone on board and excited about the prospect of finally having a single place to store your code and work through your development tasks, (well, maybe not everyone) you need to analyze and evaluate your current state in the area of source code management and application life cycle management. The first thing to do is inventory all of your digital assets and determine which ones are candidates for improved management. The obvious candidates are your source code libraries, however some may want to consider the prospect of storing associated documentation for your projects including UML docs, requirement docs, and perhaps even legacy project plan and sprint documents if you are in the agile world.

Once you have determined what you would like to see migrated over to TFS, you should prioritize the individual artifacts and move things in an organized and phased approach. I do not recommend moving everything at once. This would probably not be worth the effort since I am sure there is code out there that you will never need nor want to see again. It would also delay the actual prize of TFS which is using it in your current projects. Finally there is something to be said about starting with a fresh slate.

In our situation we had dozens of source code repositories located all over the globe, including on users desktops so we did feel that it was a good idea to bring everything into TFS. Note that there is a limit to how many projects you can setup in TFS so I recommend placing all migrated source outside of any project. Also because of this constraint you should be careful about trying to divide large project into too many smaller projects.

From Microsoft TFS site --- [Team Foundation Server can support a maximum of five hundred (500) team projects if you use the MSF for Agile Software Development process template for project creation. Team Foundation Server can support a maximum of two hundred and fifty (250) team projects if you use the MSF for CMMI Process Improvement process template for project creation. If you have more than five hundred MSF for Agile team projects, or more than two hundred and fifty MSF for CMMI team projects, you must deploy more than one Team Foundation Server]

In addition to your source migration, it is a very good idea to use a single prototype project as your first foray into TFS. You can use this as an opportunity to find out which features you will want your organization to use and which ones to avoid. In addition you can act as the guinea pig and document where you mess up. This will help others avoid your pitfalls.

Before you start your prototype, you should also go through the two process templates that are included with TFS. These are CMMI and agile. You will likely find that there are missing pieces in these templates and you can and should modify them via their XML definitions. Specifically, you should make sure that your measures align with the PM's measures. If not, you may get some complaints that the tool is not very helpful for the PM's and BA's. It is critical to consistently demonstrate value on that side of your IT organization or you will have trouble establishing a business case for future technology.

All of these recommendations are meant to help you avoid the common problems in all new IT initiatives. There is no question that TFS can provide significant value to your organization. These include efficiencies which should bubble up to the overall bottom line. But you need to remember that sometimes you need to help prove out the value because the perceived value is sometimes what matters in these early stages.

ref: Team Foundation Server Planning Roadmap

Language Agnostics

Wouldn't it be terrific if there was some lowest common denominator in speech language? Wouldn't you love to be able to go to Italy, France and Russia and be able to communicate without relying on embarrassing hand singles to find the nearest bathroom, or ever magnified head affirmations when you get a response that you don't understand?

Well, that probably is not possible in today's world and may never be. If you want to go to Italy and communicate, learn the language.

Fortunately in the programming domain, we do have that lowest common denominator in several areas of information technology.

I have been preparing a demo of Sybase Powerdesigner for the folks here and in addition to modeling tools that allow IT to communicate with the business in a meaningful way, it also allows us to write the bulk of our applications without specifying what language it is in.

As an example, for this demo I am going to show how to build a Conceptual Data Model. This is sort of the first step in the modeling process and can be created from Business Requirements and conversations directly with the business.
(Powerdesigner allows you to create Business Process Models (BPM's) that can generate your conceptual model. However for the scope of this conversation we are assuming that our interaction with Powerdesigner starts with the CDM.)
The CDM is where we build our entities and define the relationships (foreign keys) and some of the attributes of the entities.

From there Powerdesigner generates my Logical Data Model. You do this by selecting the option to generate a Physical Model, however instead of choosing a DBMS, you chose Logical Data model. From here we can define our indexes and our primary keys.

This is where we can stop, take a bow, and thank the modeling gods for allowing such a spectacular idea to surface in all of its glory. We have just created a language agnostic database. Or more specifically we have generated a DBMS agnostic model.

What Powerdesigner has done for me is collected the common concepts and features behind a databases meta data and made them available to me in the Logical Data Model. I am now King Kong. I can simply push a button and generate the code for a SQL 2005 database, SQL 2000, IBM DB2, Oracle 7,8,9 or 10, My SQL in 5 different flavors, Redbrick Warehouse, and a just about any other DBMS you can think of. How cool is that? Very cool.

Now the task is to get the rest of the IT team to embrace the concept and the value of bringing the abstract concepts discussed here and Language Agnostic modeling to generate code. Although I have only discussed database here, Sybase has the same ability to generate Language Agnostic classes which can create my code in any language I want.

I would be interested in others who have had to sell this concept and those who have been disinterested in embracing this type of culture.

More Team Foundation Server Business Case Talk

Here is a piece of advice for those of you who are trying to build a business case for TFS and are currently using VSS for source code control. Don't use as your sole business case the fact that getting licenses for TFS is cheaper than continuing with the licensing for VSS.

I know this is not true for all as Microsoft has a floating cost structure and different companies pay for different things. However in our case there was a significant cost savings by switching over.

I spoke with Microsoft reps and MVP's for TFS and most say that their customers are switching mainly for the more robust and reliable of the transactional approach to version control that TFS has. Further the ability to decommission VSS is the most compelling reason they have heard.

While all this is good and well, many companies have the problem in that the business has to approve work that IT does. It is hard to convince someone who is getting pressure to build the next great system for managing their sales force that they should instead spend on a product where the immediate benefits are not directed to the business in a way that is easy to communicate. I know, because we tried that approach and although it hasn't failed yet, it certainly didn't blow their skirt up.

If I had the ability to start over, I would not focus on version control at all. I would focus on the features that provide the most direct benefits to the business. For example I know that TFS allows for the development process to be more transparent. To me this is a huge benefit to the business. Instead of spending countless time with the business facing side of IT trying to determine percent complete on the different deliverables in a project, they can get those reports through SharePoint in a second. Further they can see quickly if projects are going out of scope, find out if they can reign things back in or if the scope creep was necessary. If so they can communicate this to the users requesting the new system and have documentation ready that explains the added cost.

Cost savings is another things that I would try and drive home better. I would not focus on the licensing cost savings at all. Instead I would try and champion the need for tighter code management, code reuse, and code consolidation. Instead of trying to manage dozens of different code repositories, we would only need one. If a developer is looking for some help in some area of functionality they can search for other code that may help them because now it is all in one place. And if I want to establish a culture of Object Oriented development techniques and have put in some standards, I have a much better chance of monitoring adherence if I can see all checkin's that are going on.

Hopefully someone will chime in on their war stories of trying to get TFS approved.

Creating a Business Case for TFS

Our company is struggling with our suggestion that we adopt TFS as our developer collaboration and repository tool. They are struggling becauase we are not 100% Microsoft shop. We use Java, ISeries and Oracle. Let's discuss some good business case points that we and others could use to help roll this out.