Written by: Erica Niesse
The Discovery phase of the project has just been completed, and now the Requirements phase is about to begin. Sales has transitioned to the implementation team, and the project has been kicked off.
During the Discovery phase, you compiled a list of relevant information about current business processes and the needs of your organization for a rewarding future implementation. The information gathered about current business processes will be the basis for analysis and detailed business requirements. Often an organization will jump immediately into the requirements phase when beginning an implementation, since they have spent a considerable amount of time in the sales process defining their future requirements. While we recommend a formal Discovery phase, if your organization chooses to skip this phase, you will still want to bring the information that you provided to the sales team during project scoping to your requirement gathering sessions.
The purpose of the Requirements phase is to take your current business requirements and transform them into traceable and consistent requirements that can be used by all areas of your organization. It is key to learn the importance of this phase. The future system configuration will be based on what is defined in this phase. Also, testing will be conducted on these requirements and end users will need to adopt them.
It is very important that all the parties involved in the project can collaborate during the Requirements phase, particularly the end users who will be using the project result.
Here are a few key considerations for a successful Requirements phase:
Review your SOW prior to the Requirements session
Prior to your Requirements gathering sessions, your vendor’s implementation team will have a transition meeting moving the project from the Sales Team. In this meeting, the Sales team will tell them about your team, your main goals in purchasing the solution, and highlight specific areas that are outside of the standard solution.
Often you have provided the Sales team with a number of documents about your organization’s processes and what you’d like to see in the future system. Make sure you save these documents so you can share them with your implementation team.
Before you start the Requirements gathering process, you will need to review your SOW with the vendor thoroughly. You will want to understand exactly what you have purchased and what will be in scope for your project. Items that fall outside of this SOW will typically require a Project Change Order, so you will want to make sure your team has also reviewed this document.
Your project manager will manage scope and if something is requested by your team outside of scope, you will want to discuss this with your implementation team. Your implementation partner will possibly have some other ideas for how to manage this solution that you are requesting, and you will want to consider those so that a Project Change Order is not needed.
What to Bring to a Requirements Session
Your implementation team has likely set up a session to gather the necessary requirements from your team. Depending on the complexity of the implementation this session can be onsite or remote. Regardless of delivery method, it is important that you come prepared. Ensure that you bring relevant information about current systems, pay policies, policy agreements, and reporting that your company would need included in the future system. Also be sure to bring documents gathered from the Discovery phase, such as goals of the implementation, Needs Assessment and a copy of any CBAs (Union Agreements).
Future Workforce Requirements
One of the first questions you should ask you implementation partner is: “who should be present at the Requirement sessions?” Your company will want to ensure that there is input from all stakeholder groups of the organization, including HR, Payroll, Operations, and the Project Manager. The degree of support needed depends on the size and complexity of the organization.
Now that you have brought together the appropriate team members and gathered the necessary documentation, it is time for the Requirements Workshop. Here are a few suggestions to follow during your Requirements Workshops:
- Encourage consistent processes across the organization. You will want to streamline your current processes, and make sure your rules and calculations are consistent across the company. Your company should try to avoid setting up a new or old rule for a small number of people. This will not only constitute additional costs but will require additional testing and timeline extensions.
- Adopt best practices provided by your implementation team. Your implementation partner will provide you with best practice suggestions for each area of the software. Take these suggestions into consideration and adopt whenever you are able.
- The less documents the better. Utilize the documents that are provided to you. Supplemental documentation outside of the provided Requirements documents can cause confusion for future phases. Keeping track of numerous documents can cause things to be missed in the Configuration and Design phases.
- Take ownership of Requirements documents provided by your vendor. Requirements documentation should be easily accessed. Place the requirement documents, and other provided documentation in a quick and easy place for everyone to access.
Analyze and determine if Requirements are outside of the SOW
The Key Stakeholders on the project will need to be provided with insight into the project risks. One way to provide them with further insight into the project is by creating a Gap Analysis. After the requirements are completed, your implementation partner can put together the Gap documentation.
This documentation will include items that are in scope, what is outside of scope, and hours estimates for how much the items outside of scope would add to the project’s cost. The goal is to break even when doing a gap analysis, which indicates that the SOW is accurate and no changes are needed. Often this is not the case, and will require a Project change order.
If these suggestions are followed in the Requirements phase, this will undoubtedly lead to a successful Configuration and Design phase. If additional time is needed in this phase, it will derail the timeline and subsequent other phases so make sure you are prepared ahead of time.
HRchitect is a leader in Human Capital Management (HCM) implementations for most major systems. As a strategic consulting firm, and not just an implementation firm, we understand the importance of best practices and bring this expertise to the Requirements phase to help ensure a successful implementation that meets the unique needs of your organization. HRchitect can also assist with HCM technology strategic planning, evaluation and selection services, and change management.
About Erica Niesse
Erica Niesse is the Director of Workforce Management Consulting Services at HRchitect. Erica has over 9 years of experience guiding clients through successful Workforce Management system implementations.