Cats and Dogs, Living Together!

Remember back in 5th grade (or sophmore year of college, in my case) when your best friend called the girl's best friend and asked if they liked you, because you like them but only if they liked you first?

Eventually, you realized that this method of communication was getting you absolutely nowhere and you dropped the middle-men and just got the guts to call the girl yourself.

I've been having deja vu lately involving workflow. While I could probably have a decent blog entry on the various approaches we've tried while implementing, I'd rather talk about why we've had to take various approaches in the first place!

Initial requirements gathering turned out to be invalid for a variety of reasons. We deserve some blame on the IT side for not really cementing the process in place - we could have done a better job of forcing users to really walk through the process on paper. Another major issue was not getting beyond the liason's and into the true end users.

The end result is something like: Bob sends to Cindy who can reject in which case it goes to Tom but an approval goes to Al unless Bob hasn't entered the id in which case... yuck.


When we eventually had "what the users wanted", you could take a step back and already identify points that just didn't make sense... You mean to tell me that the CEO at HugeCo wants to have to sign in and click "ok" for every new item coming down the pipe? We're going to get calls on Day2 telling us that we have to take that out because it's a serious kink, etc, etc.

Well, you can't be surprised that this workflow evolved quite a bit as we went a long. We'd put out something for the users - a week later someone would tell them it was there - a week later someone would tell us it "didn't work".

Did it really work? Well, it did exactly what it was intended to do (as code often does), but... no, frankly: it was a piece of crap!



So, month 10 rolls around and things are getting outrageous as the deadline approaches. Finally, not only are we working with liason's but (gasp) in the same room as the end users and actually (triple gasp) talking with them directly! So, now everything went perfectly... THE END.

ok, maybe not. Actually, looking back on the last week I have done what I would normally rate a poor/fair job of getting requirements ironed out.


BUT, using a technique I call "communicating with the user" I have been able to make my mistakes: have them corrected, implement what they think they want: have them realize it's wrong, etc all in the course of maybe 10 hours of legit work. As opposed to the 8 months of make a mistake - wait a week for communication to occur - retry, that we've been going through up until this point.

The moral of the story: Having an open communication line is essential. You can benefit greatly from having technical people talk directly to the client. People who will eventually write the code know what typically needs to be done to actually get the code written! Seems like common sense but it's not always that easy to communicate this need.

Seem like common sense? Of course it does, you're a technical person: now go explain it to your boss.