Working this week on customer site to gather project requirements, our focus has been on the technical and business requirements, driving towards design and hopefully signoff.
The architect has been leading with the technical requirements, against a template we use internally. But in actuality he’s been capturing the current solution for the customer but not the future plans, as none of the stakeholders in the requirements sessions has a view as to what the future holds or if they do have a view of the future requirements, they’re not empowered to make a decision on the requirements. Something we discovered after each session.
Added to this there are a lot of customer stakeholders, with no governance from the customer – no one overseeing the conversations with having with the different teams.
This is making life difficult as no-one within the customer’s organisation is taking responsibility for requirements governance, as requirements drive design they are therefore are not actively involved in the design decisions.
Not ideal if you’re ultimately seeking design signoff from the customer!
However it seems that the customer’s expectation is we’ll provide all the answers and they don’t need to be involved. Which could work, the risk is that the customer will reject our proposed design. To mitigate we’re starting a series of design workshops, which will effectively bring the senior technical stakeholders on the customer side, give our chance to present the requirements (current operating state) and the new world proposed, but also the benefits it’ll provide.
My feeling is because there is no “requirements gathering” governance, we’ll burn more time covering old ground, but ultimately needs to be done.
But I wonder, if there’s an approved methodology to gather requirements. With the right level of governance that ensures involvement from all teams. Something i’ll ponder and happy to hear feedback on.
iamitpm 