Changing the Conversation on Software Requirements: Collaboration in the IT Team
Delivering Business Value is a Team Sport
Last week, I talked about how to change the conversation of better software requirements from creation of the “perfect” requirements documentation to establishing joint accountability between the business stakeholders and the IT team for the success of the project. This week, I want to talk more about how this approach can carry into the detailed phase of the project.
In July I attended my company’s “Tech Talk”. My company, a software development company called Geneca, regularly holds Tech Talks to give employees the opportunity to share technology information. Even though I am no longer particularly technical, I like to attend these sessions in order to keep up on the technologies that my peers and the industry are using. At the last Tech Talk, Chris Johnson (one of the developers) spoke about a high-productivity web framework for Java development. I know – you’re asking “what does this have to do with better requirements”.
What really excited me about Chris’s talk (since I didn’t really understand all of the coding detail) was when he explained that one of the big advantages of using this technology was that he could partner with a Business Analyst (BA) during the requirements process and actually create web prototypes while the business was explaining what they needed. The business stakeholders could see how the team was envisioning delivering the solution and give immediate feedback. The developers would also get a head start on the code for delivering the solution.
To me, this was an excellent example of how the entire IT team can work collaboratively to deliver true business value. My co-worker wasn’t holding the BA solely accountable for ensuring that we had the correct requirements. Rather, he was making the conversation about ensuring everyone was accountable for understanding what the business really needs and for delivering business value. And, by working together, all parties (the business stakeholders, the BA and the developers) can better share a common vision of the solution.
Think Beyond the Requirements Document
I have worked in other environments where the BA would have been threatened by the idea that a developer could create a working prototype during requirements definition. By including the developer (or a PM or a tester) in the requirements process, there might be fear that the BA role would be devalued. But, a good BA needs to understand that the role of requirements definition is not just in the realm of the BA. In fact, ownership of the requirements really belongs with the business stakeholders. The role of the BA is to help communicate the business vision to the rest of the team, by whatever means works best.
Rather than focusing on the requirements document as being central to their existence, the BA needs to find the best vehicles for communicating the business vision to the rest of the team and for ensuring that the team works together to deliver what the business expects. This can be through written requirements, through diagrams, or verbal communication. Or it can be by including other team members – the PM, the developers, QA tester – in the requirements process so that entire team understands the vision and is focused on delivering business value.
When everyone on the team is working collaboratively and holding each other accountable to meet the project’s business objectives, then the project will be a success – regardless of whether the requirements documentation is perfect.
How does your IT team insure that they are delivering business value?
Category: Business-IT Alignment, Defining Success, Requirements Definition, Uncategorized