It’s true, some project management professionals don’t look forward to the day their project moves from “in progress” to “complete.” While most project wrap-up activities bring with them a sense of relief and accomplishment, there are aspects of a project’s completion that can sometimes make the event less than festive.
What is it about completing a project that could possibly put a damper on the occasion? We compiled a short list of what periodically bugs PMP®s about finishing a project.
Just when you think the project is finished, a whole new round of requests start to trickle in. When stakeholders get pushback on requests mid-project, they’re likely to file them away for future prodding. Once the project is complete, those wants and needs rise to the surface again. Sometimes the leadership team has new market data and wants to refine aspects of the original project. In other instances, stakeholders were just waiting for the earlier project to wrap up because they assumed your team would now have lots of free time to do other things (they don’t). Very often, it seems like you can barely get one project done before a companion or expansion project comes along. This leaves little time to celebrate the team’s accomplishments and that’s unfortunate, because looking back on successes is a big help when the pressure is high and the team needs a boost.
Your project was completed according to the scope everyone agreed upon, but now users are claiming they thought things would be different. The communication was excellent, the achievables turned out according to the plan, your stakeholders seemed pleased all along, and mid-project user surveys didn’t point to any potential disconnects. So how did this happen? You could be dealing with a complainer extraordinaire (they do exist, unfortunately), but it’s more likely the user is truly surprised by the project’s outcome. Simply put, some people have a very difficult time envisioning how the final implementation of the project—or sometimes just parts of it—will actually look and/or function in the real world. Your team should always strive to provide as clear and complete a picture as possible of how the project’s final outcome will impact workflows, operations, processes, physical footprints, costs, revenues, and everything else, of course. But once in a while, there’s bound to be a question no user thought to ask, a concern that didn’t arise until they saw the project in action, that will assuredly make its way back to the project team.
You were diligent about following up on everything, but somehow a punch list item pops up months after the project is closed out. It’s an old story, isn’t it? Somewhere lurking in that project was a piece of equipment with a faulty switch or a chunk of software with a glitch. Even after diligent and vigorous testing was conducted, nothing was found when the project was originally closed out, but here it is—bringing that old project back to life, at least for a little while. Any number of factors can contribute to this scenario, many of which are difficult to predict. User error is responsible for some portion of punch list items that come in long after the project was wrapped up, either because users didn’t take the time to let someone know an item was outstanding during the closeout phase or because they didn’t notice that something still needed to be done. Software updates may also be an occasional culprit when it comes to punch lists, both on general equipment receiving off-the-shelf patch releases as well as customized equipment that’s supported by the manufacturer directly.
Project management training tips provided by PMAlliance Inc.
