In our organization, we’re thinking about bringing together Lotus Notes/Domino development, Remedy (Action Request System) development, and VB/VBA development under one umbrella. Each of those development groups have a manager and in the new structure they would report into one person. We’re creating a job description for that person, but we’re not sure what to call it.
Someone has suggested “RAD development manager” but some of the applications that are created are enterprise applications and can take up to a year to create. “Ad-hoc development manager” seems closer, but again not quite on the mark. The Notes/Domino group is currently called “Knowledge Management Technology Development”, but many of the VB/VBA applications deal with structured information so I don’t know if that’s important.
That person would also manage two Java developers, but we can ignore them if it makes it easier. Most, but not all, the applications are internal. In our organization we also have development teams that focus on Financial, and applications for sales people.
Well, Lotus Notes/Domino and Remedy are communications mediums - one for mail, one piggy backs for incidents/feeback. The VB could be anything, as well as the Java guys. My stab would be Computer (or IT) Communications Development Manager but thats a little wordy, but I hope you get my drift.
The VBA applications are mainly internal applictions used by in support of our clients.
The Notes/Domino applications cover every category, but mainly deal with unstructured/semi-structured information - collaboration with clients, collaboration internally, travel expense reporting, learning course registrations, performance management, defect tracking, project activity, workflow, reference, discussion, etc.
The Remedy applications are primarily used by our support center.
As SmackFu noted, Lotus is actually a suite of products with applications for communications, both e-mail and real-time, scheduling, and even limited data base applications.
Aside from my initial suggestions, I would ignore the platforms on which you will initially run your applications and focus on what service the group will provide. (In that way, if some spiffy new product comes along to replace one or more of your current products or if the group finds itself providing different services as the years go by, you will not run into the hassle of explaining “We’re the buggy whip group, but that old name does not reflect our current product line of air horns and sirens.”)
My 2 cents… your key words are groupware (or collaborative software), automation, and integration. Mix and match to make an acronym that suits you, and you’re done.
