Category Archives: Business Analysis

Enterprises – Ignoring users is killing your software adoption!

Published originally on medium on June 12, 2017

If you lead any kind of software delivery team as an executive, manager, leader, or whatever title makes you happy, take a moment to meet your delivery teams and tell them this: “..keep up your work, just remember that whatever you are building, only 25% of it is going to be really used…”

What do you think their reaction will be? In today’s enterprises, it’s a reality. There is a lot of waste: of effort, money, and creativity.

Especially, in large organizations where we have:

  • Removed the involvement of users who really need help to solve their problems
  • Added layers of communication, documentation, and processes to capture their needs, that in turn are handed over to somebody else developing the solution (with little to no context of the problem)

During my first decade in IT, I was very proud of the software solutions I was responsible for: as a developer, business analyst, and project manager. Had I known only a fraction of it made any real difference, it would certainly not have helped my motivation. I have met product owners who have NOT seen, met or had any interaction with the users that they are building the solutions for.

Agile software development tries to address the gap but, in my experience, many organizations fail at it because there is no direct user involvement. Unless the delivery teams meet the real users, they simply cannot relate to what problem the users are facing. If you don’t understand a problem, how can you solve it? Direct interaction with users helps uncovers hidden assumptions, provides the overall big picture and specific context, pains, gains of how their actions impact the business.

At times, the problem doesn’t even need something to be done by the software! Yet, we form layers of communication channels to capture user’s needs, wants and requirements and pass them through multiple teams until it reaches the delivery team — convoluting and diluting the real needs. Some enterprises provide the excuse that their users are too busy to provide inputs to the new effort that will make their lives better. (Where have I heard about it…Oh, wait!)

Picture courtesy: Alalia Lundy

Delivery partner(s) and their teams are often brought in as an afterthought and are handed over deliverables (requirements or user stories) to craft the state of the art software solution, with latest and greatest technologies.

Jeff and Josh mentioned about this problem in their book Lean UX.

From: by Jeff Gothelf & Josh Seiden

In the recent decade, using more and more of lean software development approach, UX (User eXperience) and modern business analysis skills, in conjunction with working side by side with users, taught me a lot.

It starts with empathy.

Empathy is the ability to understand and share the feelings of another.

We need to empathize with the users, be in their shoes. Ask yourselves, how can a person sitting in a cubicle, who has never been a part of the domain in question, can understand the needs of a user (Example: a bio-technician, a warehouse worker, salesperson etc.) who is using the software in a particular environment?

Empathy is a life skill that everyone in software needs to acquire. Some people are naturally skilled and it, others need to work at it. Understanding users and what they want is a laborious and tough skill, but one worth acquiring. Only by empathy can we create better software that has a higher user adoption rate.

One of my projects was about providing an on the ground sales team access to their data in a convenient format which they could easily update. The customer decided to move off of a commercial off the shelf (COTS) product as it was too cumbersome to use and configure. During the initial discussions of the project, we were told by the customer leadership that they wanted to have a custom built solution to tailor to their user’s needs.

Challenge was, they did not think it was important for us (delivery team) to get to know the users. It took a lot of convincing of the immediate leadership to get us access to users. Once our (User eXperience) UX team did their research and analysis, the same leaders were surprised to find things that they were completely unaware of:

  • The sales reps were not at all using the COTS product and hated it
  • They instead created shadow excel spreadsheets to help themselves track their numbers
  • Each group and every person had their own different versions of it
  • These reps spent lot of time creating and maintaining this data, spent time coordinating with other teams and still had data reporting issues

Once this detailed research was shared with the customer leadership, we saw an immediate change in their attitude and approach. A year after delivering the solution, when I checked in with the IT management we were interfacing with, they were beaming with joy and shared that the delivered solution had a very high adoption rate. The simplicity and usability of the solution had spread throughout the company and that application is one of the most successful deliveries in their company history.

I can cite more examples of success when users were involved early on and failed projects where users were an afterthought. Sometimes the user themselves don’t know what they want!

It is an iterative process, an art to research and explore what the users want. A process of skillfully drawing out assumptions and validating (or invalidating) them using multiple tools in your pocket — continuously throughout the delivery.

In my experience, when we focus on the following:

  • Do we really understand the problem?
  • Does the proposed solution solve the issue?
  • Just don’t take the information on its face value: Challenge and improve their processes, enhance the experience
  • What impact does it have on their lives (and in turn the business they represent)?

In the end, remember that business is engaging with delivery partners to solve a business problem. Business is operated by the users, involve them as early and often as possible.

So next time when you hear in your enterprise projects that “..we will have to work without involving the users directly..”, I hope you will challenge that stance and help initiate the dialogue about why user involvement and input is necessary, beneficial and economical in the long term.

Leave a comment

Posted by on June 22, 2017 in Agile, Business Analysis, UX


Customer engagement – The hard stuff

Dealing with difficult customers

Dealing with difficult customers

Customer involvement in any project is very important. But customers also are humans and you can rest assured that with every new project – the way it is unique, your customer experience WILL be unique; either pleasant or unpleasant. Things can get very challenging, if you meet a customer who is controlling and/or unwilling to commit. Even worse: sways the users/team to “rollback” their decisions.

In recent past, we started to have problems with scope definition with our customer and the initial sessions turned unproductive. So our project management team got together internally to assess the problem and possibly rectify it. It was necessary to identify the “type” of customer and I started looking for some answers/similar experiences. I came across Mike’s post on customer engagement. As Mike suggests, customer engagement will get productive if your customers can be identified by “CRACK” acronym – that stands for:

  • Collaborative
  • Representative
  • Accountable
  • Committed
  • Knowledgeable

In our case, the controlling customer manager was just a R (Representative of the team) but missing everything else. The users were afraid and unwilling to express their needs, decisions and concerns in front of the manager. And we were expected to understand and rectify the business problem. IT team tried few tricks like JAD sessions, One-on-one discussion with the manager to help the individual understand importance of scope finalization and moving ahead. Things went 1 step ahead, but 2 step back.

Direct communication was not successful and we were not in a position to bypass the manager. In this case, the one trick that worked for us was:  Questions/Surveys. We developed a 2 page survey and distributed it to the whole customer team, including the manager to define the scope.

The statistics that came back from the survey helped us show the manager the actual needs and to arrive at the scope for the project.  This experience reminded us that: It is not just your analytical skills and technical expertise that are important. Dealing with difficult individuals and especially customers can test your people skills. You will need to reach deep down in your bag of techniques and experience to handle such situations.

Your patience, collaboration and interaction skills will be tested. Only experience can help you successfully navigate such situations. Connect, talk and try finding the answers with people who have been through such situations.

Because –  Soft stuff (skill) is the  hard stuff.


Posted by on December 25, 2010 in Business Analysis, Project Management


Tags: ,

%d bloggers like this: