Collaboration Systems
I currently work with Collaboration Systems (eMail, Calendaring & Scheduling, Instant Messaging, Web Conferencing, Team Workspaces, etc.). I didn't take a straightforward path into an "IT" career, but while updating my resume recently, a common thread through my career did strike me. Much of my work prior to IT was in management consulting and business process reengineering. Although both sometimes generated negative connotations among the "subjects" of projects, the goal was to help people work together better. The goal with collaboration systems is the same thing - just using systems to do so.
With the business process reengineering work, we found that the more we involved the people doing the "processes" we were trying to improve, the better the results. Not only were they better from an analytical perspective, but because of the involvement, the people were more willing to accept and implement the changes, which meant the intended benefits were actually gained.
The corrolary to collaboration systems should be classic IT project management of getting the requirements well defined from not just the product owner or project sponsor, but with input from the actual users. This can be challenging as most users are not aware of what features, functions, and benefits are actually available. On the other hand, we have potential influencers (IT executives reading too many trade rags) who think bleeding edge tools are ready for prime-time. The best approach I've found to addressing these both (so far) is a manner of "iterative requirements development." This includes some demos and discussions to generate thought and input around what potential exists today... and what is coming, but not ready, yet.
With the business process reengineering work, we found that the more we involved the people doing the "processes" we were trying to improve, the better the results. Not only were they better from an analytical perspective, but because of the involvement, the people were more willing to accept and implement the changes, which meant the intended benefits were actually gained.
The corrolary to collaboration systems should be classic IT project management of getting the requirements well defined from not just the product owner or project sponsor, but with input from the actual users. This can be challenging as most users are not aware of what features, functions, and benefits are actually available. On the other hand, we have potential influencers (IT executives reading too many trade rags) who think bleeding edge tools are ready for prime-time. The best approach I've found to addressing these both (so far) is a manner of "iterative requirements development." This includes some demos and discussions to generate thought and input around what potential exists today... and what is coming, but not ready, yet.