Banking

Three reasons to have a post implementation project

Jay Rollins reminds PMs not to forget about the post-project project. Here are three considerations for following up after the implementation of a software project.

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.

Conclusion

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!
11 comments
sysdev
sysdev

Numbers 1 and 3 are definite post implementation tasks. Number 2 is an item that should be taken care of during the project itself.

lmoritz1
lmoritz1

I agree with Jay Rollins that a post implementation project is an excellent process by which to find additional opportunities not covered in the orignal implementation. I'd like to two additional thoughts as to why to undertake such a project. One of the first reasons is the law of unintended consequences; for example, if one particular department within a company was the driving force for the implementation (let's say the legal department) of a new technology or application, it should be noted that this is only one cog in the overall process or value chain. Legal may touch areas including sales, production, risk management, procurement, finance, and human resources and the app or technology they implemented could have unintentional (read; "beneficial") consequences to many other parts of the organization (in fact, these benefits may be greater outside of the original department that mandated the new technology or application). Another reason is money. Often, initial projects are limited in budget with most of the budget being spent on the technology or new app. After 6-12 months and organization can much more easily "wrap its head" around how to make a new technology or application even more of an "exact fit" for their particular use and, more importantly, can quantify the benefits or the ROI of an add-on optimization secondary project. These benefits could include deeper integration with front end and back end systems, application customization, enhanced training, rollout to other departments, and other substantial benefits.

Ian Davis
Ian Davis

I may have missed the point here, but if the original Project introduces the concept of application/business support, and the scope of any support team covers quality and performance monitoring and improvement, then shouldn't these points be addressed by 'Business As Usual' activities and negate the need to instigate 'Post implementation Projects'?

erica.j.henson
erica.j.henson

Good article. I would be interested in a follow-up on how to get a 'fix it now, forget it later' culture to make this kind of practice a habit.

ivanemlim
ivanemlim

Thanks for sharing. This was consice and insightful. Well thought out approach for a holistic long term solution, rather than the short term "fix it now!" mentality which we have been caught in since...??? Given the recent past, and still tight budgets, do you think we will see more consideration for frugal and comprehensive project management beyond the 'get it out the door ASAP' variety? Wondering too, how this plays out in Small and Medium Enterprises, given your area of speciality.

maclovin
maclovin

A nice mini-list, with MAJOR points.

Ron_007
Ron_007

I see the point of having an explicit "post implementation" project/assessment is that it focus's on the project, ignoring all the other "business as usual" clutter. In all of the places I've worked, the "new products / projects" teams are separate from the "business as usual" production support teams. Sure the project team provides initial support, and sure people from the 2 teams talk, but rarely are the true costs of new projects objectively and fully assessed. So another reason for having this type of post-project is to evaluate the original cost vs benefit calculations used to justify the project. Too often the initial benefits are overstated and the real costs end up being higher than planned. If no assessment is done, the company continues to make bad decisions based on poor planning and they can't figure out why IT is "losing" money. The next project starts on basis "last project cost $x, this is equivalent so it will cost only slightly more than $x". But in reality the last project cost $1.5x after change requests, "over runs" and post implementation fixes are factored in. I highlight "over runs" because too often it's been a case where we (IT) provides an estimate the clients say "ooo, that's too much, make it less, without removing any features". So we skip and cut a few corners on the estimate, it gets accepted, and then surprise surprise things work out so the original estimate was on, but now the project is considered "over cost".

adriano.diamante
adriano.diamante

Good points Jay. At Shell we always have a Post Implementation Review after 6-9 months the project is rolled-out to the support organization, which is usually 8-12 months after the 'go-live'. All the reasons you mention are relevant and need to be addressed. Depending on the review results a new project or specific action points are agreed between the business team, the support team and the process owner/leader to overcome non-compliances.

Ian Davis
Ian Davis

I agree that these should be a Post Implementation assessment to evaluate the deliverables of the project. Unfortunately this article suggests a full blown Post implementation Project. Yes, Project Teams and BAU are separate but the project ends and is handed-over to the business. If you have Post Implementation Projects after 6 months does it need a Post Implementation Project of its own 6 months later and so on. We are into an infinite loop of Post Implementation Projects and other projects are neglected. This way madness lies. All of the reasons for a Post Implementation Project given in the original post fall within the remit of a QMS. Having a QMS and having a deliverable of the Project that ensures its application and continuous improvement by the BAU team is the way to go. There are other compelling reaons not to rely on a Post Implemtation Project. It is, or can be, used as a reason not to do the difficult things that provide the most benefit. Even in a well intentioned world, these tend not to be revisited. Any decision to defer the difficult until we understand the 'constraints' and 'nuances' can add cost as people try to use work arounds which increase costs. It is better to invest the time and effort up front to save these costs. 'Quality is free'. Get it right first time, hand-over and forget it. That is, in my experience, the best approach.

Ian Davis
Ian Davis

I think I agree. I have a large amount of experience on Infrastructure and transactional based business projects and the model I have described works (though care must be taken to use it as an excuse not to do). My experience of Data warehouse projects leads me to believe that you have a very good point (change often requires a new project be set up to instigate any change) and my experience of 'trail blazing' is very limited (I work in the public sector and we are not famed for trail blazing). Most importantly, I think you are stating that this is a 'horses for courses' scenario and I'd agree with that. My issue was that the original post suggested this had to happen and did not qualify any exceptions. If life didn't have any exceptions then the job of a PM would be all too easy (and then we'd all be out of work). To judge each project on its merits and use PM experience to ensure that a 'model' is built that facilitates improvements post 'go live' is, undoubtedly, the best approach.

Jay Rollins
Jay Rollins

Ian, I am always in favor of building in quality from the beginning and building a culture of continuous improvement where the avenues are open to suggest changes and shepard them through to fruition. However... I have yet to see this model in real life. I believe it is achievable in lower risk projects. Projects that are infrastructure-based or even replacing existing systems (typically transactional in nature) where expertise exists in the organization, this can happen. Information projects (i.e. CRM or Data Warehouse) and strategic projects where organizations are blazing new trails in new businesses, it is incredibly difficult to fully visualize all aspects of a project. Vendor best practices seldom fit every company's culture and nuances. There are always better ways to do things and the post implementation project provides resources (namely people and money) to make significant improvements. Without a separate budget and sanctioned human resources, only small, incremental improvements can be made. People still have their day jobs to attend to and gaining large leaps in process improvement typically require budget outside of approved operating expenses. Additionally, in smaller companies, having all the right resources to make things right the first time seldom exist. Hope this helps...