I've noticed that inadequate stakeholder involvement often leads to project failures. What are some effective strategies you've used to keep stakeholders engaged throughout the software development lifecycle to ensure their needs and expectations are met?
Sort by:
I agree with Brad Candia's comment. It is important that the stakeholders understand what is in it for them so that they engage. There are a lot of thoughts that people will have I am sure around communication sequences, demos, etc. The thing that I have found to be the most impactful is creating a culture of accountability. Time and time again I have seen cases where communication is being sent to stakeholders on a regular basis and they do not read or engage. There is a level of accountability that is important in addition to the "what is in it for them". If someone refuses to engage over the period of time and they have expectations and needs that were never communicated and feedback not given, that becomes an important conversation about how to work together so that they are not coming in at the last minute or giving poor reviews on something after the fact.
The easy and quick answer is that they have to see value. If you are not including your stakeholders early and often and giving them the "what's in it for me," their interest will fade if not just never be obtained. All products are made for someone and if that someone does not see the value, you have already started a losing battle.
If you are in a large organization cross functional stakeholders (CFT) is a very important part of any project, software or otherwise. You cannot sell anything to the customer if CFT dont cooperate to make the product working. In a software project the key challenge is communication gap. User teams cannot articulate for a developer and the developer cannot articulate to the users. Product owners and managers end up bridging these gaps. Though it is time taking i ensure the user team puts pen to their paper and writes what they think they want. Likewise i force the software architects to create wireframes for getting clearer picture. If these 2 steps are done with diligence the outcome is usually least resisted or less buggy. Additionally I study my key user team and ensure I pre-empt their expectations even before it goes to them for proof reading to save time. We also do a series of mini tests as and when some modules are ready with the specific user so when the UAT is done together as a whole there is lesser iteration. Lastly the most important is to maintain a clean backlog tracker that observes and documents every production issue with proof and gets filed with a priority to business.