Tuesday, February 19, 2013

Understanding Your Process

A tweet from @theitskeptic this morning brought back some memories for me. Good memories.

During my college days I was getting pretty disillusioned with computer science. Right before I was about to jump ship a person I hold in high regard as a mentor arranged an internship for me with a major US educational testing company. It was an eye opening experience in many ways but most importantly it got me really excited for what IT could really do. More importantly, what IT can do if you have a service-oriented mentality.

Testing is fraught with errors. Its just a fact of large scale testing. The people creating and scoring the tests are trying their hardest; Accuracy is their goal. When you're developing and administering hundreds of different tests and scoring thousands, even millions, errors will happen. Software bugs show up. These things happen. In educational testing, though, the stakes are high since youthful aspirations hang on the results and the tensions are extremely high due to parental anxieties. Teacher and tester are put in a tough spot when things go wrong.

The internship landed me in a department that did a lot of testing in a US state with a pretty big population. Lots of tests, lots of students, lots of problems to resolve. The task I was given was requirements research: What would it take to implement a ticketing system for problem tracking? (Sound familiar to you service desk folks?)

As I dug into the problem I discovered that no one knew the problem resolution process! Actually, there was a generally accepted view of it but at the core of the problem was that there was no actual full process. Management understood there were incidents slipping through the cracks after being submitted but without tracking or even an established workflow there was no way to find them. The process was paper-based, handled between geographically separated teams, undocumented, and unclear. It was a beautiful, glorious problem to sort through!

I spent nearly three months unraveling this tangle and learned a few things:

  • The larger the organization the more essential process becomes. When process is broken real people get hurt. Both your employees and your customers.
  • Continuing on without understanding your process doesn't just compound the problem. It explodes it and it becomes a toxic, radioactive weight around your team's neck.
  • It is a lot of work understand process.
  • Process transparency is scary but without it service stinks, trust breaks, and management is helpless.
Technologists talk a lot about standardization, simplification, automation, even elegance but none of this matters, even a little, without understanding. If you do not know your process you do not understand the basis for your work. Your vision, individually and as a team, is out of focus. With one team focused on new development, another team focused on service, and no process between them never the twain shall meet!

This is the natural point at which I'm supposed to conclude by offering some incredible insight into HOW you understand your process. I'm afraid I don't have that for you. If we ask around I'm sure there is good info out there about how to do this. I can assure you, however: Fully understanding your process is vital to the function of your business. Good service (internally or externally) cannot occur without understanding your process.