The Sixth and Final Step – Identifying Lessons Learned and Closing the Project

We’ve reached the end of our series about the software selection process. If you haven’t been following along, you might want to circle back to the beginning. In this series we have talked about the contracts and about initiating the project, identifying requirements and choosing vendors, sourcing the request for proposal (RFP) document and holding software demonstrations. Last but not least, we talked about choosing your vendor and negotiating and awarding the contract.

As we head toward the finish line, we’re going to  talk about a couple of important steps that must be done before you can close the project.

Maybe you thought that once the you choose a solution the software selection team could be disbanded and that was that. Yes, you could do that, but with any project, there are a few things you need to do before closing the book and moving on. Trust me, these few tasks are invaluable, so stick with me.

Lessons Learned

First of all, it’s so important to take the time to collectively look back and talk about what went on in the project — so everybody can learn from the experience. Some people call this step the post-mortem analysis, while others use a less macabre term and  call it a retrospective analysis. No matter what you call it,  it’s a critical step.

The “lessons learned” meeting  is one of the most important sub products of a project. At this meeting, the project team and key stakeholders gather to identify and talk about things that went well– and things that didn’t go so well in the project.

The key here is to keep a positive attitude and only provide constructive feedback. By identifying the things that went well, the participants can use that information when building a timeline and process for future projects. Why re-invent the wheel?

In contrast, by recognizing the things that didn’t go so well, the team can pinpoint causes and avoid repeating those mistakes in future projects. Keeping good notes, and encouraging the team to do the same, throughout the project, makes this “lessons learned” meeting less painful and more productive.

Project Close Meeting

Conducting a project close meeting is something we’ve found very valuable. The idea is for the stakeholders, the leadership team and the software selection team to meet and talk about the lessons learned, review and approve any final deliverables of the project and address any questions about the selection of the software.

Project Close Report

It’s also a good practice to produce a final project close report to document the lessons learned, the selection process that was followed, the criteria that were used, the vendors that were evaluated and the scores given to each vendor.

We strongly recommend creating a close report because it will be incredibly useful in the future when auditors or any other parties ask why the solution was chosen and how the company made that decision. Quite often the key participants in the selection of a software are no longer with the company or don’t remember the details when the questions come up.

Deliverables and References

Before the project manager moves on to the next assignment, he or she should put together the project documentation and archive it for future reference.

There you have it, a quick tour through the methodology and best practices to use when choosing  the next software solution for your company.  We hope you have enjoyed it. At Roghnu we have mastered this methodology, we can assist at any step of the process so you can select the best software for your needs and budget. Contact us.

PHP Code Snippets Powered By : XYZScripts.com