I presented a webinar for Catalyze (www.mycatalyze.org) on February 14th entitled Designing a Sure-Fire Stakeholder Strategy. The presentation touched on the importance of business analysis planning, specifically planning for stakeholder communications. We had 150 attendees and I was not able to answer all of the questions that were submitted. I will answer the remaining questions in upcoming blog posts.
How do I manage a stakeholder that changes his mind and these changes cause large amounts of re-work. Any rules of thumb such as an extra 20% longer?
Great question. When we are planning and thinking about how best to communicate with our stakeholders we need to consider each stakeholder's ability to provide requirements in a timely fashion. This includes considering stakeholders who may tell us one thing one day and something different the next. If you are fortunate enough to have personal experience with your stakeholders than you can plan for their individual idiosyncrasies (this is not a judgemental statement, we all have some percular ways of thinking and communicating!). If you don't personally know a stakeholder, try to find someone who does. Ask questions informally to get a feel for the person's style.
When building your task list and estimates, you should not explicitly say that you need more time with John because he changes his mind frequently, but you might build in more formal reviews and re-reviews with that particular stakeholder because you know this issue will come up. You also should alert the project manager that when dependencies are built into the project plan - beware that dependencies on John may be risky. The PM can also plan better with this knowledge.
We don't always get the dream stakeholders - the people who are always availabile when you need them, always patient when explaining their needs, and always sure about what they want. We have to learn to plan for and work with whoever our stakeholders are and remember than variety is the spice of life. If all stakeholers could clearly articulate their needs, there would be no need for a business analyst!
February 21st, 2008 at 10:25 am
Great question, maybe "the question" about this subject, and great answer too. What do you think about a strategy of "record and charge"? - Record every change to base your arguments on facts, not feelings. - Charge the stakeholder for the changes, I'm not talking about money, but something else. You can't be the only one who gets hurt when requirements are changed. In my point of view, constant changes mean lack of interest and attention to what is being made. Nothing better to get attention than to bring some pain. If you don't treat it conscientiously you'll do it sub-consciously, and it can be really bad, bringing relationship issues. Of course, this strategy should be developed along with the PM.
February 26th, 2008 at 6:58 am
Another tip is to provide tangible things to help people understand what your requirements mean in the real (virtual) world.
Agile proposes iterations. Other development models recommend prototypes.
March 7th, 2008 at 2:05 am
My few thoughts to the list: When the requirements keep changing, it's always better to set a right expectations between you and your 'so called' stakeholder. Tell them that, we will be ready to take the changes, but let's try and freeze on the initial requirements so that we can have a vinilla version of the application or the product that has been planned to build. And if your company adopts Agile Iterative method then it will be possible to track and manage the requirements that keep changing. Thanks, Ganesh
March 7th, 2008 at 10:29 am
I think that it’s important to understand the “why” behind the requirements change. Is it due to legitimate changing business drivers? Or, is it for some other non-business critical reason (i.e inattention on the part of the stakeholder?) If the changes are due to a legitimate business driver then we, as business analysts and developers, need to understand that the stakeholders and users are not changing the requirements just to make life difficult for us. Instead, more often than not, the requirements change because business conditions have changed - maybe there’s a new regulatory requirement or a new product offering by a competitor. We need to work with the business to adapt to provide the best value for their money and work with them on the best available solution.
May 28th, 2008 at 4:54 am
I would like to build a friendly relationship with any of the business analyst from any environment, i am actually in financial nevironment in south africa.