Within six months to one year after an initial software implementation project is complete, there is always a need for a second project to address opportunities with the original implementation. Always is a pretty strong word, but so far in my career and the careers of many of my closest peers, this is always true.
If we look at the beginnings of a software implementation project, there is the requirements gathering step. Project managers apply various levels of detail during this period. Some requirements are gathered with a straightforward interview and documentation process; other requirements are captured with more detailed process mapping exercises designed to streamline the existing process and make the software more valuable right out of the box. But it is the requirements process that helps to manifest the first of three opportunities after an implementation.
1. Idealistic vs. realistic
Typically with a new system we try to do things better than we have in the past. In brainstorming sessions, process mapping exercises, and requirements interviews, the goal is to try and improve upon the existing. For many processes, this can be achieved, but with other processes, the new way of doing things is not realistic -- there are nuances, dependencies, or constraints that are not considered at the beginning of a project. Addressing these opportunities as they are understood will help longer term adoption of whatever product you are attempting to implement.
2. Employee gaming
The second scenario seen within the first year of an implementation is employees trying to game the system. Employees tend to figure out ways to do things faster or differently to achieve what they perceive is the end goal; this is not necessarily the end goal of the data capture activity as a whole, and they may not realize how that impacts the system.
Many front-line employees don't necessarily see the benefit of adding all the data that is requested in a system; their focus is on completing their tasks and not what the data they enter feeds some other necessary part of the system. Call it misaligned goals, laziness, or self-determined efficiency, but employees will find a way to work around what you are trying to do.
A standardized process evaluation task monthly after the project is up and running will start to uncover these workarounds; but mini projects designed to apply long-term fixes, features, or updates will be needed to ensure you are continuing to achieve the overall goal of the system you just helped implement.
3. What if...
This is probably the most visible and impacting of the three reasons to have a post implementation project.
Once a system is implemented, employees take several months to get used to it. Sometime between six and twelve months, employees are so comfortable with the system that they start contributing ideas on how to do something better, faster, or more efficiently.
These are great opportunities to take advantage of because these ideas will typically allow your project to achieve metrics earlier than originally forecasted. If you do not address these opportunities quickly, a negative side effect may occur. For example, at a previous company, a new financial system was implemented per an extensive requirements gathering session. Employees had a ton of "What if..." questions eight months after the system was deployed; when these questions went unanswered, spreadsheets started popping up to address the system's limitations. Two years went by, and sure enough, several of the core processes that contributed to the financial statements were now in spreadsheets -- all without the financial controls necessary to ensure accurate and verified numbers, which is a big no-no since Sarbanes-Oxley came out. Some of the spreadsheets were on individual desktops that were not backed up, so the "hit-by-the-bus" syndrome was also in full effect.
One or all of these opportunities arise up to one year after a system is implemented. As a project planning step, I highly recommend adding a post-project project to address these issues upfront. Budget for this project and plan for it as part of the initial implementation. If you wait until these issues are revealed on their own, it could be another year or two before you get the new budget to fix everything. At that point, it will be a lot more work to accomplish what you need to get done. Employees will already be set in their new workarounds and process shortcuts only to have to go through a large change process again. If you can address these opportunities while they are still
opportunities, costs associated with the follow-up project can be recouped very quickly.Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!