Hi,
We are trying to reach an acceptable consensus to the question - when can a software project be deemed as closed? The following questions are being raised by the impacted stakeholders and I would like some advise on which is the best or recommended alternative.
1. When is a project considered as ‘Closed’?
(Is it decided by the Project Manager, the user, the Test Team, the Production Support team or a consensus of all the above? Or instead of this can we have conditions like 'There are no open Sev 1 and Sev 2 defects / issues and the user agrees to let the project close with open Sev 3 and 4 defects')
2. What if there are any defects that need to be handled at a later date but the user agrees that the project can be closed? Who monitors / tracks / handles such “project issues”?Who would decide whether such a project can be closed?
(Is the Project Manager still expected to monitor / track such "open" issues once the project is closed to ensure that these open issues are closed and do not drop from sight? What would be recommended?)
3.Who handles the defects found in Warranty? Tracked by whom?
(If there is a warranty period of around 1 month after go-live, can the defects found in the warranty period be addressed by the production support team and monitored by the PM?)
4. What is the best solution if the user agrees that a project can close with open issues but the Production Support team refuses to accept the project closure due to many open defects even if they are of low severity?
Saving Changes...
Sort By:
Rakesh TrivediSenior Project Manager| IT CompanyIndore, Mp, India
Good Question, Let me try to reply one by one of mentioned points -
1. There are defined steps in order to close the project but global accepted standards states that once Customer provides the Sign off on your project after production deployment, project can be deemed as closed in the eyes of customer but for Internal Stakeholders still some process related things need to be completed for actually closing for QA or Senior Mgmt of your company ( issues like any NCR is still pending, CMM related activities closed, resources released, Close up party over :-) etc.)
2. The scenarios depicted in point # 2 is really good and have seen many times it occurring , I would recommend that any defect status are closed in consultation with Clients/customer/business users. Generally no project can be closed with major or critical issues ( Sev 1-2-3 ) and may happen to have Sev 4 may be closed and be taken during Warranty support or Post production support which you have defined already in point 3.
3. The assumption made is correct all the Warranty support related matters are taken by PM with support or 1-2 Tech team resources.
4. I do not agrees with assumption itself in first place since Production support team comes into existence only after project closure so they will not have any say in project closure activities. Anyway, even if project closure is done with major defects open with concurrences of Business then also next support team will take over all those defects and work towards foxing/closing them in agreed timeframe.
I have put all the above points based on practical experiences, hope this helps.
Saving Changes...
Anonymous
Hi, Thank you so much. The replies definitely help.
Hi Anon:
You have two processes to review for closure: Project Management and Systems Development Lifecycle.
Your PM, Sponsor and Technical Lead are integral in this process along with the vendor /account manager and PM. Also, your operations manager and key staff should also be involved early on so discussion for a smooth transition and SLAs can be developed for the business.
You don't mention is this is internal development or contract however; ultimately your customer and key stakeholders will provide approval for user acceptance of the final solution. Your PM./Contract Manager should be managing the contract and deliverable to identify the vendor has meet all contract requirements and complete contract deliverables to the customers satisfaction.You will have project managerment closure and contract closure.
It sounds like you have a problem with agreement from IT and the business owner of the final solution. The final solution will either be supported by IT with a maintenance and support contractor or managed by the business with support from IT and maintenance and support. This should have been determined early on in the project.
As far as the PM is concerned, once the project is over, lessons learned is completed, contract is closed and resources have rolled off the project the PM is done. Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
By the sounds of it, you don't have any structured processes within the company to follow already. That means you are at liberty to create your own, using the advice from the other people who have commented, and your best judgment. As to the warranty period, we don't sign off a project until the system has been in use for 30 days. That gives us a while to work out any snagging, check the users are happy and fix anything major that was overlooked. Go live + 30 days is a useful rule of thumb.
I'd also add that the PM needs to manage his or her way out of the project, and that means being very clear with people about when it is actually handed over into production. Otherwise you will be picking up support queries for a long time. Make sure the users know who to turn to with questions, because once it is signed off it's no longer your responsibility to fix things or respond to queries. You'll be too busy on your next project... Saving Changes...
This should be decided at he very beginning of the project under success criteria and agreed by the sponor and area responsible for the ongoing support and documented in your Project Management Plan.
2. What if there are any defects that need to be handled at a later date but the user agrees that the project can be closed? Who monitors / tracks / handles such “project issues”?Who would decide whether such a project can be closed?
(Is the Project Manager still expected to monitor / track such "open" issues once the project is closed to ensure that these open issues are closed and do not drop from sight? What would be recommended?)
Again once the agreed success criteria have been met then all outstanding issues are handed over to the supporting business areas to be handled as would any normal defect tracking.
3.Who handles the defects found in Warranty? Tracked by whom?
(If there is a warranty period of around 1 month after go-live, can the defects found in the warranty period be addressed by the production support team and monitored by the PM?)
All new issues are handled as would any normal defect tracking. Once the project is closed the PM has no authority over the deliverables.
4. What is the best solution if the user agrees that a project can close with open issues but the Production Support team refuses to accept the project closure due to many open defects even if they are of low severity?
Again best to agree this up front and then the Production Support team have already agreed to take on the outstanding defects.
I include this section in my project management plans.
11 Project Success Criteria
Outline the criteria the project has to meet in order to be seen as successful, these can be tailored for each project. The success criteria provide a basis for decision making throughout the project, they must be measurable.
Questions for the sponsor to complete this project would be;
What does success look like?
How will you know the project is complete?
How will both of these be measured?
What would be considered a good vs a bad job by the project
11.1 Criteria 1 – Scope
E.g. delivering 90% of scope or list the scope items that are deemed as mandatory
[Insert comments]
11.2 Criteria 2 – Quality
The system does not have any critical bugs at “go live”, has < 100 minor bugs etc
Staff/member satisfaction survey improvement of x%
Pass regulator audit
Less an x number of significant complaints
No downtime in system cut over
Sign off by external/internal auditors
Transaction throughput or performance
Zero OH&S incidents
Less than x% in exceptions handling from conversion or new process
[Insert comments]
11.3 Criteria 2 – Time
within x months of the expected delivery date
[Insert comments]
11.4 Criteria 2 - Cost
E.g. delivering 90% of scope or list the scope items that are deemed as mandatory within 10%+- budget
[Insert comments]
Saving Changes...
Anonymous
Hi,
Thank you for your advice. The feedback recieved really helps. Saving Changes...
