Time and again we see projects with a trail of issues that, if not dealt with, build up into this "issues bag," as I call it. The further you get into the project, the bigger and heavier the bag becomes--making it harder to control.
Carrying around these unsolved issues creates several risks.
1. Schedule risks: The project isn't completed on time because the issues left unresolved have caused delays in project activities or phases.
2. Budget risks: An unresolved issue creates a requirement to redo the work. If this work isn't done within the allocated timeframe--when it's still possible to refine requirements and while keeping the changes within the scope of the project--any changes would require additional funding.
3. Staff risks: The issue, if not dealt with by the project team, may be passed on to the baseline/production support team. This would impact other departments--and their time and money.
So how can you make sure the issues bag is empty at the end of the project? Here's what I suggest:
• Keep track of the issues.
• Maintain a list of the risks involved with these issues.
• Keep a list of assumptions about what? and validate them.
• Maintain a list of all changes executed during the project.
• Perform quality assurance and close-out any outstanding quality? issues.
• Ensure appropriate user-acceptance testing phases and garner signoff on the testing.
• Pay attention to the organizational and business environment your project is impacting and any issues that arise.
• Notify systems support teams of any impacts that may be caused by your project, directly or indirectly.
Carrying around these unsolved issues creates several risks.
1. Schedule risks: The project isn't completed on time because the issues left unresolved have caused delays in project activities or phases.
2. Budget risks: An unresolved issue creates a requirement to redo the work. If this work isn't done within the allocated timeframe--when it's still possible to refine requirements and while keeping the changes within the scope of the project--any changes would require additional funding.
3. Staff risks: The issue, if not dealt with by the project team, may be passed on to the baseline/production support team. This would impact other departments--and their time and money.
So how can you make sure the issues bag is empty at the end of the project? Here's what I suggest:
• Keep track of the issues.
• Maintain a list of the risks involved with these issues.
• Keep a list of assumptions about what? and validate them.
• Maintain a list of all changes executed during the project.
• Perform quality assurance and close-out any outstanding quality? issues.
• Ensure appropriate user-acceptance testing phases and garner signoff on the testing.
• Pay attention to the organizational and business environment your project is impacting and any issues that arise.
• Notify systems support teams of any impacts that may be caused by your project, directly or indirectly.
Excellent post. It seems too many people simply want to always gloss over the "issues" list, and draw attention to the project. In reality, those who deal with the issues up front when they are known are the true leaders.