The Key to My Success: User Interaction

A couple months ago, I wrote about the importance of development teams and the business areas working together (Development and the Business - A Partnership).  This is a topic that I've been thinking about quite a bit recently as I review the applications I've been involved with.

The applications in my career that I consider to be most successful are the ones where I was constantly involved with my users.  There are other applications that have had limited user communication that have resulted in successful applications, but the process was extremely painful.  A couple of applications fall into the failure category, and these happen to be the applications where I had zero user contact.

This lines up with two of the four points in the Agile Manifesto:

o Individuals and interactions over processes and tools
o Working software over comprehensive documentation
o Customer collaboration over contract negotiation
o Responding to change over following a plan

These are elaborated in the 12 principles behind Agile.

So, let's take a look at some of the successful and not-so-successful projects I've worked on and why I consider user interaction to be a key component in what has worked well.

Just a quick note about my terminology: I would normally refer to people by name (since they are people).  But to keep things (semi-)anonymous, I will refer to someone as the "user" or "super user".  This is simply because I can't refer to them as "Frank" or "Janice" here.

My First Project - The One that Wouldn't Leave
I actually got into development as a profession almost by accident (I'll say almost because I wanted to be a developer and was looking for ways to break in, but this opportunity came up by chance).  I was on the user side of a multi-year project to build a system that would consolidate information from different departments around the company.  During the pilot phase (that is, figuring out what we wanted the development team to build for us), I got to know all of the people in the various departments that would eventually be using the system.  We were collecting the information manually and figuring out what we needed for incoming fields, approval processes, and outgoing reporting.

During this process, the manager who was working on the developer side of the project saw that I had some qualities that could make me a good developer.  So, about a year into the project, I was offered a junior developer position.  And that's how I got started.

Now, originally, the project had a team of about 6 people, and I was doing the types of things that you would give to a junior developer at the time: slinging around a bit of HTML and learning how to write Crystal Reports.

Fast forward a bit: the project is released, the senior developers go on to other stuff, and I end up as primary support for the application.  This made sense since a lot of the issues that came up were odd behavior related to reporting or some of the SQL behind it, and I could always ask questions of the original developers.

But it turned out to make sense for a much bigger reason: I knew the users.  Since I had spent so much time working with them on what the system needed (i.e., gathering requirements), I had built a relationship with them.  And I ended up supporting this application for close to 10 years (until I left that company).

A Couple Key Wins
The application had 2 primary pieces: a Windows application used for data entry / administration and a web application that was used for reporting.  I was given the task of re-writing the data entry application at one point, and I took that as a chance to add some things to help out my users.

The Tedious Process
The data entry application did not have any reporting at all (you had to go to the web app for that).  One of the business areas handled approvals for the items that were entered into the system.

I visited their office one day to talk about some things in the application. While they were working, something caught my eye. And it was something I hadn't anticipated.

In watching their process, I saw that they printed out a copy of an item after it was approved; this copy was then put into their files. And the current system was a bit tedious:

1. Open the data entry application to get the list of items to be approved.
2. Approve an individual item.
3. Open the web application.
4. Navigate to the Search screen.
5. Use the search fields to locate the item they just entered (and based on similar names, this was sometimes tricky).  This was generally the most frustrating part of the process.
6. Print out the item from the web application.
7. Go back to the data entry application to approve the next item.

This is what these users did for 3-4 hours per day.  I like to make jobs easier.  So when I saw this, I offered to add a Print button to the approval screen. This would take me about 5 minutes to do (I already had the code), and it would make their process much easier:

1. Open the data entry application to get the list of items to be approved.
2. Approve an individual item.
3. Print out the item from the current screen.
4. Go back to the list to approve the next item.

This completely eliminated the most frustrating part of the process and made their work much easier.

The reason I found this problem is because I actually watched people using the system.

Eliminating Data Entry
For some departments, the new system eliminated the need for them to maintain their own data.  For other departments, the new system would not be a replacement.  As an example, a department had a financial system that they used for resource planning and scheduling.  All the new system cared about was one small piece of their existing data.  This resulted in a bit of duplicate data-entry (at least to start with).

Once the new system was running and stable, we started to look at where we could eliminate the duplicate data entry.  Again, because I knew the users and spoke with them regularly, I could prioritize based on which of the business areas would get the most benefit.  If a department had dozens of items a day to enter, we could prioritize that automation over those that had only a few items a week.

Also, we could determine how to automate based on the timeliness of the information.  For items that were scheduled several months out, we could do a once-a-day import from the systems.  Conversely, for items that would result in immediate change to operations planning, we could tie more directly into the source systems for close-to-real-time data.

The Key to Success
My ability to make these choices -- the choices that ultimately affect the business -- was due to my relationship with the users in the various departments.  I continued those relationships for many years.  And when someone left a position, I went to go see the replacement in person as soon as I could (this was really easy when they were in the same building; a little more difficult if they were on the other side of the 100-acre property).  My goal was to establish very quickly that I was committed to their success.  Fortunately for me, most of the people who left positions told the new person that I was really good to work with.

The Project That Could Have Been a Disaster
One project sticks out where user interaction really saved the day.  This was a rewrite of an Access application that had been built by someone in the business area.  The application was having issues with scaling and was crashing fairly regularly.  They came to the development team to build a stable app.

I was the development lead, and my first request on the rewrite was for me to go out to the business area, do some job shadowing, and find out what they really need.  Unfortunately, that was not approved, and I was given the directive that the new application should do exactly what the old application did.

This is never what you want to hear.  In this case, there were 2 reasons I didn't like it.  First, I didn't know whether the current application actually met the users' needs.  Second, the current application consisted of about 20,000 lines of VBA code (it still gives me shivers to think about it).

I built a very good relationship with the super user.  He knew the functions of the current application, and he also fielded questions and issues from the users.  He became my source for real knowledge.

So, I dug through each module of the Access application.  More often than not, I found out that the application code was not actually doing what the users thought it was.  For example, there was an part of the application that looked at the city of a customer record and gave back the current local time for the customer.  The actual code had a hard-coded list of cities for each state along with the time zone.  The problem is that then a city wasn't found in the list, it would just pick the first city in the list.  This meant that it wasn't always accurate (particularly for states that had multiple time zones and/or multiple rules about Daylight Saving Time).

If I were to simply "do what the current application did", I would end up reproducing the errors.  If I wanted to make the function accurate, I would need to figure out a better way of getting the current time information (maybe a call to a web service?).  But it turned out to be much simpler than that: I talked to the super user.

In talking to the super user, I found out the intent of this function.  There were situations where the department would call a customer, and they wanted to make sure that they were calling within a particular window (for example, not after 8:00 p.m.).  It turned out that they didn't need the precision of a particular city, just a general idea.  So, instead of a function that would tell the time for a city, I provided a Time Zone map that showed the current time in each time zone.  This was a fairly simple solution that met the users needs.

I have many other examples from that particular application.  Time after time, communication with the users saved me from over-building and allowed me to provide a system that more closely met their actual needs.

Disaster averted.

Disaster Not Averted
Unfortunately, not all projects can be successful.  I can think of two projects in particular that were extremely difficult (and ultimately never made it to release).  In both of these scenarios, I was "insulated" from contact with the users through a project manager.

In one scenario, all of the requirements came through the project manager.  I was only given what the application should do (i.e., it should show data this way, it should print that way); I was never given visibility to the actual business issues that we were trying to solve.  I just had a solution.  And I was doubtful whether that solution was really what the business area needed.

Ultimately, that version of the application was never released (which was a frustration to me even though I only worked on it for a few weeks).  The good news is that a year later, an updated version of that project came up, and I got to work on it.  In that iteration, we were working closely with the user group and created a very successful solution.

In another scenario, the requirements were coming through a (different) project manager.  For whatever reason, she didn't want us (the two developers on the project) talking directly with the user.  I'm still not quite sure; it might have been for political reasons.  The problem is that whenever we came up with a prototype, we would give it to the project manager who would test it before giving it to the user.  When the changes would come back, we would never get the "why" of the change, just the "what".  And whenever we had a question about a particular function, it would go through the project manager and take about a week to get the answer back to us.

That project was put on the back burner several times, and it still wasn't finished when I left the company two years later.  Kind of sad because it was something that could have been very useful.  Sometimes we don't have as much control over the situation as we would like.

Wrap Up
I have many other examples from my career.  Fortunately, most of them have been successes: like the time that the project manager was someone who used to work in the business area.  Again, she had the answers to most of the questions, and if she didn't she had all of the right contacts.  In addition, she didn't insulate us from the users; instead, we had conference calls and were encouraged to talk to them directly.

I've worked on a number of different projects in different environments (at one company, I had primary responsibility for 20 applications when I left).  The projects that I consider to be most successful have one thing in common: constant user interaction.  Meet face-to-face when you can; we need to realize that we are all people, not just voices on a phone.

Building real partnerships with the business area is how I've been successful.  And I'm not sure how you can build a successful product if you don't truly understand who will be using it and what their needs are.

Happy Coding!