The Undercover Adventure (Part 1): Being a user is hard!

After 3 years of being part of an open source software development team (amongst other things) I decided to do something unusual. I decided it was time to experience life on the other side of the fence. I wanted to gain a deeper understanding of the, at times, chaos and conflict I was experiencing as a test analyst (and later manager) when dealing with the business. I realized, after many attempts to talk to a client over a phone (we supported clients in UK directly from South Africa) that not a lot of business knowledge makes it way into the software development team. Documentation is one thing, but with challenges around accuracy, maintainability and timeliness, it isn't a useful insightful way of understanding a clients business.

I wanted to know more. Much more. I wanted to migrate across the fence and just be a user for a while. I do mean user in the truest sense. I didn't want to have access to IT directly in anyway. I wanted to experience business process and attempt to verbally stroll through organization layers to find answers. I wanted to understand first hand what it is like to be a business person dealing with systems everyday and what they face in just trying to get to their work.

It's not greener on the other side.

So, it has been 2 months (3 days and a few hours) and I am deeply frustrated. No wait, let me be more accurate and less nice about it. I want to rip the phone out of its socket, walk over to the software development department and ask them in a tight lipped tone why they are being so myopic, somewhat annoying and you know, perhaps even stupid. I want to shout at them for their indifference and their lack of response. I want to ask for where their source code repository is, print out every line of code and burn it. While explaining to them that this is what a business user feels every time they encounter a bad implementation of functionality.

I want to put in a disclaimer here before I continue as I know that at times limited situational and premise context are provided in a short article. There isn't a way that I can give you full detail about the last 2 months in their entirety here, so I want to say this. The descriptions and opinions displayed here are based on my experiences and are not a reflection of what lies beyond the bounds of this context. I know that there are amazing teams out there. I have had the privilege to work with them and going through this makes me appreciate them more and how critical it is to have good, solid, well understood software development practices and involved, active and interested business sponsorship and support. It is the stuff that makes the process of building something sweet and the end result sublime.

Taking a stroll through a seemingly solid structure.

Now, to give some detail, I work as a maintenance clerk for an oil company that is in the process of starting up its mine. I am there to build up a reference archive, amongst other things, and generally be a runner and helper of sorts for the planners. The planners are responsible for the coordination and facilitation of all information that relates to any and all maintenance that has to happen on the mine. Oil mines by nature are heavily structured and regulated by the government so everything has an associated paper and approval structure. The process is outlined and you can see the workflow diagram on the walls and in the meetings room. Everyone here takes their job seriously because if something isn't done, and everything here is critical, it affects production and that is very, very bad for business.

Being a clerk has a lot of benefits when it comes to understanding a business. All that is required of me is to listen and learn. I am not distracted by having to manage people or systems (not that I mind those things, but it wouldn't have worked well in this situation). I spend a lot of time just sitting and watching what happens and noting what worked and what didn't. Within the first month a few hiccups immediately became apparent. The team (on both sides, both business and IT) are making really simple mistakes (which would be fine if they were small, but they happen to choose the most costly ones).

There are serious cracks under the surface and certain things creak.

For a week I watched one of the planners struggle with the project management/ scheduling application they use to schedule the work that needs to happen. She struggled for an entire day to get all the data together and after much effort finally managed to get the schedule together. The next day she opened up the schedule and noted that something didn't look right. The data was different. She changed everything and saved and sent it out for review. Halfway through the day she opened it for final additions and again, the data had changed.

I had a look at what had changed and immediately two words leapt into my mind and skidded to a sudden halt. Like a board with florescent lights it read "Test Data". I told her to phone the system development team lead and indeed, I was right. Someone had forgotten (a complete shocker actually) to move the database connection to the production instance and had been using her data the whole week as test data. Now this wouldn't have been too much of an issue had the schedule been for a small team to do simple tasks with no real dependence on each other. However, this is not the case. That schedule feeds several teams that within themselves keep around 29 different plants running.

After that, and a few other experiences that I will blog about later (I don't have enough space to cover all of it here), the planning team now circumvents the system as much as possible so that they can get the work through the door. Something that should have assisted them, facilitated away the silly stuff has just completely failed them. The system is badly designed, badly implemented, clumsy and always a frustrating experience.

Things are swaying on its foundation, but I don't think people realize it.

I spent a lot of time thinking about how it got to this case. I am sure that there are a lot of people working on this. You can't tell me that someone didn't raise their hand and ask loudly why they are deploying something so bad. Then something occurred to me when I started bumping into other parts of the business and I started learning about how things are decided, who makes those decisions and I realized how fluid the business is and how unclear and fuzzy the details are. Most of what has been built here has arrived out of a crises mode approach. It all "had to be done now" thinking meant that investment into the long term, such as having proper codes, proper data entry of assets, proper workflow development, proper system integration never happened. If anything, the system that is in place is a clear reflection of the state of the organization (both including the business and IT).

Systems are meant to promote and assist business value growth and be a pleasure to use. I realize even more than before how deeply critical it is have a full picture of which the end user is and what the purpose of the system is. Systems, when they are badly designed and implemented cause immense amount of frustration and indirectly encourages bad business practice and any long term advantage that could have been gained through it is eroded with each release.

Originally from South Africa, Anne Botha is an independent consultant that now resides in Canada. She has deep interests in quality of software and works with teams to build quality into their software development mindset. Anne is a regular writer and her recent articles include Data Quality is More than the Sum of One Part, and Making Sense of the Terrain. She is currently undertaking a self-motivated experiment to understand the life of a user sitting on the receiving end of a software development team. In the next part Anne will discuss her initial experience and observations about the challenges and frustrations that arise when working within a company where a large mismatch exists between critical business activities and the software that is ultimately put in place to serve them.