The 6 components of a good requirements analysis process
- Dave Coriale
- July 18, 2014
You know that moment in the board meeting when they approve the budget for the new AMS, CMS, or other system you’ve been lobbying for? Yes, that was a beautiful moment – but now that the system selection battle is won, it’s time to come down from your high and prepare yourself, your colleagues, and your leadership for the project that lies ahead.
You might think, “I’ve been waiting for this for a long time. I’m ready.” Maybe you feel ready, but is your association ready? Are they prepared for the most critical phase of a technology project – the requirements analysis phase?
Here’s what your association must have in place before starting the requirements analysis (RA) process.
1. Leadership takes ownership of the project.
As the project lead, you own the project, but your CEO and senior staff must behave as if they do, too. They’ve given their blessing to the project; in fact, they helped get approvals from the budget committee and the board. But you are going to need more from leadership if your project is to succeed.
In the past, technology implementations like new servers or applications were mainly the concern of the IT department. Now, because technology is entwined with everyone’s job, system implementations involve a larger percentage of staff and budget than ever before, and that involvement starts during RA.
Leadership must come to understand how much business analysis, project management, and technical experience and expertise is needed to successfully select and implement new technology. They must be willing to dedicate the appropriate resources to all phases of the project, not just the implementation phase. Hopefully, you kept that in mind when requesting your budget. The RA phase of a project is too often given short shrift, yet that’s the phase that can make or break a project.
2. Staff is fully on board.
The input and buy-in of internal stakeholders is absolutely necessary to ensure project success. A representative of each department or position that will rely on the system must participate in requirements gathering. If stakeholders are left out or don’t dedicate sufficient time to the RA phase, critical functions or processes could be overlooked and the final product won’t fulfill business needs. Staff must also make time to review and approve the requirements documentation so they have a clear understanding of the project’s deliverables and a sense of ownership in the expected outcome – don’t underestimate that last piece!
3. Planners are mindful of departmental calendars.
When planning a project timeline, find out if your project team has responsibilities that must take precedence over the project.
- Are conference or education staff in the midst of a busy meeting cycle?
- Will staff be consumed with developing budgets for the board?
- Will lobbyists be unavailable because of legislative or regulatory hearings?
- Are membership staff working on a renewal campaign or membership drive?
Coordinate with department heads to make sure staff will be available for the requirements, testing, and training phases of the project. If their participation is to take priority over other tasks, or if duties must be reassigned temporarily, the CEO and senior staff must make that clear from the start. In a tug of war between a project manager and a department head over someone’s time, the project manager will lose every time unless leadership has made it clear what must be done to keep the project on schedule.
4. Everyone gets behind a shared project vision.
Each stakeholder will come to the requirements gathering table with their own departmental agenda – that’s natural – but they must understand how that fits into the bigger picture. Do they understand the project’s goals and how they relate to the association’s strategic goals? You want to make sure the team “gets it.” They need to see the larger, strategic picture – how the new technology will help your association achieve its goals and fulfill its mission.
5. No one is left in the dark.
Communication starts early with the CEO and senior staff communicating their vision, goals, and expectations for the project to everyone in the organization. Leaders clearly signal to staff that this is an organization-wide project, not a departmental project. You have a plan to keep everyone informed about the project’s progress. And you stick to it – keeping the lights on, so to speak, so no one is left in the dark.
6. Everyone has a positive attitude about change.
Let’s face it – a system implementation is a change management project. During the requirements analysis process, discussion about changes to business processes, workflow, and staff responsibilities can cause conflict, stress, and anxiety. Although it’s not always easy to let go of “the way we’ve always done it,” leadership and staff must resist looking backward so they can help your organization move forward.
Your technology project is more likely to succeed if you take the time to prepare your organization’s leadership and staff for their project roles and if your organization dedicates the appropriate resources up front to collecting and analyzing requirements.
Flickr photo by aussiegall