Mike Donoghue is a member of a multinational information technology corporation where he collaborates on the communications guidelines and customer relationship strategies affecting the interactions with internal and external clients. He has analyzed, defined, designed and overseen processes for various engagements including product usability and customer satisfaction, best practice enterprise standardization, relationship/branding structures, and distribution effectiveness and direction. He has also established corporate library solutions to provide frameworks for sales, marketing, training, and support divisions.
In recently trying to develop a plan to define requirements for a systems project, I found myself wondering just who would have a sufficient interest in the project and become a stakeholder in it. It was so easy to think that what I was proposing had value, but it took a bit of thinking and analysis to figure out whom besides myself would have as much of a concern about the venture.
It posed a good period of head-scratching to come up with what types of people and their respective roles might be considered. Basically, I was looking for simple answers to help in my process:
What parties in the enterprise will want to use the system improvement?
Once those parties are identified, who will be acting on behalf of those various groups?
What plan, method, etc. will be used in which to distribute system features to these groups?
What potential is there for requirements information to not be identified or provided as add-ons to the project?
What issues may arise when we look at different implementation options and the new tools and utilities needed to support the system change?
And of course:
Just what are the bottom line advantages and benefits to stakeholders?
Questions, Anyone?
Have you been part of a project team that built something that, while it fascinated and