The Accelerate HR Blog
Customers - not always right (Tue Nov 20 2007)
I'm not a big fan of manuals - not for software. As far as I'm concerned if you can't see exactly what to do when you arrive on one of my pages, if you can't navigate through the website, then I haven't programmed it right. (Go on, tell me I haven't - or I'll never know.)
For me 'The Manual' is what corporate clients ask for when they really don't want to buy your software. That's fair I guess. I don't want to sell to them either if they'd prefer to read books than use software.
But on the other hand, I'm a big believer in documentation. Not so much 'What do you do next?' as 'How does it all fit together? and 'Why are we doing it like this?'
David Heinemeier Hansson, the big cheese behind Rails, says he believes in opinionated software. And I'd go along with that - even if my emphasis is a little different. 'Convention over configuration!', DHH proclaims. In other words, if you do it the way I tell you, life will be sweeter. For DHH it's mostly about software design. Me? I'm opinionated about the way we run HR. I want to see it done better. And I use software as a subversive means to my end.
It doesn't always make me popular. There was a time I teamed up with a local agent to sell my desktop HR product. He managed to win a deal with a client by telling them we'd make any modifications to our package that they asked for. It was all part of the service. Then he told me. What did they want to do? Add in all the tedious paper-oriented procedures that I'd spent the last 5 years streamlining out of our package. There was a furious argument. 'The customer is always right', he screamed. Not in my book. End of relationship.
It's not to say the customer viewpoint isn't important. If you take Accelerate HR, virtually all the ideas and methods have come about as a result of client suggestions or as a result of working on their specific problems and issues. But it's just that as a software publisher rather than a hired programming hand, I believe that I should retain the ultimate responsibility for deciding whether a new feature will enhance the package or hold it back.
So let's get back to documentation. The whys and the wherefores. And specifications. The aims and objectives.
Without these, the poor client doesn't know where he's headed. OK, he can test out the software, maybe even do so for several months before making a decision. But hidden behind the facade of the software, there are thousands of different design decisions, more in an HR package I suspect than most other software. Does the client buy in to these or not? Are they relevant to his business?
Let's take an example. Right now I'm working on Vacations. Here's a little sampling of my considerations:
Calendar or working days
Clients use both methods. Having specified which method is used, the number of vacation days taken is calculated correctly by the database after the start and end-date have been provided.
Lieu Days
If lieu days have been earned (e.g. working on an off-day), the total number of lieu-days earned are visible as the vacation details are entered. If the user opts to include lieu days within the vacation record, the number of vacation days recorded are reduced by the number of lieu days used. In the background, the lieu days table is updated with the days taken. The whole process is reversible.
Expatriate employees
May be provided with travel tickets at defined intervals. When entering a vacation it is clear whether a ticket has been earned, and whether it has or not, the user can include a ticket application in the record. If the employee is on 'family status' the entry form also shows any family members also entitled to tickets - and in the case of children, their ages (to make it clear what type of ticket to purchase).
If the business does not hire expats or does not provide vacation tickets, ticketing arrangements are invisible.
Unpaid leave
Users can freeze employee accounts during extended unpaid leaves. The calculation of vacation days due takes account of any frozen periods.
And so on.
This is information clients need to have. Preferably before they start using Accelerate, so that they can determine whether our software meets their requirements. For example, there's nothing here that says anything about employees creating their own vacation applications. Nothing about automatic generation of printed application forms. And these may be very important to the client. (... so they'll be pleased to know that they will find both of them covered in Accelerate as they continue through the documentation.)
And with any luck the user will dip into the documentation too - to understand how all the component parts fit into the whole. I want it to be a learning tool for anyone who wants to understand HR better.
So how do we deliver this? Not as a book. In recent months, a whole plethora of great search tools have been made available on the Web ... you'll see what I mean if you check out our Live Search feature for this very blog. And that's exactly how I'm going to handle the documentation in Accelerate. Any time you have a question, the answer's going to be right there. Watch for 'Documentation' to appear in the left-hand menu bar soon.
Now, if you've got this far, you must be at least a little bit interested. Seems like you have time on your hands too, if you've stuck around. So how would you fancy giving me a little help with the docs? An hour or two of time ... great learning exercise .... undying gratitude ..... Ah well, no harm in asking, was there?
Oh, where can you reach me? At support@jobwd.com.
