Customer and User Success

Is it in the system? Require IT use at each project approval stage

The other day I was talking with a woman at a large non-profit that is trying to improve their enterprise knowledge management efforts. She said that they are using a CRM system and SharePoint to manage information related to all of their internal projects. The CRM is used to track all of the people involved and track key activities and SharePoint is used for sharing and storing all project specific knowledge content.

The problem, as you would expect, is that very few people were using either tool. Sure, there were some pockets of success, but for the most part each individual or team would just do their own thing. Obviously, this did little to preserve knowledge and make it accessible for future use.

She needed help and asked me what she could do to increase effective use of the systems.

Do you have different approval stages for your business projects?

When we were talking about how they manage their internal projects, she indicated they have various formal project reviews and approvals required for a project to proceed to the next stage. The reviews are primarily to manage quality and were required in order for the project to get funding. But they didn’t actually check to see if internal processes were followed or if people were growing the institutional knowledge of the organization.

Make complete & accurate IT use a condition for project advancement

Require IT use at each project approval stage.One of the easiest things you can do to help increase effective IT user adoption is to integrate it into the workflow and approval process of your normal work activities. This can apply to internal projects as well as sales reviews.

To be effective, define very specific, measurable system use requirements that must be met in order to gain approval.

This could be things like requiring all related contacts and accounts (specify required fields) are entered, that all major pre-requisite activities are entered (specify required vs. optional activities), and that any required documents are entered. 

Also, make sure that all naming conventions and status fields are correct. This is not just an opportunity to make sure information is entered, it is also an opportunity to maintain the quality of the data.

Include timely system use in individual performance reviews

If you want to encourage regular, timely use of your systems (instead of just ensuring data is entered immediately prior to an internal project review), think about including a quick audit of created dates as part of your project approval process. If an individual did not enter the data within required timeframes  -- and thus deprived other people the ability to make use of the data in a timely way --  you can identify them and then take appropriate action. 

For example, I know of a sales professional at one organization who made his numbers, but didn’t enter the information in the required timeframes. As a result, he was ineligible for a major sought-after reward, namely attending the President’s Club celebration.There are lots of ways you can encourage (or discourage) effective system use as part of your regular business processes. How can you do it in your organization?

No idea where to start? We can help you Quick Start

Cloud IT User Adoption Services

Find out more for free with a 30-minute consult



Be part of the conversation.  Join the Customer Success Practitioners group on LinkedIn

join us on linkedin!


Book it! Scheduling User Adoption activities is a must to ensure long-term IT success.


We have all experienced this:  a round of discussions generating wonderful ideas, with a promise to reconvene and determine next action items.  The problem is those action items rarely become a reality, because there was never a sufficient amount of follow-through to act on those ideas. We know that user adoption (UA) of IT systems does not occur without deliberate action items.  Since the goal is to conduct specific activities that encourage end-users to engage your IT system as designed, we need to move from mere discussions and ideas to committed actions that promote user adoption. In order to maintain both focus and follow-through of user adoption plans, it is recommended to reconstruct your project team meetings in a way that generates ideas and creates specific follow-up actions.


For each strategy phase of the user adoption (UA) plan (e.g. analysis, engagement, learning, support, etc.) create two separate meeting times and agendas:
  1. “Brainstorming Session”
  2. “Implementation Planning”
Brainstorming Session:
  • Ascertain and list the relevant topics for that phase of the UA plan (rely not only on the project plan and initial team discussions but also on your UA consultant/expert).
  • Organize each agenda topic in a logical sequence to create a seamless and singular focus throughout the session.
  • Place specific time limits for each discussion topic, and be realistic as to what can be accomplished, as brainstorming/discussions can take longer than expected.  Therefore do not attempt to overload the meeting agenda with too many topics. If needed, consider more than one brainstorming session vs. one long session.
  • During the brainstorming session, ALWAYS include the predicted impacts to user adoption of each idea.
  • Assign specific assignments to session participants with the due date set for the following meeting: “Implementation Planning”.  Typically, these assignments are data gathering/research in nature, which shall help the team determine the implementation plan.
Implementation Planning:
  • Revisit each discussion topic in the same sequence from the brainstorming session.
  • Address the findings from the various assignments in order to decide how to best proceed.  Again, validate each decision based on predicted impact to user adoption.
  • Agree to a specific series of implementation activities to enact your team’s decisions.  This must include primary ownership and enactors of activities, time-frames, resources required, leadership endorsement and support.


As you plan for your next UA meetings, remember what the overarching goal is:  to enact specific actions that will create user adoption of your IT system.  Using the above steps can help you and your team follow-through on your user adoption ideas to create long lasting results.


Check out these other resources for more information related to this topic:



Many people blame “user resistance” as the reason why their systems are not adopted.  The prevailing attitude seems to be that if we provide adequate training and communication (often the extent of the “Change Management” effort), then it must be the users fault if the system is not used.  I like to call this the “Train, then blame” approach to User Adoption. There is an implicit assumption that user choice is the sole factor affecting user adoption.  However, when we look closer, we see that this is often not the case. 

There may be many other reasons why your people might not be using your system, and in many cases it is not their users fault at all.  For example:
  • Many times there are organizational barriers outside the users control that prevent them from adopting the system
  • Design disconnects between the technology, process and users prevent users from adopting the system
  • Conflicting priorities, misaligned reward systems, and the directives of immediate supervisors result in a situation of, “hoping for A, while rewarding B”
  • The Change Management and IT implementation methodology were inappropriate for driving user adoption
  • No action was taken after go-live to create and sustain full user adoption


Blaming poor user adoption on “User Resistance” may be convenient and it may shift the onus for taking action from you to the users, but it may not be accurate.  There may be other factors causing your adoption problems and the responsibility for taking action may fall on YOU, not the users!


  • What factors outside of the users’ control would prevent them from adopting the system?
  • Have you adjusted reward & recognition criteria to reward people for adopting the system and penalize them for avoiding the system?
  • What are the reasons (other than the technology itself) that people did not adopt earlier systems?  What did you do to address these issues?
  • Did you take appropriate action before, during, and after go-live to address user behavior and drive user adoption?  How can you move beyond traditional “Change Management” efforts to drive desired user behavior over the long term?