Continuing our series of interviews with industry experts, I recently chatted with Rob Beckmann, the co-founder and editor of Requirements Networking Group, aka RQNG.
Jama: Rob, how long have you been educating folks on the best practices of requirements management?
Rob: I have over 30 years experience in the IT field in various roles. At Caro Systems Inc., my focus during the last 10 years has been on the business architecture and requirements management challenges of our clients. I have advised and mentored on business architecture, requirements management and elicitation, and development methodology. Over the years, we developed some best practices that we share with our clients.
Jama: During that time, which aspects of the software development process have you seen evolve over the years and which aspects have remained constant?
Rob: “The more things change, the more they stay the same”. I’m not sure who originally penned that phrase but it is certainly true in this case. Back in the latter half of the twentieth century some of the smarter people I had the priviledge of working with were employing concepts that we would attribute today to Unified Process and Agile methodologies – we just didn’t call it that back then. The more prescient among us drove projects with the notion of delivering incrementally and frequently – in order to maintain interest and elicit feedback from the business community as early and as often as possible.
What has really changed over the years has been the growing recognition that this is a better approach, but we still see a lot of software development relying on a Waterfall methodology. Organizations that make an effort to adopt a UP or Agile approach will often fall into the waterfall trap and focus on one discipline or skill (usually requirements, in the early adoption phase) versus applying the approach to all disciplines and ensuring their teams deliver real working software in short iterations. Organizations definitely have their challenges adopting such an approach, the biggest being their social and corporate cultural concerns.
Jama: What compelled you to start the Requirements Networking Group (RQNG)? What problem did you see that the community web site helps address?
Rob: Studies such as the Chaos Report by the Standish Group certainly made the case that the root cause of many software development projects can be laid at the feet of poor requirements. We were also especially struck by the lack of consistency and varying quality of expressed requirements from various organizations. Each organization also had their own definition for the “business analyst” role and the skills needed in order to perform that role. This got us thinking about establishing an online forum where ideas could be shared and provide people with access to information and guidance. In July 2006, we launched the Requirements Networking Group in partnership with Richard Matthews of iONGs. Since that time, we have attracted nearly 12,000 members and the response has been exciting – exceeding all our expectations.
Jama: If you had one fundamental tip to provide people, what would it be?
Rob: Active participation from stakeholders in a project is key to that project’s success. It won’t guarantee success, but without it I can guarantee it will fall far short of what it should achieve or simply fail. Every project that I have been part of that has been acclaimed a great success has always enjoyed the active participation of one or two well respected individuals who could represent the stakeholder community and clearly express a vision for the software product under development. These people were committed, worked with the project team on a day-to-day basis and took ownership of the system. So, my tip would be to find the one or two people in your organization who are likely to be the most unavailable to you because they are so knowledgeable, well-respected and in high demand – and convince your management that they are critical to your project’s success.
Jama: What’s your perspective on the role of requirements management for organizations adopting newer Agile development methodologies?
Rob: A project organized along agile lines is geared to delivering functionality in very short cycles so that immediate and frequent feedback on the functioning system can be received and cycled through future iterations of the software product. This is very different from traditional waterfall approaches. Instead of “completely” documenting all the requirements up front before any analysis, design or coding effort takes place, the requirements will also evolve into more concrete needs as the development sprints execute.
The activities to express the detailed requirements must be planned to ensure they mesh with the sprints that will build to them. Feedback from prior sprints must also be taken into consideration to ensure important features are addressed at the appropriate time. This also impacts other activities, such as testing, to ensure they are planned in accordance with feature delivery.
Jama: Bonus question – If you were stranded on an island and had only 1 album with you, which would it be?
Rob: I like many genres of music (I’m even starting to develop a taste for classical music!) but I am especially partial to the blues so I would have to say a good anthology mix of Muddy Waters’ music would be my choice.
Jama: Thanks Rob for taking time away from your busy schedule to share your thoughts with us.
Tags: Agile, Industry News & Trends, John, Product Development, Requirements, software product development, Traceability, web-based requirements management
RSS
I was once at a conference where I gave an amazing demo of my software tool. (Feeling very impressed with myself) I asked the room full of people if there were any questions. Some questions were about this feature, others were about this best practice, and I answered them all perfectly. Once again feeling impressed with myself. Then an old gray hair, as I like to call him, stood up and asked me what I was going to do to address change adoption. Being a young whippersnapper at the time I stumbled around for a little bit and then was lucky that my time was up.
Your response about one of the biggest challenges that an organization faces in adopting an approach is social and cultural concerns, brought that experience back to mind. I know that the Anthropology of Product Management CoP, (#AoPM in Twitter) is focused on discussing ideas of how to address this challenge as a product manager. They are also in LinkedIn.
You often hear that active participation from stakeholders in a project is key to that project’s success. During a Twitter meeting using the hashtag #innochat, we talked about innovation as being the value that you bring to the stakeholders. If your stakeholders are not involved you will not understand their needs, not understand their objectives, not capture their input, not bring them value, and not innovate.
Agile- Meeting stakeholders/customers immediate needs with an evolving product. An agile product development team can have some of the most volatile requirements/releases because of that principle. Agile houses have to understand the importance of version control, traceability, and suspect links. Requirements Management principles that if ignored will kill a shops ability to hit deadlines and cost expectations on iterations and releases.
Lastly during a PMI meeting this week in Austin we talked about feedback and review during/after a project. Don’t wait until it is too late to do anything about the situation to collect comments and feedback. Collect comments on everything, everywhere, that way you have them when your ready to act.