Blogs

Last week on a different blog, I talked about how we are using SharePoint to manage the voting for a Holiday Door Decorating contest in our office. Marc D. Anderson commented that:

“This is one of those fun little applications that I could get totally lost in. It would be an awesome SPA example, with live updating to the tally list, a little visualization to show where the votes currently stand, a rotator to highlight the top entrants…

Ah, but there’s so much else to do in life, eh?”

I wrote to Marc privately to explain that one of the reasons we wanted a low-key judging process is because we didn’t want anyone to feel bad by seeing a low vote count. I offered some other details that I won't share here, but I think that's enough for you to understand Marc's response:

“What you've written below would make an excellent post at AIIM or elsewhere. The standard technology-driven approaches just don't always make sense in the real world. This is part of the reason why techies who build things without sitting with the ultimate users build such crap. It makes it even harder when something like this is offshored to people who have different cultural biases.”

He’s right, on all counts!

I thought about suggesting that Marc write the blog entry and that he substitute “my client” for “my company” but there are enough dotted-line connections between my blog and Marc to make that an easy puzzle to solve. So, if you’re one of my coworkers and you feel like you might be someone whose feelings are being protected, please focus on two things. 1) Your coworkers care about your feelings and 2) you still have time to make your door look better.

I can’t really add anything to what Marc said. Designing systems is difficult when humans are ultimately involved. Throughout my career, my designs have been impacted by humans on numerous occasions including when:

• The advantages offered by the system I was proposing conflicted with a union contract. People had negotiated the right to work harder than they had to. You can read about that incident here.
• The end user didn’t want to rely upon calculations that a human couldn’t manually cross-check. We build a somewhat imperfect process but ones that didn’t really need a computer.
• A flexible, dynamic, configurable user interface was bypassed for a static, albeit intuitive interface so that documentation could be written and cross-training better supported.
• A third-party purchasing system I was supposed to implement had to be shelved until the process could be altered to accommodate a higher level business requirement that trumped the accountants’ view of separation of duty.

In each of those cases, I was surprised until I understood the point-of-view of the user organization that I was working with. Despite the fact that many of my examples stem from the early days of my career, I think there are several reasons why this is a more important issue today than it was in the 80’s:

Development is decentralized – I started my career in the “The Great and Powerful OZ” days of IT. We controlled everything and even if we didn’t always “get it” there was one place to complain. Today, development can take many forms and “solutions” can be set up by almost anyone at almost any time. Apps can be purchased and integrated with a business process without any design and often without any consideration of up/downstream consequences.

Complexity is non-linear – Systems are getting more complex and business processes are getting more complex. Combine those two facts with the notion that more and more people can create a “solution” and you have a development environment that is much more complicated than it was 10 years ago. Despite that, IT organizations frequently are driven by the goal of lowering cost and line-of-business organizations are often driven to implement solutions without IT. I added that last bit, because when LoB units implement solutions without IT they often don’t bother to involve other LoB’s either.

Technology is cool – Even within my own organization, I sometimes have to pour water on the fire of cool technology. It’s been said a thousand times, in presentations and blogs and real live people talking to other real live people but “just because we can do something doesn’t mean that we should do something.”

If I could add anything to Marc’s comment, it would be to extend the information gathering task. Marc points to “the ultimate users” but that may not be far enough. The purchasing solution we purchased and tried to implement was selected by “the ultimate users” but the president of the division I worked for didn’t like it. Systems codify, literally, a business process. The ultimate users may only interact with a portion of that business process. In addition to reaching out to the LoB employees, designers and developers have to have or acquire a fundamental understanding of the business operation, too.