Most of the strategy and technique that need to be developed in the critical area of stakeholder management will come as part of the practitioner’s experience negotiating real-world project issues. However, it is always a good idea to pay heed to some proven practical pointers that can come in good stead.
Few project managers discuss stakeholders without in some way referencing the need to employ "stakeholder management". Not only have we invented a dehumanizing four-syllable word for "person", we've also now implied that they are people that need to be managed. Luckily, there's a simple solution here. Read about three letters that make a lot of difference.
“Project manager” does not mean “stakeholder gatekeeper”. The PM always seems to control that relationship, but there is a better way: When the relationship between team members and stakeholders is working, it’s the PM’s responsibility to stay out of the way.
For an agile project to progress smoothly, the backlog must be groomed and ready for each sprint. That work must be included in your project plan. This article gives you five points to consider when planning that work.
How can we estimate a project in advance while still maintaining the ability to manage the backlog in an agile manner? In this article, we’ll answer that question, compare release-level estimation to the techniques used for iteration estimation, and give some pointers on getting started with release estimation in an agile environment.
The Requirements Management Plan is primarily used for communications, giving all stakeholders a view on how this process is managed for your project. It completely answers the very common question, "How are you identifying and managing your project requirements?"
Having taken over a project, I find myself in the awesome position of needing to revise requirements with my customers that are pretty obviously in need of some spring cleaning.
Here are some tips ...
Most projects start off by asking twice as much as is possible given the existing resources. This shouldn't be accepted as just "the way things are"--we can partner with the customer to keep application development scope in line.
Bad requirements? Actually, that's your fault. If we know this is a recurring problem in our profession, why do we mindlessly continue engaging in the rote repetition of what doesn't work?
If a woman has to choose between catching a fly ball and saving an infant's life, she will choose to save the infant's life without even considering if there is a man on base.