Unlike large mainframe systems, GroupWare has to “fit” into an already existing infrastructure and the applications must adapt to the organizational setup even when facing political or social resistance. One big challenge that remains is that of the interface. Since single-users use the groupware software, developers need to focus on a clean interface as well as the group processes and activity challenges that might arise.
It is often the case with new software or applications, that users need to get used to the application or it requires a steep learning-curve...which in turn leads to more work necessary. This additional work does not guarantee additional benefit, and the company is often stuck with a white elephant afterwards. GroupWare systems are often challenged by the social, political and economical factors which a group naturally portrays and because of this, a system (scheduling system) is at a disadvantage when it comes to information regarding human-interaction etc. One should be careful not to disrupt these carefully constructed webs of interactions by forcefully introducing a new GroupWare system.
Because GroupWare builds on individual activities, developers have to be alert to the facts that the software should be designed to align to individual needs and requirements. They should also make sure that infrequently used features are not dominating the primary screen. These enhancements could lead to a wider and quicker acceptance of GroupWare as a whole. Developers must also look at the introduction of GroupWare and take into account what users want and need in group setting. Often, software is doomed from the beginning, because it has been poorly introduced, or does not benefit the customer at all, or only minimally. The developers would be wise to take a step back and understand the group process activities, application use and also group-activity requirements, and integrate all of these features into already existing software.
No comments:
Post a Comment