As a project professional, how many times have you experienced a project sponsor resisting the documentation of requirements, or a consulting firm saying they don’t need to produce business requirements because it’s obvious what everyone wants? More times than you’d care to mention, I expect. This blog explores what happens when requirements are deficient and how to ensure that your projects don’t suffer the consequential problems which often result.
Why take the time to produce business requirements?
Our project manager today is James. He is an experienced guy, but he is new to the company and is taking over a new transformation project, having previously worked for several years in an organisation where projects were second nature. By changing company, he is introduced to a culture where projects are far less common and the management team far less experienced in running them successfully. His project sponsor, Beth, is reluctant to spend significant time documenting requirements, believing that it wastes valuable time and hampers progress. In persuading Beth that requirements are essential, James uses the following arguments to explain that successful projects possess a sponsor who can visibly demonstrate and advocate:
Understanding: that they have a good grasp of what they want and expect to achieve is best elucidated through a set of requirements – this demonstrates the completeness of thinking that is required to minimise the likelihood of nasty surprises
Articulation: the process of gathering requirements stimulates debate, clarifies issues, highlights the unknown and prompts challenges such as ‘why have we been doing it like that?’ It encourages the examination of what people do today so that you can agree how to change it – a sponsor leading a transformation has to be able to articulate the benefits of change, a key component of which is to be able to compare the start point to the end state
Proof: that you know what you need to design and build to successfully deliver the business outcomes and can demonstrate this to your stakeholders, building confidence in the project
Challenge: making improvements and enhancements are fundamental to successful transformation. The requirements gathering process provides a platform for challenging what gets done and aiming to do it better
Agreement: ultimately, signing off requirements achieves consensus from stakeholders about the business need. This consensus demonstrates that the sponsor is not in it on their own but has broad support for the project
Projects are complex animals, as are the people who work on them, so when disagreements inevitably arise, James points out that it is quicker and far cheaper to resolve these before you have started to build or implement a transformative solution. He explains that the requirements process can be used to drive out areas of contention and resolve them before they become expensive. Further down the line, should disagreements then resurface, the requirements exercise provides a quick and easy frame of reference for a sponsor to remind everyone what they agreed to.
What if we don’t bother?
Beth hears all of these arguments but is worried about expending significant resources and time on requirements and how she will explain them to her fellow CxOs who are unused to projects and who pride themselves on being dynamic and agile. To help, James lays out some of the consequences of omitting requirements:
Perceptions-driven management: without clear, shared, agreed requirements there is no baseline for business needs. The whole team will have to deliver the project with no more than the differing, shifting perceptions of stakeholders with which to work.
Significant Disruption - as these perceptions are likely to conflict and because no agreement has been reached, there are likely to be contention, change, delay, cost and political consequences
High Risk: both for the project and the Sponsor. Projects can be reputation enhancing but also career-limiting should they go badly. As requirements build consensus, they go some way to insulating the Sponsor from political pressures which may arise as the project progresses.
Supplier management: it is difficult for suppliers to give you a quote with any degree of accuracy if they do not possess a clear set of requirements. Without requirements it is practically impossible to hold suppliers to contractual commitments, meaning that costs and timescales could be highly unpredictable. In fact, suppliers love vague requirements, they can never be held to account for poor performance if the requirements are insufficiently detailed or clear.
Auditability: many projects must prove that everything requested has been done (e.g., if projects are subjected to an internal audit) then you need to have documented and signed off requirements against which to measure the outcomes.
Without a strong set of requirements there is a high risk of a mismatch between stakeholders’ perceptions of what they believe is required and what is being delivered. James explains how projects with that problem always become stressful for the Sponsor – they are constantly under pressure due to delays, cost overruns, increasing risk profiles, descoping and, ultimately, not delivering to stakeholders’ expectations. This resonates with Beth as she has seen other sponsors in her company live through similar painful experiences.
Conclusion
Beth now possesses all the arguments she needs to convince her stakeholders that her project will need a strong requirements phase. She can demonstrate, with James’ help, that the value of producing requirements more than outweighs the costs of delays should problems be encountered, due to their absence, at a later stage. Her stakeholders understand risk, as most of them deal with it every day and accept that they should be playing their part in helping Beth to de-risk what is a complex transformation project.
To find out more about any of the points covered in this blog, contact us at info@clavertonconsulting.co.uk or call us on 0117 325 7890.
Comments