Just recently I completed a major project – the third phase of a project that had extended over nearly four years all-told. The project involved implementing a data warehouse with a global scope, involving over 30 different countries and in excess of 50 million customer records.
I think it is fair to say the project was a major success. It consolidated several systems the company had been using, dramatically lowered costs, increased the business intelligence capabilities of the organization and was extremely well-received by the users. In all my years of doing project work, I have rarely seen a project achieve such positive results. This may sound like personal horn-blowing, but if you spoke to the key stakeholders, I think you would find that they would generally agree.
It is not that the project went completely smoothly and with no hiccups. The last phase in particular (converting an old mainframe-based system) was a tough one and it went several months longer than the original plan. There are many reasons for this, the primary one being underestimating the effort involved in converting some of the very technical and complex functions. But in the end the project delivered very positive business value. And delivering business value is what a project should be all about.
There were many lessons learned on this project. I’d like to focus on one aspect here that could be of help to other PMs. This is how to effectively close a project without leaving many loose ends.
In my experience, projects do not often close in a clean manner, with everything wrapped up and delivered and nothing left to tidy up. Often the projects seem to just go on forever in a sort of maintenance mode, with new issues arising week after week. On the other hand, sometimes the project is closed abruptly with software full of bugs and the users feeling that the product is incomplete.
There may be many ways to manage this. The closing process in the PMBOK is straightforward – you complete all the work assignments, release the resources, close any contracts, write up Lessons Learned and have a party. It seldom works out so cleanly.
There are two primary ways to ensure that all loose ends are tied up. They can also be used to compliment each other.
First, at the end of the project all outstanding issues are either closed or they are converted into open requests or tickets in the normal maintenance system.
The other way to manage this is to build a warranty period into the project, where some project resources are kept at least part-time to resolve any issues or bugs that arise. The project is formally close before the start of the warranty period and the warranty work is done under the auspices of the organizations normal maintenance process.
The warranty makes most sense when the product of the project is delivered to an outside organization, but it also can be used within an enterprise, especially when the product is delivered to another department or group.
But the key thing is – don’t leave loose ends! They will come back to haunt you.
I have made my best efforts to apply these principles to my recent projects. The effect has not been perfect, but it has had a positive impact.
============================================
As the title of this post implies, the end of my most recent project has also meant the opening of a new chapter in my career and life. I have left the organization where I had spent over 20 years. There were many reasons for my departure, but in essence the company and I both felt that it was time to part. They were and continue to be very gracious and generous.. I greatly appreciate their good will.
I am taking some time now to assess my future and to look over my options. I will be working to establish myself as an independent consultant, one who can assist in the management of any IT project and make those projects work better.
To see more about me and my background and competencies, see my Linkedin profile: http://www.linkedin.com/pub/8/648/258.
I think it is fair to say the project was a major success. It consolidated several systems the company had been using, dramatically lowered costs, increased the business intelligence capabilities of the organization and was extremely well-received by the users. In all my years of doing project work, I have rarely seen a project achieve such positive results. This may sound like personal horn-blowing, but if you spoke to the key stakeholders, I think you would find that they would generally agree.
It is not that the project went completely smoothly and with no hiccups. The last phase in particular (converting an old mainframe-based system) was a tough one and it went several months longer than the original plan. There are many reasons for this, the primary one being underestimating the effort involved in converting some of the very technical and complex functions. But in the end the project delivered very positive business value. And delivering business value is what a project should be all about.
There were many lessons learned on this project. I’d like to focus on one aspect here that could be of help to other PMs. This is how to effectively close a project without leaving many loose ends.
In my experience, projects do not often close in a clean manner, with everything wrapped up and delivered and nothing left to tidy up. Often the projects seem to just go on forever in a sort of maintenance mode, with new issues arising week after week. On the other hand, sometimes the project is closed abruptly with software full of bugs and the users feeling that the product is incomplete.
There may be many ways to manage this. The closing process in the PMBOK is straightforward – you complete all the work assignments, release the resources, close any contracts, write up Lessons Learned and have a party. It seldom works out so cleanly.
There are two primary ways to ensure that all loose ends are tied up. They can also be used to compliment each other.
First, at the end of the project all outstanding issues are either closed or they are converted into open requests or tickets in the normal maintenance system.
The other way to manage this is to build a warranty period into the project, where some project resources are kept at least part-time to resolve any issues or bugs that arise. The project is formally close before the start of the warranty period and the warranty work is done under the auspices of the organizations normal maintenance process.
The warranty makes most sense when the product of the project is delivered to an outside organization, but it also can be used within an enterprise, especially when the product is delivered to another department or group.
But the key thing is – don’t leave loose ends! They will come back to haunt you.
I have made my best efforts to apply these principles to my recent projects. The effect has not been perfect, but it has had a positive impact.
============================================
As the title of this post implies, the end of my most recent project has also meant the opening of a new chapter in my career and life. I have left the organization where I had spent over 20 years. There were many reasons for my departure, but in essence the company and I both felt that it was time to part. They were and continue to be very gracious and generous.. I greatly appreciate their good will.
I am taking some time now to assess my future and to look over my options. I will be working to establish myself as an independent consultant, one who can assist in the management of any IT project and make those projects work better.
To see more about me and my background and competencies, see my Linkedin profile: http://www.linkedin.com/pub/8/648/258.
