Requirements gathering should be done mindfully. Then there is this world we are living in, which requires agility, right? Well, can mindfulness and agile be imagined together?
Once you can imagine this your requirements will be solid and done right, and you will obtain agility. Your sign-offs will be also achieved smoothly. It won’t stop there. Development, unit testing, functional testing and UAT will be smooth as well, including your org readiness efforts, along with your usage uptake and learning experience. Does this sound like it is out of this world, or in Utopia as most of us know this is not a very easy thing to achieve?
So, really…how do we do this? This is revolving around good documentation, with data and process visualization. It starts with seeing the big picture and depicting it in the most logical way. Let me expand on this little more. Spend sufficient time to understand the problem first. Listen to the voice of the customer (this is the group we are gathering the requirements from). This will build trust between you and your customer. Do not turn anyone off by making them feel uncomfortable. Sometimes consultants (internal or external) do this as they present their involvement in a more hostile way, not politely at all. Agility requires a certain level of speed and by being mindful, at the requirement gathering phase, you will actually help down stream processes. You will also win the customer. By truly hearing their concerns, you will help them be creative in resolving their problems together. Use visual depictions. Diagrams, that are simple to follow and interpret, and sometimes even hand drawn sketches will help you tell their story in a unique way which will resonate with everyone, and be understood.
We all had worked with PMO assigned PMs, and for them it is just another IT project. It is not PMOs or PM’s responsibility to have agile requirements, they did not write the requirements. Do they even have to understand the requirements? Or have sufficient time to digest it, track changes, follow it up closely? Ultimately, aren’t they also responsible to deliver a project with an excellent customer experience? Between the time a requirement is written, understood by all, signed off on it, and given to PMO to do it, the document goes through so many iterations, it is hard to follow it. PMs just treat it as another item in their project plan, they don’t know much what’s in it! However, aren’t they the stewards of that document. Like a classical orchestra conductor, they should live and breathe it. I know what you think. I keep coming to the PM, but this is about requirements gathering, and documentation of it in an agile way. The document is not even used by PMs much. Developers use it, architects better know it, process owners should sign off on it. PMs really care about their project plans, and their metrics. They don’t have time to track anything in its entirety in an agile world. They just go with it, and conduct the whole thing without even knowing the music at all. As they run these sprints, it’s all about how many of these they deliver on time, under budget, right? Most PMs assume the quality of the requirements is already in place since it passed all of those steps. A PM most of the times don’t even think they need to know intimately about the product/service or whatever their project is delivering. They complete their project and move on to the next one.
If we gather and document mindfully then everybody will know the music. They will feel it, live it, get so close to it and consequently deliver quality projects. Overall customer experience will also be good and they will all be happy users. Learning will be faster and knowledge will be sustained. Simple visualization is the key for agile efforts. Know your customers well, know their process by listening to them. Spend up front time gathering their requirements after you hear their voice well, and know what they want. Use data and process visualization and simple, yet strong illustration in your documentation. For sustained and clever solutions that is the best approach you can adopt. All you have to do is to document what you hear mindfully, using visual depictions, illustrations, and sketches. Agility will start with this. You will see how it will help expedite all steps downstream and your requirements will be simply better and naturally agile when done mindfully.
