Listen to the real users, dammit

The world of IT and custom software is complicated, and it’s very different from the world you read about in the blogs.  It’s not nearly as sexy as a startup, a social network, or a product company that’s releasing other product “killer”s, but billions are spent a year writing custom software for use in enterprises.  Unfortunately, unlike a product company that sells to its end users, custom software is often designed by a committee of people who never use or have any plans of using the actual software.

We just completed one of our quarterly major software releases this week.  From many people’s perspective it’s been an unqualified disaster.  I sit somewhere in the middle, as my expectations for acceptable quality are somewhat lower than a lot of the business side management.  I can’t blame them for their high standards, but I’m a bit more of a realist.  However, there were undoubtably major problems released into production which should have never passed testing, and we caused very real impacts to our sales and care reps as well as to our actual customers, largely because we have cut ourselves off from listening to our real users and instead spend our time listening to corporate “Program Management” type functionaries who represent our actual users’ interests.

Anything designed by committee is likely to suffer in quality, and custom software only amplifies the affect of design by committee.  Product Manager, Business Analyst, Enterprise Program Manager, these are all titles of people hired to, among other things, write requirements for IT to deliver software against.  Their job is to design enterprise “products” that companies sell, however, in many companies, these people never actually use the output of their work.  Sales and care representatives are then forced to follow processes concocted by their corporate counterparts which make customers jump through hoops, follow inane business rules, and in some cases turn paying customers away.

Also, when this software goes to production with issues, as all software does to some extent, there becomes a prioritization exercise that’s required in order to get the biggest issues triaged and fixed as fast as possible.  It’s these same corporate managers who are prioritizing what needs to be fixed first, even though they’re likely not seeing any of the issues for themselves.  For example, from this last release there was a defect where the customer’s account number was not printing on a receipt when taking a service payment.  This sounds critical until you realize that we don’t take service payments in the locations this defect was said to be affecting.  The people prioritizing the defects didn’t even understand the business well enough to know the basics of how payments are taken in various channels.  On the flip side, coming out of user acceptance testing, an issue was detected where migrating a customer from one pricing plan to another caused their error to order out which requires a 24 hour manual process to correct the customer’s account, but this wasn’t considered critical so it went to production affecting hundreds of users a day.

These types of corporate structures feed upon themselves.  Productive departments servicing customers end up hiring their own analysts and “managers”, often with no actual management responsibilities, to combat the work being thrown at them from their corporate counterparts.  Corporate product managers and business analysts design business rules which do nothing to help the actual customers, but they do help to drive revenue to their particular corporate general ledger line which keeps their management hiring more.  This does nothing to grow your business.  Yet, it’s common in many large organizations.  Instead, eliminate these corporate departments.  They’re completely unnecessary, and you’ll find yourself not only saving money by avoiding having to pay their salaries, you’ll also be more productive. At the very least listen to your real users.  If you need business analysts, bring in field sales representatives, bring in help desk and customer care representatives in 6 month rotating cycles.  These people actually know what they need, because they just lived the life of your end user.  You shouldn’t be writing software, custom or not, that’s being designed by people who have had no interaction with the users of the products.  This is worst in custom software, but the same wisdom should hold for anyone writing software.  No one should ever be more than 6 months from having worked directly with end users.