This is the third article in a series about buying and implementing software. Other articles include:
- Top three things to consider before buying new software
- How to organize your next software procurement
The dust has finally settled; your company has bought a software solution. While congratulations are in order, the journey is only halfway over. Now, the actual work begins - putting the software into production - in what is commonly referred to as implementation.
For most businesses, this is actually the most difficult part of the software procurement process. It is a culmination of all the work: the requirements that the project team documented, a myriad of demos sat through, and getting executive support to make the purchase. It’s also the point in the software procurement journey when any requirements that did not get documented will become painfully obvious, the project team has to get buy-in from users, and any technical enterprise debt will rear its head. To make your next software implementation a success, here are three things to focus on.
Clearly define implementation roles
On the implementation team, there are three key roles to fill. While the makeup of the team may change depending on the project, there should always be a project manager, team leader, and organizational change manager.
Project Manager
The project manager (PM) is central in every stage of software procurement and implementation. This is the individual that led the gathering of requirements and evaluated the different options before helping to identify the winner. The role of PM is the single most important position on a project and has the overall responsibility for its success.
This position comes with tremendous responsibility, accountability, ownership and authority.
Implementation is the point where a strong PM will pay dividends, or their lack of experience and shortcomings will become painfully obvious. This position comes with tremendous responsibility, accountability, ownership and authority. Not everyone has the skills to be a PM (there is a project management professional (PMP) certification, after all). For your next project, besides holding a PMP, look for a PM that has experience:
- Owning Responsibility and Accountability for the Project. The project manager, fully accountable for the outcome of the project, is the glue that holds the project together. The project manager leads the project with passion, as if it was their own business.
- Defines Project Roles and Responsibilities. The project manager is ultimately responsible for ensuring that project members understand what is expected of them and what they should expect from one another.
- Leads the Project Planning Activities. The project manager directs the creation, approval, and ongoing change control of the project plan.
- Performs Project Tracking. The top reason for tracking a project is to discover potential problems before they occur. The project manager applies this proactive approach in routinely tracking the project members’ progress against their project commitments.
The PM is also responsible for regular meetings with the project’s executive sponsor and other key stakeholders from across the enterprise. Without a clearly defined PM, confusion over the implementation is not just inevitable, it is truly unavoidable. Projects without clear leadership will fail to implement the solution and get adoption from across the organization.
Team Leader
The next key role on a project is team leader. For minor projects, this person may also be the project manager, even though there are key differences between the two. While the PM is busy communicating up, the team leader is communicating down. This delineation ensures that a communication breakdown does not occur, and that everyone involved in all levels of the project receives the information they need to be effective.
A knowledgeable team leader will ensure that the product works as intended.
As this person will make key configuration decisions, they should be a power-user in a management position within the department or business unit that will be primarily using the new product. While there may still be situations that require a higher level of approval, management should empower the team leader to make most process decisions. For your next project, look for an individual with these strengths:
- Initiator. Rather than tell people what to do, the leader draws attention to actions to meet team goals.
- Model. They use their own behavior to shape others’ performance—by starting meetings on time, for example, and following through on between meeting assignments. Leaders often rely heavily on this tactic, since they typically cannot use promotions, compensation, or threats of dismissal to influence team members.
- Negotiator. They get what they need from resource providers by framing the project as mutually beneficial.
- Listener. They gather from the environment signal of impending trouble, employee discontent, and opportunities for gain.
- Coach. They help team members maximize their potential and achieve agreed-upon goals. Coaching opportunities are abundant within teams because the skills members eventually need are often ones they do not already have.
- Working member. Besides providing direction, the leader must do a share of the work, particularly in areas where he has special competence. Ideally, they should also take on one or two of the unpleasant or unexciting jobs that no one else wants to do.
A knowledgeable team leader will ensure that the product works as intended. All too often, a person without experience in the business unit that will use the product has responsibility for configuration. This is a sure way to torpedo an implementation - if the product does not work correctly, or fit into existing processes, it’s not usable. Selecting a team leader with experience is a way to avoid this problem and set the implementation up for success.
Organizational Change Manager
The last position to include on every project team is the organization change manager. This is a specialist position that serves as an intermediary between staff that are using and providing feedback on the project and the project team. A change manager will play a key role in ensuring projects:
- Meet objectives on time and on budget by increasing employee adoption and usage.
- Focus on the people side of change, including changes to business processes, systems and technology, job roles and organization structures.
- Creating and implementing change management strategies and plans that maximize employee adoption and usage and minimize resistance.
- The change manager will work to drive faster adoption, higher ultimate utilization of and proficiency with the changes that impact employees. These improvements will increase benefit realization, value creation, return on investment and the achievement of results and outcomes.
A good change manager will help identify and address issues before they become a major roadblock.
While the change manager may or may not have supervisory responsibility, this person will have to work through many others in the organization to succeed. They will act as a coach for senior leaders and executives in helping them fulfill the role of change sponsor. They will provide direct support and coaching to all levels of managers and supervisors as they help their direct reports through transitions. The change manager will also support project teams in integrating change management activities into their project plans. A good change manager will help identify and address issues before they become a major roadblock.
It is important to note that there are more staff on a project than just the three discussed here. The specific project will determine other positions that need to be filled. By seeding your team with strategic leadership, configuration expertise, and user support, these three key positions will set your next implementation up for success.
Adequately test during implementation
Implementation is the time that the project team will have access to help from the vendor in configuring the product to meet the organization's needs. This period is crucial to a successful project, as any setup that is left undone will have a chilling effect on the usability of the product and return on investment.
Many organizations struggle to test a new product adequately. As the new software will supersede or entirely replace existing systems and processes, it can be confusing knowing where to start. Begin by reviewing any existing process documentation, including the requirements documents assembled at the beginning of the project. After reviewing this documentation, it should become clear exactly what the outcome (or output) from the solution needs to be.
Have real users, real data, real volumes, real authorizations, real interface and periodic job execution run through the system multiple times.
During implementation, the team will configure how the product works to the needs of the business. This information will be used to conduct Day-in-the-life (DITL) testing. The general idea behind DITL testing is to use the system the way you expect it to be run during a regular business day. Have real users, real data, real volumes, real authorizations, real interface and periodic job execution run through the system multiple times. The goal is to get as close as you can to a production environment before you go-live with the system to uncover anything that needs further configuration.
It's difficult to test edge, or unusual situations. As every day in business is different, you should plan on running DITL tests that cover 80 - 90% of situations that are common for your organization. Plan DITL testing in advance as end users will need to be trained and available for extended periods of time. If the new system interacts with existing partner systems, it will be helpful to include activities with real and synchronized data across the systems, real users, and real data volumes to put the new software through its paces.
Provide plenty of support and training for users
User adoption determines the utility of your new product. It can be perfectly setup, thoroughly tested, and all for nothing if no one uses it. Therefore, communicating to staff well before rolling out the product is important. It will take many months of regular communication before staff are comfortable using the new product.
Communication
Start communicating with the big picture; where does the software fit into the current business structure? Do not assume that everyone knows how it will affect their tasks. Rather, convey this information at the beginning of a training session or in a company-wide communication. However you choose to push out the information, keep it concise and to the point.
If the new technology is like something your employees already know, use the older software to provide a basis for understanding the new software. If the program is completely different, take the time to explain even the most basic parts. Even though it should feel intuitive, doing a quick lesson on the basics can transition much easier.
User Training
Just thinking about training an entire organization on a new software seems overwhelming. But it does not have to be. Break your training down into smaller segments and follow a hybrid approach. Some employees will prefer in-classroom training and others will like online training. Leverage your organizational change manager to spend some time learning about different learning styles and modalities to help get a handle on what might work for your team.
One method that works well is to have students attend an in-classroom training session or complete online learning modules for the basic and intermediate level features of the software. Next, set up 30 minute to 1 hour small group sessions of 1-3 people for employees to ask specific follow-up questions. The project team can do this. Then have additional online and in-classroom sessions for intermediate and advanced levels.
Setting Expectations
Always set your expectations before creating any of the learning curriculum for the new software roll-out. Expectation setting should also include looking at the expected ROI, and later the actual ROI, so you can establish goals. After you develop the goals and expectations, get formal feedback throughout user training. Try to automate feedback at each training session via an online survey. Remember to ask specific questions that require open-ended responses to get the best feedback. Avoid binary (yes or no) questions.
Next, determine how quickly everyone needs to be up to speed on the new software. Then do an assessment and measure the effectiveness. If you are not where you want to be, you may need to seek additional training.
Learn the program yourself, even if you will never need to use it. Understanding new software is critical to a system implementation whether you will work with it.
If the program helps drive your organization’s business, everyone needs to understand the basics to address software related issues and to understand how information flows. By setting the example of making the new software a priority, employees will know that their time investment in training is important, too.
Putting it into practice
Defining clear project team roles and responsibilities, testing the product, and supporting users throughout are key to a successful implementation. Especially if it is the organization’s first time implementing a new system, take plenty of time to plan. Placing artificial pressure to stand up a project team and put a new software product in production lowers the likelihood of success. Future projects will lean on lessons from prior projects. Keep documentation so that each subsequent project becomes easier. Last, build a buffer into a project’s timeline. Unexpected issues are bound to arise and having a few extra weeks of flexibility will help the enterprise be flexible.
This is the third article in a series about buying and implementing software. Other articles include:
- Top three things to consider before buying new software
- How to organize your next software procurement
