Tuesday, February 17, 2009

Stakeholders

Rob was complaining this morning on Twitter about how much he hates the company's time tracking system. I think about HR applications from time-to-time, mainly as an example of how *not* to develop an application.

Every HR time tracking application I've ever seen or used has the following problems:
  • It is antiquated. Probably designed between five and ten years ago and purchased at a ridiculously high cost, the business cannot justify the ROI to upgrade or replace the system.
  • It has amazing usability problems. I imagine these systems being built to some spec by an overseas sweatshop under contract. While technically they work, they rarely work well.
  • It frustrates the crap out of thousands of users every day, but then again, who asked them?

The trouble with these systems is that the end-user, as a stakeholder, is rarely considered in the design or purchasing decision.

These applications tend to be the perfect storm of poor design. They are sold to CEO's, HR execs or Finance execs who see them as a necessary evil. These execs know little about the underlying technology, and are ill equipped to do the requirements analysis necessary to clearly articulate their needs to the vendor. They maybe consult their IT people, but then those guys have their own agenda (deployment and operations). They definitely ask the Accountants what they need--since they're the only part of the business that actually has anything to gain from the data the system will collect.

In any system there's a bunch of stakeholders in the mix. In this case the role that will make the purchasing decision, and a few stakeholders who will directly or indirectly use the system (i.e, finance, IT, and the employee). The irony of HR systems in particular is that the user who is most affected by the system in their day-to-day life is rarely consulted or studied in the design or purchase of the system.

Let's say you have a company of 2000 employees. Let's say these employees only need to enter their time once a week, and it only takes them 4 minutes to do it. That's 6933 hours of labor time that's going to be spent in your company each year--just entering time. One would think that those employees would be considered as the single most important stakeholder in the design and purchasing decision of such a system.

So what tends to make these systems so miserable, isn't so much the specifics of their design as much as the fact that the stakeholder who's life is impacted *most* by that design is rarely consulted.

In our business we have a number of stakeholders who need to be considered when designing our products. Not the least of which is ourselves (how will this advance our goals?). We also need to consider our sales channels (what allows them to compete?), our target purchasing decision maker (who's often not the end user), and the end user themselves (whose entire waking life is going to be spent using our product).

What's disastrous is when any of the stakeholders are left out of the design process--or when the priority is wrong. HR systems get this wrong all the time, and it's a shame because it makes Rob's life miserable.

4 Comments:

Blogger Rob said...

Did I ever tell you you're the man? Well, in case I haven't... You're the man!

11:20 AM  
Blogger brent said...

I completely feel your pain about time-reporting (and HR systems in general). We just started using a new system that, although we only have to use it once a month, are going through the deployment pains. One of my big objections is that even exempt salaried employees, some of whom may not have turned in a timesheet in decades, have to use a module called "absence management". *Absence management*, could there be a worse name? It sounds like we're in kindergarten. But the name shows you for whom the system was built, that's for sure :)

The argument you make about saving four minutes a week per employee is one i've tried to make before, and gotten shot down on: "well it's not like I'd be doing something more productive with those four minutes". Well maybe not, but on "company time", yeah i think we should free up those four minutes *just in case* people want to do something more productive :) And like you say, why unnecessarily annoy people?

But for perspective, it is all sort of on a scale from really detailed "time and motion" analyses that the industrial engineers would do on the assembly floor, to Google's take-a-day-a-week-to-work-on-whatever-you-want-to.

11:29 AM  
Anonymous Anonymous said...

Rob,

I don't want this to sound like a commercial so I will not mention my company, our service or provide a URL. In a nutshell though, we couldn't agree more with your post.

We started our company with the belief that time tracking and approval should be simple, inexpensive, and universal. To meet these objectives we built a community of users (workers, managers, clients, and admins) around our website. These are folks who do time tracking everyday and we asked them to tell us what they think would make reporting easier for them. It turned out to be a great experience and we still prioritize our development that way. Generally speaking, if it's a good idea to one, it's a good idea for all.

The result is a network where people invite each other to join a project. The person who owns the project sets up the details and invites the other people by role. Unbelievably easy and built with all user suggestions.

If you would like to ask me any questions, I can be reached at joepiekarz (at) gmail.

3:59 PM  
Blogger Rob said...

I should mention that since I arrived four years ago our systems are TONS better, and are continually improving! In large part due to Steve and his band of merry developers.

The last year has brought a new philosophy to our beloved shop. A good one.

Some day I'll realize the dream of ZERO time reporting! Until then just turn away when I begin to scream, it's a huge character flaw, and not likely to change anytime soon.

2:13 PM  

Post a Comment

<< Home