In order to affect positive change in complex organisational and technical environments, it’s imperative that an in depth and accurate understanding of core business problems and opportunities is developed. This will allow a detailed analysis to take place to determine what needs to change to address these problems and opportunities.
But the reality is that in order to then capitalise on that knowledge and deliver real business value, individuals and teams must be able to effectively and faithfully communicate what the problems facing the business are, and how they can be addressed. This will remove potentially harmful assumptions, minimise risk, and allow project sponsors to make sound decisions, enabling cohesive and efficient project teams to deliver to the businesses’ true needs.
Where there is not a clear and correct understanding of project scope, business requirements, risks and issues, the impacts to scope, schedule and budget can be severe. Worst of all, the fact that these impacts arise from misinformation can mean that they may remain hidden for some time, increasing their severity exponentially when they are finally uncovered. This type of scenario can derail even the most lucrative business case, resulting in huge amounts of wasted investment.
There are a myriad of techniques that can be used to ensure all project stakeholders are engaged and well informed, and a skilled change practitioner will work hard to get to know the teams they work with so they can understand the best way to connect with them. They are then able to select the most appropriate techniques to suit the personalities and preferences of their audience. They consider:
Do our stakeholders work on the business or the technical side of the organisation?
Business stakeholders will usually prefer to have conversations and view high level power point presentations with just a basic level of detail. Technical stakeholders might prefer detailed use cases, user stories, and functional requirements specifications.
Are our stakeholders better able to interpret information when it’s presented textually, visually, or orally?
Is the subject matter interesting enough to engage them? Where it’s routine or monotonous, is there a way it can be presented to make it more exciting?
Do our stakeholders have the time and energy available to commit to the consumption of the information required?
Do they need to have time freed up for them to allow them to be more involved in the project?
Do our stakeholders grasp new concepts easily or do they require time to absorb information?
Do they prefer to learn independently or learn through discussion? Are they likely to ask for clarification when they don’t understand? Perhaps they might be less or more likely to do this in a group environment?
Although these seem like simple questions, they will allow one’s approach to effectively eliminate assumptions and ensure clarity across even the biggest and broadest of teams. Ultimately, good project requirements are well understood project requirements. And good requirements are the most important characteristic of effective project delivery.
