Modern Middle Manager
Primarily my musings on the practical application of technology and management principles at a financial services company.

Tuesday, January 07, 2003  

Part of every manager's day will revolve around meetings. Some are ad-hoc, some recurring and some (the best ones) are dressed-up rewards from vendors like lunch or golf. Those are my favorite. Today I have eight meetings, none of which are lunch or golf.

What happened? How did it get out of hand? Let's see -- a conference call to discuss outsourcing our imaging system, a contract review to renew maintenance on our UPS and generator, the beginning of one staff member's review process, four half-hour meetings to discuss my staff's individual biweekly research topics and an application architecture meeting in the afternoon. All important, in their own way. All crammed into the same action-packed day.

These meetings remind me of a series of meetings regarding application development last year. I can't say enough about the extraordinarily time-consuming idea known as Consensus Decision-Making. Why would I say such a contrarian thing? How can I go against the core wisdom of the management gods? Because we tried to craft The App That Would Make Them Happy. It started simply enough -- they wanted a system to help them improve their fee review process and track changes made through that process. Fair enough. The Fee Review Action Team was formed, consisting of myself, the programmer who would implement the system, one regional VP and two administrators. The initial specification was flowcharted out, changes were suggested, all seemed well. Until the meetings started to occur when participants would ask for things that had been deleted from the spec in the last meeting. Or change what had been a "consensus decision." Finally I just started to say, "No" or the more politically soothing phrase, "Let's look at that in the second release of the application. But we've got a timetable, let's get this project out the door soon." This is when backroom dealings begin because I was starting to get irritated with the admins who would change their mind. By talking with the RVP, I was able to get him to help me squelch some of the more ridiculous or time-wasting suggestions. Even getting them to sign off on proposed changes was a chore that took weeks instead of days. At the end, the senior VP signed off on the specification. Finally, the application was developed, much testing done, a beta test performed with a larger group and then Implementation Day.

Was that the end of it? Hell, no. First there were the admins and assistants who didn't prep the data properly (yes, long meeting and e-mails and demos accompanied the rollout. These were The People Who Didn't Pay Attention). The best incidents were when the senior VP would tell us there was a bug in the system and it turned out to be performing to specification -- she had just forgotten what the spec was that she had approved (and, in some cases, the behavior was what she had demanded).

What did I learn from that experience?

1. Consensus is important, especially when creating something that adds value. Make sure the other members of the team representing end-users feel responsible for what they've created.
2. It's a very, very slow process and needs a strong hand guiding it.
3. Get a specification in writing, signed by the spec team members and the department head. Get all spec revisions in writing. Why? It's a very important CYA move.
4. If things look like they're getting out of hand, apply pressure on the team members indirectly through their supervisor, branch manager or department head. This is why it's good to play politics.
5. Once the application has been created the implementation process is not going to be smooth. Information will fail to be communicated to the appropriate people or ignored. Be prepared to defend your decisions (see #3 above) and remind the end-users that they had representatives to whom they should be complaining (#1).

Maybe the lessons I've perceived means I'm getting jaded and cynical in my old age. Or maybe the personalities I deal with are more mercurial than the norm. In any case, I found the above list to be helpful in crafting new applications.

posted by Henry Jenkins | 1/07/2003 11:00:00 AM

Comments: Post a Comment
the author
open source