Simply finishing doesn't ensure that the organization benefits from the project's outcome. For example, after completing a year-long project to establish a new quality management process for your organization, you want to make sure that what you set out to do was actually achieved.
Your objective wasn't to simply deliver a process — but rather, to deliver the process that addresses the specific business need you intended to meet.
This is the real measure of success. To make the most of the benefits that the project can deliver, however, you also need to check to see if further improvements will deliver still greater benefit. You also need to ensure that the lessons learned during the project are not forgotten. You can more effectively design and execute future projects when you take advantage of lessons learned through the experience of previous projects.
So how can you properly measure a project's success, and work toward continuous improvement? It helps you answer the following key questions:. The key to a successful PIR is recognizing that the time spent on the project is just a small part of an ongoing timeline. For people and organizations that will be working on similar projects in the future, it makes sense to learn as many lessons as possible, so that mistakes are not repeated in future projects.
And for organizations benefiting from the project, it makes sense to ensure that all desired benefits have been realized, and to understand what additional benefits can be achieved. A good time to start thinking about the Post Implementation Review is when members of the project team remember the most — shortly after the project has been delivered, and when most of the problems have been ironed out.
Start to list ideas and observations while they are still fresh in people's minds. However, to adequately assess the quality of the implementation and complete this process, you'll need to wait long enough for the changes caused by the project to truly take effect. You can learn another 64 project management skills, like this, by joining the Mind Tools Club. Receive new career skills every week, plus get our latest offers and a free downloadable Personal Development Plan workbook.
There will probably be a period of adjustment before you can finally review the solution as it was intended to operate: you'll likely need to overcome some of the usual resistance to change, hold people's hands while they operate new systems, and eliminate technical problems that didn't emerge when deliverables were tested.
You should therefore typically allow a few weeks, or even a few months, before doing the full PIR. Where possible, allow for at least one, full, successful cycle of business before reviewing lessons learned. As you perform the post-implementation review, certain methods and practices will help you obtain the best possible information:. As you plan your PIR, be aware of the costs and benefits of the review process itself. Interviewing stakeholders and customers, testing the solution, and documenting the results are time-consuming activities.
Make sure the time and resources dedicated to the review are consistent with the project scope and its output, and that the potential benefits of conducting the review are worth the effort put in.
Its purpose is to evaluate whether project objectives were met, to determine how effectively the project was run, to learn lessons for the future, and to ensure that the organization gets the greatest possible benefit from the project. After a long project, the last thing many project teams want to do is relive the process and look for ways to improve.
go-live (go live)
However, a forward-looking review can discover many tips and strategies for improvement. By conducting a thorough and timely PIR, you'll identify key lessons learned — and you can then apply those lessons to the planning and management of future projects. This site teaches you the skills you need for a happy and successful career; and this is just one of many tools and resources that you'll find here at Mind Tools. Subscribe to our free newsletteror join the Mind Tools Club and really supercharge your career!
Expert Interviews Audio Forums Infographics. Quizzes Templates and Worksheets Videos. For Your Organization. By the Mind Tools Content Team. Finding This Article Useful? Subscribe to Our Newsletter Receive new career skills every week, plus get our latest offers and a free downloadable Personal Development Plan workbook.
Unfortunately, flawed system go live executions happen all too often. You might wonder how this is possible, after dozens of people have worked for months on an implementation. The following 10 points should be part of your readiness assessment before management gives its blessing to convert and go live:. Modification process: All testing of modifications need to be done first by IT and then by department management.
Testing: Complete end-to-end testing and conference room pilot testing from origination of orders, returns, receipts and shipping through to systems processes.
This includes inbound product flow processes and outbound shipping functions. Be sure to process live data through to accounting and management reporting systems. File conversion: Have the necessary files been successfully converted on a test basis and visually spot checked to the files on the current system.
With SQL systems in large multichannel environments this may take days to convert customer files. How does this affect your plans? More testing: Do volume testing with website and call center phone orders to get a feel for how the system will respond when processing actual transaction volumes.
Check the interfaces: Have you tested all the interfaces with vendors, ASN and EDI services, marketing services, credit processors, etc.? Training: Have all the employees in various departments been trained? Are new standard operating procedures in place? IT readiness: Is IT ready to support the company with knowledge of the daily processes, and is all equipment installed in IT and user departments?
For sure, there is intense pressure when you miss a go live date, as this means incurring additional project costs and taxing limited resources.
Curt Barry is president of F.Implementing an ERP Software is a huge and a very cumbersome task in itself. It involves money, time and high involvement from the resource.
Hence, it becomes important to be aware of all the aspects related to implementation. Usually the company goes ahead and hires an ERP consultant who is a third party consultant acting as a bridge between the ERP and the company. During this times, the true capability of the ERP can be known. It is not impossible to have a smooth Go — Live process. Here is the ultimate Go — Live checklist which will help the management be ready during the whole Go — Live process.
Even before you start with the implementation, the Go —Live date should be set in mind and the team should start working backwards to end up with realistic targets and dates. Sometimes the company may want to get the roll-out done all at once and sometimes, it may choose to roll-out the ERP Software either branch wise or module wise.
In these cases, it is important that all the parties involved in the ERP Implementation process is aware of the same. If the roll-out is happening branch wise, it is important that the parent company is supporting the branch with ample amount of training and workload sharing.
As mentioned previously, training is an important part of any ERP project. The training phase should not only focus on training, but also on smaller aspects of training like if the user ID has been created and the individual user rights have been assigned to the particular account. By the end of the training, the trainee should be well-equipped with:.
At this point of time, we are done with major workflow checks — software and hardware, training and communication with the customers. A day or two prior the Go — Live, the company needs to check the readiness from people to machines. A last minute check of server, electricity lines, ISP connections, help desk lines, Wi-Fi speed, connectivity, etc. Along with the systems, checking the readiness of people is equally important. Checking if the staff has their user IDs created and knows their roles before the Go — Live happens.
There will not be a lot of people needed for the process overall, the major help and support is required to handle customer calls and co-ordination for online processes which will be handled offline for the time being. The management should also focus on keeping up the excitement level amongst the employees as their readiness to accept the new change is very crucial for the success of the overall process.
The staff even might need to work early or late due to changes and this needs to be communicated to the staff beforehand. Conducting a last system walk through will also be beneficial. Employees — Post Implementation, it becomes essential to primarily monitor the users.
The management should identify any loopholes and plan for further training if necessary.Go-live is the time at which something becomes available for use. In software development, for example, go-live is the point at which code moves from the test environment to the production environment. As a verb, go-live means to make such an event happen. At the time of the go-live, a system is officially and formally available to users who can then initiate transactions in the new system.
In enterprise circles, the term go-live is particularly associated with systems that help manage business functions such as ERPCRMor HCMfinancial, logistics or marketing systems. The go-live concept itself taken in isolation is straightforward -- the system truly goes live. However, a successful go-live typically depends on an array of complex factors, especially for big companies or those implementing expensive, wide-scale ERP systems, and many go-lives do not go smoothly or they suffer outright failure.
This is because a go-live is arguably the most critical milestone in a technology system implementation. An unsuccessful go-live can cost companies millions of dollars and create a cascade of business problems. Although large-scale on-premises ERP system implementation is falling out of fashion in favor of standalone systems and cloud-based delivery, the go-live becomes no less important. To avoid failure, a go-live for a smaller implementation will still need excellent project management to ensure success.
The elements required to create any successful go-live, and in turn, system implementation, include a solid business case with executive business sponsorship and leadership, in-depth change management and training, thorough testing, realistic timelines and thorough rollout plans, and plans for and attention to details such as ensuring correct data.
The specifics of a particular project will be based on a number of factors, including the size and type of system being implemented; the number of business users or customers that will be affected; and the complexity of the implementation.
Please check the box if you want to proceed. This handbook looks at what Oracle Autonomous Database offers to Oracle users and issues that organizations should consider Oracle Autonomous Database can automate routine administrative and operational tasks for DBAs and improve productivity, but Oracle co-CEO Mark Hurd's abrupt death at 62 has put the software giant in the position of naming his replacement, and the Managing the data contained in your enterprise data lake presents many challenges.
From the amount of data to data With organizations of all sizes coping with the impact of COVID, the importance of enterprise data governance and chief data On-site monitoring centers come under stress when it's necessary for most workers to telecommute.
Here are key points to include There are three different SuccessFactors implementation methodologies. Here's the information you need in order to select the one Some finance departments are turning to SAP Concur for accounts payable automation to manage processes and increase accuracy. Enhanced SaaS capabilities and tools to help customers migrate their analytics operations to the cloud highlight the latest A new offering from the Atrium consultancy hints at how Salesforce's Einstein Analytics and Tableau may complement each other now The global pandemic has forced many businesses to make quick changes.
Good database design is a must to meet processing needs in SQL Server systems.
In a webinar, consultant Koen Verbeeck offeredFor years your organization has been planning and preparing for a complex Electronic Health Record EHR implementation and at last the ticker is finally at zero and you are live! Hours after your go-live you realize while the clock struck zero on your countdown, the work for system stabilization and optimization is already piling up.
Understanding what an organization can expect post go-live of an EHR system implementation is critical to the long-term success of the organization. Here are four key challenges you can expect to encounter after you are live and some helpful tips for successful post go-live stabilization.
Users may be frustrated and overly stressed and want resolution immediately. Issues immediately affecting care should be marked as critical and resolved first. Once the critical tickets are addressed you can work your way through the lower priority levels. Simultaneously, use a method of communication e-mail is typically easiest to keep your organization apprised of the status of your work. The more transparent you are to staff regarding things such as the number of tickets you have received, how many you have resolved, etc.
With a system such as Epic, for example, each user is given unique security access based on their role and the corresponding application training they completed. No matter how much work you did to ensure correct access was being assigned, once you are live, some end users will undoubtedly have been given incorrect security access. To mitigate these challenges, have plenty of at-the-elbow support available immediately following the go-live that can perform training checks to verify if the user completed training.
The most challenging security issues you will face is when a user has been given the correct security access based on the training they completed, but it unfortunately is not the access they need to perform their role because they took incorrect training.
You will have to work through some difficult conversations with their manager to identify what the correct training is and have the user attend training once again before they can get their correct access. To ease any tensions and be as efficient as possible, see if you can assign them a view-only access level that will allow them to perform some of their work until they can get into training again.
Training: While most of your time and energy is spent on getting users training before the conversion date, you will also need to be prepared to plan for training after you are live in the system. Ongoing Communication: One of the most important things you can do after a conversion is to keep both staff and managers updated. Most likely, managers will have been focused on just getting through the go-live and probably have not yet thought about what the conversion means for their practice in the long run.
As processes for training, security access, and command center help desk tickets change in the days and weeks following the conversion, it is important to keep managers updated on these changes.
Anytime a change is made it must be communicated to them. The earlier you can communicate and the more transparent you are will lead to the greatest point of stabilization in the new system.
The complexity of an EHR implementation often means post go-live planning is put on the backburner. However, if you have an understanding of these challenges you will encounter after you are live, you will be better equipped to guide your organization to system optimization. Sign up for our weekly 5 Cool Things in Healthcare newsletter.
Every Friday we give you five stories of innovation, disruption, and - you guessed it - coolness. Hayes' Healthcare Blog. The training team will need to know the critical training needs so they can get classes and certified trainers organized for users who completed incorrect training or need supplemental training as soon as possible.
Additionally, you should build a moderate training schedule for the first three weeks after the conversion that is available for users to register into prior to the go-live. This will help eliminate any time lost after go-live creating class schedules and reassure end users that they can receive additional training as needed.
Long-Term Training Post Go Live: Application training will need to be offered endlessly as new hires, rotating residents, interns, transfers and other staff will all need to be trained. To manage this training, it might make sense for your organization to create a set monthly training schedule.
To create a set schedule, first speak with practice managers, resident coordinators and others to get anticipated start dates and general monthly hiring times. It is likely that they already have a general year-long hiring plan.Or does that assessment depend solely on the relative number of positive and negative anecdotes after ERP go-live? If it is the latter, be prepared for a disappointed organization and a demoralized team, because even though getting an ERP system up and running successfully is a highly challenging task, expectations around how it should operate on day 1 are almost always unrealistic.
For instance, will part of your implementation plan be to a run ahead and bill as much as possible the week before ERP go-live b try to reduce work-in process inventories to the lowest practical levels and c shut down business operations for a three day weekend at ERP go-live?
In general, these are things that help the quality of an ERP implementation, simply by making the problem queue smaller, but think further about the financial ramifications of each. Item a artificially increases revenues in the last month of running the legacy system, and artificially decreases revenues in the ERP go-live period.
Item b reduces your working capital to unrealistic levels; when it returns to normal, will it be viewed as an increase in inventory investment caused by the new ERP system?
Without clear and proactive communication, item c can easily be misrepresented in the field, with cause and effect getting juxtaposed. Instead of it being said that a business stoppage was planned to ensure the quality of the ERP implementation, the story will be that the ERP implementation was so problematic that all business came to a halt for three days.
The fundamental problem with ERP performance expectations goes all the way back to the project approval process. The ROI justifications for obtaining investment funding are real, but not realistic on day 1, nor on day The fact is, there is almost nothing sexy about ERP on go-live day 1. But a solid implementation on day 1 becomes the foundation for the very real ROI that comes later.
If you can set that expectation, everyone will be more satisfied. Free white paper. Featured white papers. Sign up to our newsletter Sign up. Thank You!
Acceptance Criteria in Scrum: Explanation, Examples, and Template
Your first ERP newsletter should arrive in your inbox soon. These reasons could be the answer.I've been working with my project team to establish the criteria we'll use to determine if our ERP implementation has been successful. We would also be using this criteria in order to measure our implementation partner's performance and determine that the project is finished to our satisfaction. We have come up with a number of ideas surrounding training, reporting, stress tests, and performance and have defined some criteria in these areas.
I'm interested to know what kind of acceptance criteria other ERP project managers whether vendor, consultant, or customers have used in the past to measure the success of their projects, and how well they worked.
I would also be interested in any recommendations that could be made regarding the development and use of this sort of criteria. Have the executive team define success at that this high level and use this to guide the next wave of defining success measures. Work with business owners, SME's and functional consultants of each ERP feature team to create performance metrics that are linked to the business measurements of the processes they support. These are customarily your core business process metrics.
Of course, they signed off in the design stage saying the test case itself would be appropriate to verify their needs. At the phase gate they sign off that the results are accurate and adequate to satisfy the business.
Specific to vendor performance: I use scores on a set of targeted vendor questions as a motivator and success criteria. The biggest challenges for us may be to ensure that we can address the management goals for implementing the ERP. In scenario one, if the ERP is to provide the automation, transaction processing and operations reporting, then we would target the performance measures relating to those related factors.
However, in scenario two if the ERP is implemented to achieve supply chain excellence, then the key performance indicators shall be focusing on the return on assets ROAlower inventory turns, lower cash-to-cash cycles, increase in throughput, reduce cycle and lead times, and so on.
Although ERP may not directly affect some of the performance, but we have to clearly differentiate them. With the two scenarios above, it can be possible that the IT people use GoLive and automation as the measurement of success. Unfortunately, the management may want the ERP to be tied to the business performance. This has a lot to do with the contract for the implementation. Yan-Goh Ng, Ph. Liverpool www. Good Luck. One good way to go is downwards from your traceablity matrix.
So you start with your strategic drivers e. What you have below are the much harder qualitative measures - absolutely worth doing, as they differentiate an excellent implementation that provides quick ROI, from a merely good one that produces the goods agreed, with the usual attending hidden frictional costs.
After my previous reply, I considered that one technique you might like to use is EVA economic value add for each activity, module, or process that has been impacted.
EVA is a whole field in itself Right now, my question focuses more around 6. We are working away with repect to internal conditions of satisfaction as well, just not having as much difficulty conceptualizing these for some reason. You mention "targeted vendor questions". Could you please possibly give me some examples of these? Measuring consultant perform is a necessity. However, payments tied to deliverables is a very tough sell especially on a project that is bigger than a bread box.
It is definitely worth exploring, but on medium to larger projects I would be interested in how you get consultants to buy into the "progress payment" arrangement. They will have many reasons why they cannot do it and most are valid.