Home 
CM Journal Articles Tool Purchase Afterbirth
CM Journal Articles Tool Purchase Afterbirth
|
In a quick list, here they are:
While it's not the first step in the sequence, training is by far the most critical item to pay attention to. Development staff, or testers, requirements people, and whomever, will tell you they don't have time to learn "your" tool. Give them a 15 minute overview, they say, and they'll figure it out. They're intelligent people. No need to waste time. Do NOT let them do this. Whatever tool you chose is more advanced than the corner ATM and it will take real training to understand not just how the tool works but how the tool fits into the lifecycle. Everyone is under the time gun, but full training now will save hours of frustration for both you and the others down the road. Push as hard as possible to get them to set aside 1/2 day or whatever it will take to cover the material and let them practice. And do not allow the training to be generic. You are asking the staff for their time; teach them how the functions will be used in their own lifecycle. Integrate naming conventions, IDEs, and other local customs into the training so they will recognize what they need to do appropriately. You should provide several training sessions so that you are not asking for the whole team to be offline at the same time. Secondly, create specific documentation for them. Your vendor may provide basic documents that you can model but you’ll need to give your users all the common features in their own language(s). Make sure you include a glossary that helps convey the differences between their own vocabulary and the way the tool uses a term. You don't have to recreate the user manuals but you will want to hit the most used functions. And make the vendor documentation available to them as well. These are intelligent people who can learn advanced functions and it will save you a good deal of time. Those two steps alone are, in my experience, the very best things you can do to help transition people into the new tool. It allays the fears and gives them something to consult when they are coding/testing/documenting at 1:00am. Rolling out the tool will require significant planning, no surprise there. More than likely, you have multiple project teams working on different products or variants. You not only need to choose which product to hit first with the tool, but determine which landmines to avoid. You may not want to hit the team with 15 product lines right out of the gate. Remember that unless you or your staff have significant experience with this tool, you will also be learning a lot as you roll it out. Personalities also play a part. Sometimes it's good to start with the most recalcitrant and outspoken opponents first and win them over. Other times, those same personalities will never be convinced by you so you need to roll the tool out (successfully) to other areas so word of mouth can make your job easier. They will tell you dozens of ways the world will end, and if you have done your homework, you already know the tool will take care of them. Sometimes those issues only occur once every few years and a work around can be managed. Timing will be very important. Converting a team 2 weeks prior to production release will not win any friends unless they themselves are begging for the new features. Even then, it's probably a bad idea. Not that there is ever a great time for upheaval but you can work with the teams to identify points in the organization's timeline that will be reasonable for all involved. Ensure the leads are fully aware of your time tables for training, file imports or conversions, and first day use. While you bought a tool that will work with your lifecycle, go back over it. There are probably areas where you can simplify the process with features you didn't fully comprehend during the demos, training, and set up. For example, do you need an approval if you are also doing a promotion/release at the same point? Wouldn't approval be inherent in promotion (assuming the same group)? The tool is supposed to make everyone's life better. Look at the tool from each user's perspective to see if there is something that can be made easier. Perhaps a traditional step can be removed because it's inherent to the tool in some fashion. This leads us to automation. Certainly the tool will have all sorts of wonderful bells and whistles that will make your job easier but is there more you can do to uniquely accelerate things? You might devise some command line scripting that will ensure timely baseline reporting or release automation. Every step you put in an automated process is a potential failure point removed. Control is a point that shows up early in the process. How much access to the tool do you allow users to have? Can you allow delete functionality without endangering traceability? In many cases, organizations are going from a lesser controlled environment to more controlled, regardless of your methodologies. Have you defined the roles that will make sense both to the tool and to the organization? And while it would seem blindingly obvious, do not allow another organization to own administrative access to the tool. Occasionally it falls under the guise of application management or some such nomenclature where a group who does not directly support application development controls the tool. It will make your life vastly more difficult. Most tools for which you spend good money will have reporting functionality. This is a gold mine for you. It may be an uphill battle to get the various areas to use the tool but if you ensure that senior management is getting the kind of information that intrigued them during the purchasing decision, you can pull their weight onto your side. Particularly if you can get them to rely on the data, they will become your spokespeople to the lesser inclined teams. Set up a playground in advance where users can tinker with the new tool. It will give them a comfort level they will need before being thrown into the tool on day one. You may need to pull multiple groups into it because the best results will come from being able to see the lifecycle in motion, rather than just from one perspective. This will also bring much needed light on unanticipated problems and keep Mr. Murphy at bay. Your tool may integrate with several others to make users’ lives even easier. Make sure you have tested those integrations in your playground before handing it off to the team. This is your new tool and it needs to play well. The integrations may be with tools you don't know or like but everyone will look to you to solve problems. The success of your implementation tool may require it. Whether you are converting from an existing tool or a manual system, you will need to identify if and what you will import of history. Most tools have conversion scripts to pull files and metadata from other known tools if you can find them on the web or get them from the vendor. If you choose not to convert and just start fresh you will need to maintain the original archives for some period of time as people do their trouble shooting for application problems. This decision may be a function of space availability, projected growth or even the currency of configuration items being managed. Management will always want to know how well their spent money is being utilized. Make sure you identify your milestones and quantify your success. By January 15, we'll have converted 80% of the applications/modules into the new system. By June 1, we'll have 4 of the 6 geographic areas up and fully running on the system. It provides a challenge to yourself and a way to show your own success. Keep the milestones to a reasonable amount. Three milestones will likely be too few unless you have a small shop but two dozen is too many for a senior management report. And this is not a time for optimism, because it may not benefit you or the organization. Dr. Nash (A Beautiful Mind fame) was correct in asserting that success comes from doing what is best for both you and the organization. That kind of optimism may be what the boss wants to hear but may crush your credibility in the long run. Before you roll the tool out, ask one important question: why did you buy the tool in the first place? Have you satisfactorily resolved the problems you were hoping the tool would handle? Are you competently managing all the functions of the old system? Reread the analysis papers you started this whole process with and make sure you understand what others were expecting from this tool. The final thought to leave with you is to plan for change. You will most likely not strike gold with the first swing of this new tool. Know your vision and what you are trying to achieve and then allow that vision to work the way the organization can best benefit. Plan for periodic reviews of both the tool and the underlying processes. Join the vendor's user support groups to see what other groups are doing with the tool. As brilliant as CM Journal readers are, it's possible we won't conceive of every variation that will help us and our users. Remember, they are customers and they will change tools, products, and processes of their own. Make sure you can respond to them. There are no magic bullets for bringing a new tool into an organization. You will see problems. You can never plan for all eventualities. But learning the lessons, often learned the hard way, from others is an easy win. Each of these steps will provide a small step toward successfully deploying your new tool. Choosing the tool is still a long distance from putting it to use. Good luck. Randy Wagner is a Contributing Editor for CM Crossroads and VP of Technology Development with Taylor Bean & Whitaker in Ocala FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at SR_71_98@yahoo.com.
Set as favorite
Bookmark
Email this
Hits: 5990 Trackback(0)Comments (0)
|
| Last Updated on Sunday, 05 August 2007 17:14 |
TrackBack URI for this entry
Subscribe to this comment's feed