A new software implementation can be both an exciting and challenging time for an organization. If the project is executed successfully, a company can experience significant improvement to its daily operations with new features and workflows that new software often brings. The unfortunate reality is that many of these projects will struggle from the start and these benefits are never fully realized.
Project managers have a process at the closing of a project or phase where the team looks retrospectively at their successes and failures. This is referred to as a “lessons learned” event and provides valuable feedback to both the team and the organization to prevent mistakes and replicate successes in the future. The following topics are all lessons that have been learned, sometimes painfully, through years of implementing software with a variety of providers in both privately held companies and traditional hospital organizations.
Applying these concepts to your next software implementation can help you avoid some common mistakes and take full advantage of new tools emerging in the market.
1. Missing leadership at project kickoff:
A successful project kickoff will propel the project team with positive momentum and a clear sense of direction. This momentum is sustained through the accomplishment of tasks and milestones. When it comes to new software implementation, there will very likely be team members who are resistant to such changes; and when leadership is lacking, it can cast doubt upon the entire project. Resistance can bring projects to their knees, where progress becomes fierce trench warfare between two groups arguing over seemingly every problem.
It is the leadership team’s responsibility to affirm a strong commitment to the change as the direction for the organization. This commitment will repel the formation of these hostile factions and give the project the needed boost to accelerate progress. Ideally, having a leadership representative on the project is a great way to showcase that the project objectives are a priority within the organization. Although the scope and duration of the project might require slightly different frequency, an attempt to have at least monthly progress meetings would be a great start to stay informed and engaged in high-level decision-making.
2. Insufficient or late requirements gathering:
Despite the improvements new software brings, there is often a different workflow for how data moves through the system. After the project kickoff, a requirements gathering process should begin to identify the needs, wants and preferences of the affected departments. This could be gathered informally during training, but ideally, these requirements should be documented by the project team. It is generally best to tackle these potential conflicts as they come up so that an amicable solution can be identified within the constraints of software functionality. Additionally, by gathering requirements early, there is a possibility with some software vendors to gain access to enhanced functionality prior to go-live.
How should an organization start such a process after kickoff? If your organization does not already have process mapping around what is referred to as your “current state,” this should be the very first effort. Document every part of the current process, including manual transfers of documents or information.
This current state documentation is then referenced during the training on the new system to identify the fundamental differences between the two different workflows. When a difference is found, it should first be documented and then later discussed in detail with a larger team. If the new workflow achieves the same, or ideally improved result, it will likely be accepted and the beginnings of a “future state” process started. As each area is explored, the future state process map will begin to take shape to encompass each functional department in your organization.
3. Underdeveloped lead user group:
Among the most challenging implementations are those where the lead user group is lacking a detailed understanding of the software. Typically, in most large software implementations there will be a small group of management or subject matter experts that will be the first to learn the software and make decisions regarding the process development around it. There are two points of failure that will typically come up with this group.
The first point of failure is the composition of the group itself. A common mistake is to have only management or director-level team members in this group. A strong team will consist of not only leadership, but also some of the subject matter experts out of the user group. Most organizations have a couple of leaders in the user group who seem to know everything and have the inside knowledge of how work is actually completed. Their inclusion on the team provides not only valuable insight but also equips them with knowledge of the new software to continue to be strong leaders at go-live to support the user group.
The second point of failure is when this group tries to stay out of the details of specific processes in the software. Too often, a criticism of the leadership team is that there is a tendency to keep things high level and never fully understand how the software thinks and operates in its day-to-day operation. What ends up happening is that after go-live, these leaders are so out of touch with the software that they cannot take decisive action in the future as the organization evolves. For best results, be sure to include your subject matter experts, and have everyone ready to learn the software. More specifically this means knowing each function, its intended purpose and being able to actually perform the same work that users will be expected to do in the future. This might seem like a lot of extra effort on the surface but the knowledge and insight gained in this process will be invaluable in the future.
4. Process breakdown at go-live:
The go-live event is generally a stressful time period for most projects, and even with all of the planning in the world there will be a little tension when a new software is launched into a production environment. A majority of concern for users is being unsure how to accomplish their daily tasks with the new application. However, with careful preparation much of this anxiety can be alleviated.
A frequent mistake is that the developed process documentation does not always make its way to the end users. A process map is a great thing, but without a translation component in place it can be hard for the average user to interpret what each process means in the software. Remember that a process map is usually high level and not granular enough to show the individual button clicks a user needs to take to accomplish said process. This is where a document called Work Instructions comes into action. Work Instructions will define detailed step-by-step actions how each function is to be completed (e.g., new orders, prescriptions, etc.).
When the process map is combined with detailed Work Instructions, you create an informed user who is given the resources to help themselves through their daily work. When users feel they understand their work, they will be much happier, and it will reduce the strain on the management team.
At times, there could be a deficiency with the new workflow presented. These conflicts can be very hard to navigate toward an acceptable solution. The first step should be to engage your software vendor on these problems—they could already have solutions not advertised to common issues. If an acceptable solution cannot be found due to either design or time constraints, a new workflow will need to be crafted to work around these deficiencies. A strong software vendor will consider changes to future versions to resolve these conflicts when appropriate.
As a final anecdote, some of the most successful projects were great primarily because of the people involved. Although intangible, there is something to be said about a positive mindset and a team that has a fierce tenacity to get the work done. With any large project, it is almost a guarantee that problems and conflict will come up at some point. If the team can get through those tough times, this can act as a catalyst that drives the project forward to success.
