You’d hope that the closing phases of a project always might be straightforward, but in reality they’re far from it. The end of a project brings together all dependencies, some of which might not have been worked on in months, in order to complete. In this post we’ll explore how we can create timing plans that account for the complexities of the closing phases of a project.
Remember the hidden phase
Planning out the final phases of a live project can appear to be some of the most straightforward – finish it off and just get it live! It can also seem like one of the most unproductive; after the productivity and excitement of new ideas formed in UX, creative being birthed in design, the technical development and functionality being worked through in development, it’s easy to think of a project as being pretty much complete.
However, the final stages of a project can be the most complex as dependencies are fully realised and the importance of having a proper plan in place to make sure everything can be deployed live and the project closed properly is important.
Build in the closing dependencies early
The kind of things that can get missed off of a project in the closing phases are usually the things that are dependent on other things so can’t be auctioned earlier. Content, SEO, servers, hosting, database migration, DNS configuration and third party integrations all need to be built into the timeline and the specific dependencies defined so that there are no delays at the final phase of the project.
Finishing well means QA’ing properly
Part of finishing well is ensuring that quality control or assurance (QA) has had a chance to properly validate the site. Just because there’s no clear deliverables from a client’s perspective, doesn’t mean it doesn’t take any time.
In order to QA properly, make sure you build into your project plan the development of test cases. The test cases will be used later to validate whether or not your project has passed. It’s best to create these test cases early on so they can be agreed with the client what constitutes a pass or fail.
Remember to build in external and internal approvals
When a project has passed QA, there will be a need to get final approval of the project’s deliverables. It’s always useful if you can then build in time for an internal approval cycle so that you can get the green light from all internal departments that the project is approved as complete.
There can also be snags in approvals; if the appropriate stakeholders haven’t signed off a project at the right points earlier in the project, you can find the whole project delayed at the final hurdle. To mitigate against this, build in the planning and implementation of these early on.
The external client approval can often be the most lengthy as usually a larger pool of stakeholders have to be included who feel bad if they don’t try and change something; ensure not only extra time for approvals is included, but additional time for amend cycles too. Try building in 3 x amend and approval cycles to give adequate time for all stakeholders to provide input.
Define your deployment strategy
Going live is rarely a simple switch. Remember to fully define the deployment strategy and define the steps required for deployment from the local environment, through staging, UAT, production and finally the steps to go live. Ensure you build in adequate time to migrate databases, make DNS switches and finally for caches to clear or load. As much as possible forward plan the deployment so that there aren’t unforeseen delays at the end of the project when everything keeps trying to load the project and can’t understand why it hasn’t updated yet.
What do you think?
What do you think we’re missing? What else is there to defining the idea that should PM’s be thinking about when creating timing plans and project plans? We’d love to hear if you’ve got any more tips – why not share them using the comments below?
10 top tips for creating timing and project plans
This 10 top tips blog series has been written as a guide for estimating and approaching creating cost estimates in the midst of it all. In this series of posts we’re looking at the following:
- An introduction to creating timing plans
- Define your workflow
- Establish your planning horizon
- Break it down
- Ask, don’t guess
- Question when questioning
- Allow time for amends
- Plan for it not going to plan
- Finish well
- Post project review & optimise
- Checkpoint charlie
- A summary to creating timing plans