I was recently doing some work with a client that was engaged in a very large, multi-year program that is implementing CRM, SAP, and a few other specialty systems.  The CRM development team, of which I was a member, was over 50 people and that was before it had ramped up to full staff.  With a program that large and complex it was imperative that we had structured processes and tools for managing the internal workings of the development team.  To that end, the client had deployed one of ClearQuest’s systems for risk and issue tracking and management.  While the tool was available, it was not widely, nor consistently used.   It seemed ironic that a team whose sole purpose was to deploy an enterprise application to 1,000+ users was unable to successfully adopt a system themselves!
 
I took a few minutes to observe the team and I noticed several interesting things regarding its attitudes and behaviors towards ClearQuest.  Within the CRM team there were widely different views of the purpose and usefulness of the system.  Individual’s behavior using the system tended to reflect their views of the system.

• Several people viewed the tool from a political perspective. They would actively push back whenever another team member tried to assign an issue to them because of concerns how the senior executives would view the issue.  In one instance one such person tried to intimidate the creator of the issue by saying things such as “Do you really want Mr. X (the senior executive who reviewed all issues) to see that YOU wasted their time by opening such a ridiculous issue?”  The implication (and intimidation) was clear – if you create an issue (as the creator had been instructed to do) then you could harm your own career.

• Other users adopted a “CYA” approach and opened every possible issue in the system.  What was interesting is that the nature and wording of the issues was done in such a way that it was largely perceived that the CYA users were just trying to make less work for themselves by using the issue management process to push it onto other people. The common perception was that CYA users were trying to indemnify themselves from responsibility for actually solving problems.  It was perceived that simply by documenting that they were not going to address, they problem, they had tried to shift all responsibility (and blame) for the problem onto whoever owned the issue in the system. 

• One team leader, who was very open about your lack of comfort using technology, indicated that she didn’t use the system because she had not been forced to do so by her direct boss.  She indicated that all it would take for her to use the system was for the boss to mandate it.  (I question if this is truly all it would take.)

• In a few instances certain team members (who had been on the project for over 6 months) had never been setup in the system.  These people reported to the team leader who herself avoided use of the system, and thus were never pushed to get system access.  Since they did not have system access these user adopted the position that they were not responsible for using the system.  There were several contentious discussions when other team members pointed out to the people without access that they should take responsibility for getting themselves setup in the system. 

• In one instance, a member of one team opened an issue and tried to assign it to a member of another team who did not have system access.  When he was unable to make the correct assignment, he assigned the issue to this individual’s manager (as he had been instructed to do).  The manager then complained that the issue creator was at fault for not following proper procedure and for not assigning the issue correctly, ignoring the fact that he was unable to follow the proper procedure because the manager had not arrange proper system access for her direct report.
  

While all of the work streams had some level of adoption of the ClearQuest system, one thing that I found most interesting was that the work stream that was focused on “people” issues was one of the worst adopters of the technology.  The big irony is that this team was responsible for driving the behaviors for the end-users of the CRM system, yet they were unable, or perhaps unwilling, to modify their own behavior.  This “do as I say, not as I do” mentality did not bode well for the future adoption of the CRM system they were working to deploy.

In the ClearQuest example above, the technology had been effectively deployed.  It functioned as designed.  The processes to use the system were defined and training had been provided.  There was a support organization that kept the system up and running.   But was the system a success?  Was it used effectively?  Had it delivered the value the organization expected when it made the decision to purchase and deploy the system?  I would argue no.  Sure, the system had delivered some value, but it had certainly not lived up to its full potential.  The low levels of user adoption, coupled with the inconsistent approach to how the system was used, dramatically reduced the value the system provided to the organization.  From an investment decision point of view, this reduced value to the organization had the effect of lowering the ROI the organization received on the money it spent implementing ClearQuest. 

It occurred to me that if we, as an IT development team, would spend a bit of time reflecting on our own behavior – which is something I think everyone should do on a fairly regular basis – we could learn (or perhaps re-learn) just how difficult it is for end-users to adopt a system.  We could use the insights gained from our own experiences to improve how we introduce systems and drive successful adoption of the system we deploy.  In the ClearQuest example above we saw that many of the factors impacting adoption of the system were related to individual perceptions of organizational and political forces.  Improving effective system adoption which would maximize ROI of the ClearQuest system requires us to address the non-technology and process items that are typically ignored during a technology project.  This can best be achieved by adopting organizational development activities (which goes way beyond typical “change management” efforts) as part of IT projects.  Clearly we still have a lot to learn about maximizing ROI on technology projects.  Perhaps we should start by learning from ourselves.