Worldwide travel sounds great, until you have to do it in coach, flying for 24 hours to get to where you are going. Then it becomes a pain in the rear (or back, or leg, pick your stiffest joint after sitting like a sardine for 24 hours). This post isn’t about whining about air travel, it is about learning new things, and seeing how our customers use things in new and interesting ways.  I recently traveled to India for our India Innovate and VoiCE conferences, and while I was there, I heard many of the same types of issues and challenges from our customers in India.  Many of these challenges have to do with what you might think of as the MENTAL infrastructure required for a Jazz deployment.

Why Won’t They Use It?

One of the interesting things that I kept hearing our customers struggle with is in getting people/teams to adopt the CLM/Jazz solutions. The teams seem to get overwhelmed with all of the options available to them, and often struggle with how to get started and best use the tools. After hearing this multiple times, I thought that it might be a good idea to share some of things that I have seen work for our customers who most successfully adopt the Jazz tools.

Keep the process simple

It is easy to fall into the trap of trying to implement a lot of process control in Jazz. Don’t fall into that trap. Keep the process enforcement loose, with simple state models and a limited amount of restrictions. This way you can support a variety of teams with a common process template. For those teams that want more process enforcement, have them do it by creating “bad behavior” queries. A “bad behavior” query is a query that looks for conditions that a project wants to enforce (like no delivery without approvals). Having a widget that alerts a manager to bad practices allows the leader to address the situation with individuals, and also allows them to ignore these rules for exceptional situations. It also allows teams to adopt process enforcement based on the maturity of their team, the type of project, and their specific business situation, without having to change project templates or tooling customizations.

Share a Roadmap

One of the greatest strategies is the use of what I call a usage model. A usage model covers the basic use cases for the various development roles as they develop their software. If I am a developer, how do I fix a defect? How do I know what to work on next? A high level (no need to get super detailed) guide that let’s people know their workflow does two things. One, it lets everyone know that you are concerned about their role, and that you have thought about how each role will do their work, and written down some basic instructions for them. This builds confidence and reduces the fear and anxiety that many have when having to move from the tools/processes that they used to know. Two, it can serve as a small easy to consume reminder that developers, testers, analysts and others can use as a reference. Think of it as one of those “for Dummies” guides. Keep it simple, and at a high level, so people can see the bigger picture.

Adopt in Phases

Organizations can only absorb a limited amount of change, without losing effectiveness. Role out these changes to teams in waves of adoption, do not try to get everyone to adopt at once. As time goes on, your previously adopted teams will help your newly adopting teams, and you will begin to identify best practices for your organization. Having too many teams attempting their initial adoption at the same time will overwhelm your tools administrators. By staggering the adoption of the tool and process changes, you manage to level the workload that you are placing on your tools support infrastructure (both people and hardware).


Organizations that follow these three rules will typically have much smoother rollouts of the Jazz capabilities to their organizations. These rollouts involve organizational change, in terms of tools, process, and often development methodology, so they require careful management. Getting people to change their habits can be a challenge. The organizations that focus on changing these habits often see huge improvements in the quality and quantity of work produced by their development teams.