As soon as the budget for a new system or software is approved, it’s tempting to start developing an RFP and begin looking for vendors. But wait a minute. Now’s the time for more talk, less action. Yes, you read that correctly: more talk, less action.
The initial conversations about any technology project should focus on people, not solutions.
These conversations are often led by the project manager and involve the people who will be selecting and implementing the new system—the project team.
Conversation #1: Define project roles and responsibilities.
The goal of these discussions is to:
- Identify project stakeholders and their relationship to the project.
- Ensure you have all the correct team members on the project team.
- Identify user classes that need to be part of requirements gathering.
- Solidify members of the project team and their individual responsibilities.
As a result of these conversations, the project manager develops a RACI matrix. RACI stands for the four levels of project responsibilities: Responsible, Accountable, Consulted, and Informed.
For example, if we were to describe the work involved with data migration, and I’m simplifying things here, the RACI matrix might show that:
- The IT director is accountable for a successful outcome.
- The project manager and the database administrator are responsible for successfully migrating data to the new system.
- The membership director must be consulted about the data migration.
- The CIO must be kept informed about the data migration.
What makes the ‘responsibilities’ discussion so important? Despite its importance to project management, the RACI matrix itself isn’t the most valuable outcome of these meetings. Rather, it’s the conversations that resulted in the matrix that provide the greatest value.
Here’s why: Projects are more likely to succeed, and timelines are more likely to be met, when everyone involved has the opportunity to talk through the matrix and come to a mutual understanding of each other’s roles and responsibilities. The project team gets a feel for how one person’s task is dependent upon another person doing their part first. People know whom to keep in the loop and whom to consult when making decisions.
Conversations like these don’t always happen, but they should. Too often, project team members are assigned roles and they immediately get to work. But do they really understand where their responsibilities begin and end? Are they consulting and informing the appropriate people?
Conversation #2: Know what success looks like.
When an association has a problem to solve, such as a cumbersome registration process, too often they jump right into conversations about solutions—systems or platforms that can solve the problem or provide the desired capability.
Don’t do that. Don’t talk about solutions yet, it’s still too early. Instead, this is the time to talk about project goals and requirements, not solutions.
What will success look like? Perhaps you want to reduce calls about registration. Or, you want to have access to better data about registrants, for example, what prompted them to register, or how many of them have attended before. These are your business requirements.
Talk about user needs too. Or even better, find out what users actually need by asking them, looking at analytics, and conducting usability testing. In this case, you want to understand both the needs of staff and the needs of registrants. Don’t start hunting for solutions until you have nailed down your requirements.
How does a business analyst help your project meet expectations?
An experienced business analyst has a proven process for guiding associations through the requirements phase of a project. They go into a technology project with one goal: to ensure the product or service delivers the expected value to project stakeholders.
The business analyst’s responsibilities include planning the requirements approach, identifying stakeholders and user classes, and managing requirements throughout the project. The business analyst also will define, analyze, prioritize, and document:
- Business requirements
- User requirements
- Functional and non-functional system requirements
The accuracy and thoroughness of your requirements determine the success of your project. Technology that doesn’t deliver what your association truly needs is a waste of resources—both time and money.
An experienced business analyst uses many methods to elicit requirements from the stakeholders, including requirements workshops, interviews, user interface analysis, and persona development.
Can an outsider be a good thing during a technology project?
In addition to expertise, a business analyst also brings another asset to a technology project: objectivity. Unlike others on the team, the business analyst doesn’t bring a departmental bias to project discussions. They can call out attempts to move things in a certain direction for political or cultural reasons. They know which questions to ask to reveal issues and needs, and can safely ask those sometimes difficult questions, like:
- Can we simplify this complicated policy?
- How often is this custom function used in the current system?
- Why does the report have to look like that?
It’s easier for an outsider, like a business analyst, to bring sense to a complex situation and provide an experienced perspective on existing and potential scenarios.
Every organization benefits from paying experts to come in and tell them how to improve practices and policies. We do it here at DelCor all the time. When you’re about to invest significantly in technology, you shouldn’t go it alone either. Dedicate resources for expert business analysis and project management. You’ll end up having conversations that lead to the best solution—one that meets (or exceeds) your expectations and is implemented within your timeline and budget.
