board, and at the same time gain meaningful feedback.
If you're writing a custom tool for the organization this becomes even more important. Understanding the customer mindset and approach can drive meaningful feature development; much like with the Scrum Development Paradigm, your goal is to bring the customer as close as possible to the development, again gaining meaningful feedback. Soliciting and incorporation feedback as part of feature development is a great example of relationship building that will drive tool acceptance. Users like nothing more than to see their suggestions are considered; at the very least provide feedback on every suggestion you receive from your internal users. Developing a rapport with these internal customers means a much higher likelihood of a tool's acceptance into overall process, regardless of whether it is written or acquired from an external source.
But most importantly, if you're going to champion a solution, you have to live it and love it. Find a way to integrate the tool (or even a portion) into your process, your daily life. Share your passion and enthusiasm for it, find others that will need your tool, or that might just want to play around. Every development organization was people who like toys, and custom tools; those people are the target of your enthusiasm. Your enthusiasm, and your passion are the keys to championing your solution with customers. Approach and attitude are just as important as audience.
Provide Training and Guidance
The easiest way to close the loop, and encourage tool use involves training. Write documentation, run a class or two, post an internal video! By providing ongoing training, and acting as a resource, you help the organization absorb the tool. Unless users know what tools are available, and where to find them, they'll never use them. Once a tool has been "in the field" (or in our case, deployed internally) for a period of time, run a refresher class. Reintroduce users to the tool, and introduce new users to the tool. If applicable, show off some advanced features.
More importantly, revisit your users use of the tool over time. Just like during the initial phases, ask about pain points, try to understand rough areas, and see what you can do to smooth out the lines. By being the champion we've discussed, you can help provide constructive feedback to the tool developers (even your own team). This can only help improve the tool's use experience, and acceptance.
Wrapping it Up
Changing a workflow and having a tool accepted in an organization isn't an easy task. But, with perseverance, engagement, and your eye trained firmly on the customer, it's relatively easy to achieve. The key, is to remember that the customer comes first, that as SCM professionals our focus is on our customer, and improving their environment.
Remember to keep your focus on the customer. Understand the customer, focus on their needs. Developer or procure a tool the improves their environment. Finally, develop the internal customer, with the goal of improving their workflow. At the end of the day, we need to make our customers a happier group of people!
Chayim Kirshen is the Build Manager at PlateSpin ULC, a Division of Novell. As an experienced professional with over a decade of experience, his prior engagements have included the Telecommunications, Financial, Healthcare, and Education sectors. Chayim manages a combined build and release engineering team, planning and developing with a SCRUM development process. He loves GNU Make, NAnt, and breathes python and revision control systems. Chayim can be contacted through his website, http://www.gnupower.net , or at email@example.com .