In my limited time as an assistant project manager, I have quickly learned the importance of taking the proper steps to make sure a project is closed properly. Unfortunately, this isn’t something that my office is always good at – and I think this is pretty common problem. When it gets to the end of the project process everyone is either excited or exhausted and so ready to be done with the project that little attention is paid after the project is handed off. Ideally, the hand off of the final product shouldn’t be the last step for a project. Newsignature.com outlines the six most important reasons for following a proper project closure process (listed below).
- Confirmation of Objectives Being Met
- Sense of Closure
- Improving Future Engagements
- Capturing Knowledge
- Tying up Loose Ends
- Rewarding the Team
These are all very important reasons to pay attention to this final step in the project cycle. In particular, I think points 1, 3 & 4 from the list above are the most important and are the reasons that I place such value on this step in my daily work. Once a project is finished and handed off to the client, our team generally has a sense of closure and it’s pretty clear if the objectives are met – but that is something to make sure of. We are notoriously bad at maintaining our archives, so items 3 & 4 from the New Signature list are most important to me. We need to make sure that everything the team has worked on is in one central location, organized and clearly laid out so that anyone not familiar with the project could come back to the folders and make a change if necessary. This also helps in having organized files for future reference on similar projects and allows the team to take an extra minute and reflect on the project, making sure that any lessons learned are communicated so that similar mistakes aren’t made in the future.
Wether you’re a project manager or a team member, it will be helpful to remember these six key parts of the project closure process to ensure that all projects you work on end in the best, most productive way possible.
The Project Closure Process and Why It's Important
By no means am I an expert in either Agile or Waterfall project management, but I’ve studied them and I’ve found that in my currently position we implement a blend of the two styles. In general, I much prefer Waterfall because it allows for more structure and insurance that each piece is finished, this is a somewhat unpopular opinion with the modern field of project management that is trying to bring Agile to the forefront.
Our project situation makes it almost impossible to use a traditional waterfall approach, we have student workers who typically work at most 20 hours a week, and our projects are generally proposed, planned and completed within a semester. This creates a rushed timeframe that doesn’t allow for an extensive planning phase and results in a lot of changes to scope as the project is already being worked on. Because of this situation we try to implement an Agile approach to projects but even that doesn’t always work because of our limited project team and the workers not being around all day. As a result, within a project, some things might be planned incrementally with a Waterfall technique while other parts of the project are implemented and created simultaneously like Agile.
This combination of techniques is a result of necessity, but creates confusion and duplicated work from time to time. While adapting and pivoting is always going to be required on some projects, I prefer to approach projects from the Waterfall perspective. I like to be able to put more time and detail into planing the project and then making sure each segment of the project is completed fully before moving on to the next stage. At the end of the day you have to be able to use whatever approach fits the project and will allow the project to be completed in the given timeframe, meeting the given requirements.
Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?
The variety and number of project management software and applications available today is quite frankly overwhelming. There are hundreds of applications that are all slightly different, and supposedly are all meant to do the same thing. In my short time in the field, I’ve only been exposed to a select few but I’ve learned a lot from that exposure. The single most important things that I’ve learned is that at the end of the day, your preferences probably don’t matter if they don’t align with the program your company expects you to use.
At Ball State, pretty much every project must be managed in Workfront, formerly AtTask. Like I said, almost all of these project management applications are pretty much the same, but that doesn’t mean that some are better than others. Workfront is very clunky, light on features, and just not very user friendly. I compare it to a few other systems I’ve used like Basecamp or Trello and it just falls short, especially in the area of collaboration. The feel of Workfront takes me back to 2007 Microsoft Project, outdated and confusing. Even the newest version of Project is a step up from Workfront in my opinion.
I do have to say that I think much of my distaste for Workfront may be because – as a “millennial” – I expect everything to be constantly updated and cutting edge, which the program simply isn’t. Aside from the physical design the deliberate lack of collaboration due to administrative oversight makes the system less responsive and effective than Trello or Basecamp. At first I was tempted to just use a program I preferred in addition to Workfront, but it just became too much of a hassle. That’s when I learned that sometimes you just have to use the tools you have to get the job done, even if there are better tools out there.