Most association technology projects follow the traditional, waterfall methodology in which one phase of the project follows another, without any repetition of stages. This happens because association enterprise systems like association management systems are configurable – vendors aren’t developing them from scratch.
However, if a project involves the development of new technology, like a customized mobile app, developers may use an agile methodology in which the project is broken up into a series of cycles called “sprints.” These cycles of testing and feedback require a much higher level of staff engagement and communication than the waterfall process.
Regardless of the methodology used, these 4 techniques for identifying and communicating requirements during an agile development process can be applied to the requirements stage of an agile or waterfall project. They will help you clearly communicate to your internal IT department or your vendor what you need, so you have a better chance of actually getting it.
1. Establish the ground rules for making decisions.
Before the discovery or requirements-gathering process begins, you must have the right people in the room and be able to answer these questions:
- How do we know as a group when we’re done with the requirements?
- How are we going to make that decision?
- Who has the authority in the room to make that decision?
2. Plan for a structured conversation.
Don’t just sit down and start talking about requirements. You must have a structured conversation to ensure you deliver clear and complete requirements. It’s easy to overlook major factors when you approach discovery by starting with the question, “What do you want?”
Having a tool for discussion visible either as a handout or on a poster – like the product dimensions below – helps provide the framework for a complete conversation. Consider it the “who, what, where, when, and why” for requirements – who are the users, what is the interface, what is the user environment, etc. As the project evolves, each dimension may be further developed.
3. Discuss expected value first.
Don’t be tempted by bells, whistles, and fun functionality. Focus first on the value that the product must provide in order to achieve your goals – not product features. What problem are you trying to solve? What value do you want to bring to the user? A vision statement can help clarify goals, for example:
- What is the problem? Low student registration with existing online platform.
- Whom does this problem affect? The 50% of members who have expressed interest in online education.
- What’s the impact of this problem? Members want online education but can’t access it easily.
- What is a successful solution? Students use their association login on their laptop or tablet to access an online platform where they can participate in an online learning experience and take away a unified transcript.
That’s what the product must provide to be successful.
4. Write testing requirements before leaving the room.
When you’re developing product requirements, don’t forget to include a test plan. All requirements must be testable in likely scenarios. One technique – user stories – illustrate how a user (member, staff, or someone else) will interact with the product in real-life situations.
For example, there may be a series of a user stories about a member who needs 10 hours of continuing education a year to maintain her certification.
Each user story will include details of each element of the process and can be prioritized and developed separately, for example:
- The member uses the online registration system to login and purchase a course.
- The member sees the total number of credits earned to date.
- The member can print a copy of her transcript.
The key is to define, prioritize, and illustrate what the product must do to meet the core set of requirements. Real-life scenarios like this one are very helpful to the configuration or development team. They can use these stories to pre-test the product before delivering it to you.
You know the old adage: success is 90% preparation and 10% execution. Be better prepared to articulate to your vendor what you need and why by:
- determining ahead of time how requirements decisions will be made,
- having a framework for discussions about requirements,
- focusing on value, and
- delivering testable user stories.
Flickr photo (dog) by Thomas Teubert