Want to implement an ALM process? Focus on the output!

Want to implement an ALM process? Focus on the output!

In my previous article “Implement TFS or ALM? Same or different?” , I talked about the differences between an ALM implementation and a TFS Implementation.

Today I like to talk about the change process that is involved when an ALM process is being implemented. I am totally aware that no business is the same and every organization has its own bottlenecks but the following approach helps me a lot in various implementations.

Friend or Foe?

When a decision is made to implement ALM, this usually has impact on the way that people work. As I mentioned in my previous post there are different ways how people deal with these changes.

The people who do not mind to adjust are your friends. Keep it that way! Involve them, let them try new stuff, provide quick information from the system.

Then the other group. The people who do not like changes. People in this group are technical people who just do not like TFS, people who do not like to administer things, but also functional people that suddenly have to change their tools. They used Excel, Visio, Word and now all of a sudden they need to register everything in a strange tool.

The argument that I mostly hear is that working with TFS (and thus adjusting to the process that is defined) takes a lot of time. That is partially true and is unavoidable. But why do people only feel the burden of administration?

Where does this come from?

The reason this happens is actually pretty obvious. People who define a ALM process often start with the process and the input. What is our ideal process? What do we need for that? What are the different roles? Who is responsible etc. etc. By answering these questions, the process is shaped. The way of working is extracted from the process. There are also some wishes for output but most of the times this comes from the people involved.

What people forget is that most “users” are not involved in shaping the process and therefore do not see the overall benefits of an implementation. When everything is done, they only get a manual about how they should work.

It is logical that they are a bit reluctant of using it.

Focus on output

If we want people to do things, we have to reward them. This is also very true for the problem described above. Most of us have a need for information or insight. TFS can provide this, only most implementations stop when the process is in place.

When the first drafts of your process are in place, interview all of your users (or their representatives). Ask them what information they need to make their work easier. Capsulate this in your process. Make sure that the information that your users ask for is stored in the system. And most importantly……Build reports to show it to them ! (Look here for my TFS Reporting Series).

Let the information be the reward. If they do not want to register items? There is no information available. But probably their colleagues (who were reluctant as well) will make sure the information will be put in.

When the Push is transformed to a Pull, the process can be further optimized. New reports are demanded, new information must be stored etc. etc.

Conclusion

When the focus is on the output, the process is more likely to be adopted because people do not only put data in the system but they also get valuable information out of it. Another advantage is that once reports are defined, the information must be present in the system. Because the information must be present, people must follow the procedures to fill in the information correctly.

Try to involve people up front before the complete process is finalized. Sometimes a few bits of information can turn foes into your best friends!