PMI BeNeLux Day

This fun and interactive workshop can be considered as an introduction to the topic.

The content and approach is based upon the article "Using Stakeholder Analysis in Software Project Management" which is an extract from my book "Surprise! Now You're A Software Project Manager".

The material of the workshop will be general, not specific for software projects.

1. Introduction and background
2. Stakeholder identification
3. Stakeholder expectations and interests
4. Stakeholder involvement
5. Stakeholder communication (feedback)

So, as a software project manager, you should really focus on the stakeholders. You should be guided by their fears and their wishes. A stakeholder can be a project team member, an employee of the user organization, or a senior manager. It can be virtually anyone, as long as that person has something to do with the project.

Here is the central problem the software manager is faced with, appropriately named “the software project manager’s problem,” as explained by Barry W. Boehm and Rony Ross1. They believe that everyone affected by the project, directly or indirectly, has something to say, again directly or indirectly, and will do so.

All of them want to get the best from this project for themselves personally or for their organization. It’s the job of the software project manager to see that everyone gets what he or she wants, in one way or another. He has to “make everyone a winner.”

In a project, it’s the people that are the main cause of problems. Time schedules, financial projections, and software goals may be abstractions, but it’s the flesh-and-blood people whose work determines your project’s status.

It’s the programmer that misses a deadline and holds up everyone else, it’s the financial manager that goes berserk if you can’t produce some good budgetary indications, and it’s the key user that doesn’t give a darn but didn’t tell you about his dismal lack of motivation; these are the folks who can cause serious trouble.