Sections of this topic
Two years ago I was deploying a high-technology project for a client. It was a worthwhile project, whereby we were going to give sales people the ability to communicate instantly with their developers in Asia. A few weeks into the project, the client’s own Security organization became very interested… and proceeded to shut us down!
We have written a few times in this blog about the importance of understanding a project’s justification, or business case, before plunging into planning and implementation. Why is it important that this project be deployed? Why now? What are the essential features needed? Who is the ‘management sponsor’ interested in seeing the project succeed? What we don’t discuss as often, but can also be critical –as illustrated by our now defunct project− is an early Stakeholder Analysis.
Stakeholders are people (or organizations, such as the aforementioned Security) who are involved in the project or who are affected by the project. When we mention ‘stakeholders’, it is quite easy to limit ourselves, and just think to include the performers and the customers of a project. In truth, we must look further afield and consider other indirect persons or groups that may not be as obvious, but who are still being impacted by our project. For example:
1. Customers of the customer – It may be that the ultimate user is not the group who commissioned the project, but customers of theirs who have additional needs. If the project’s ultimate customer may or may not speak English for instance, we may want to include symbols along with written instructions, to increase clarity.
2. Regulatory Groups − Our analysis should incorporate functions which may not be obvious, but who would indeed have the authority to terminate our efforts. They can reside in the customer’s organization or in society at large, eg, Procurement, Security, the city’s Health Department, Fire Department.
3. Managers of our resources − We should stay in touch with those who manage key individuals in our project. They may have their own set of measurements, timeframes or constraints and possibly impact someone’s availability while we still need them.
There are others of course. By introducing these categories though, we hope you can manage direct and indirect stakeholders’ expectations, and avoid unpleasant surprises.
—————————
For more resources, see the Library topic Project Management.
—————————
