Posted on May 29, 2018 · Posted in Project Management, Task Management, Time Management

This is a guest post by Reshmi Sujesh. The ideas reflected here are her own.

The days leading to Project Launch are always hectic. As a Project manager, you need to review the checklist to ensure all the items are closed and there are no gaps. The items on the checklist could range from: Are there any pending approvals on the change request? Has the project launch timelines communicated to the Business stakeholders? Are the Launch orchestration plan and the shift roster finalized? Are the post-implementation test plans locked and the list can go on and on.

Each activity on the checklist is important for the smooth and successful launch of your project and they should ideally be planned well in order to be executed successfully. How about the list of open defects which are not being fixed in the current launch?  As a Project Manager it is important you understand the list of open defects and ask the right questions-What is the reason these defects are still open?  How many are high severity and How many defects are open from System Integration testing and User acceptance testing? What is the impact to the current project launch due to these open defects?  Has the team analyzed these? Is there any temporary workaround till this is fixed? You see there are many questions which need to be answered.

Following these simple steps would help you, the Project Manager and the team to effectively manage open defects.


Identify the list of open defects from your project during the project lifecycle and understand why this has not been fixed. It could be due to the various reason for e.g.: Out of scope for the project, existing production behavior, Low severity issue not critical for Business functionality, Team bandwidth issues to fix in the current project launch etc.

Open defects which are not planned to be fixed in the current project launch window need to be classified or updated under one category in the defect management tool. For ease of understanding let’s categorize such open defects under  ‘Deferred’ status to signify they would not be fixed in the current immediate project launch but are being deferred to be fixed in the next upcoming project release.

When a defect is in ‘Deferred’ status, the impact analysis and the Business decision to defer the defect need to be captured. All documents and artifacts need to be uploaded to the Defect management tool. It is important to document the person who took the decision to Defer. Was it the Product Owner, Development Lead or the Business stakeholder?

Business and IT stakeholders need to be aligned before moving defect to ‘Deferred’ status.


Once the deferred defects are identified they need to be classified to have better control.

  • Software/Code deployed to Production as Known Issue with a workaround –

Deferred defect needs to be classified in this category if the code causing the defect is identified as a known issue and will be deployed in production with a workaround.  Workarounds would help to reduce the Business impact post the project launch. Project Stakeholders need to be intimated on the workaround. E.g. of workaround: Existing production issue to be fixed in the next launch window. Please update the records manually from the Green UX Screen.

  • Software/Code deployed to Production as Known Issue with no workaround – Some defects may be related to requirements which are out of scope and may need a detailed analysis hence there would be no workaround for such defects for the current immediate project launch. They would need to be fixed in the upcoming launch window. Again a clear alignment needs to be sought with the project stakeholders to avoid any confusions.


A workaround is basically temporary solution until the permanent fixes are available for project stakeholders. Whatever may be the severity/priority of the deferred defects there has to be a clear categorization of workarounds.  Temporary workarounds need to be clearly documented. If there are no workarounds it may need to be prioritized to get into the project backlog for prioritization for the upcoming future project launch. Workarounds could vary from monitoring the server behavior to asking the user to use an alternative screen to perform the functionality. The workaround documentation needs to available either in the Project SharePoint or in the defect management tool or any other Knowledge sharing tool. The location where the workarounds are documented needs to be cascaded to the Project stakeholders.


Operational readiness team (ORT) are the support teams who ensure the operations and Business continuity is maintained. As the project manager, it is your responsibility to let the IT operations team know of such ‘Deferred’ defects so they can understand the impact these might cause to the project launch and be prepared.

Ensure to provide them a detailed walkthrough on the list of deferred defects, documentation, business alignment, workarounds etc. Till the permanent fixes are available they need to support the project stakeholders with the temporary fixes. A consensus needs to arrive between the project teams and the ORT Team. Deferred defects which are identified as known issues would generally fall within the ORT team’s backlogs and Defects which are the change in requirements would fall within the Project team’s backlogs.

Before the project launch, a signoff from ORT teams is highly recommended to ensure that a proper knowledge transfer has been provided and there are no further gaps before the project launch.

Project Manager can plan to follow the above practice of identity, classify, document and consensus during the project lifecycle to ensure the deferred defects are managed properly.

Reshmi is an IT Program Manager with 15+ years of experience. She is certified in PMP, CSM, DevOps, SaFeAgile, COBIT, ITIL and ISTQB. She has been published on, and several of the India print media for children.

Reach out to Reshmi at: or connect with her on Linkedin.

About the Author