Closing a project is one of the most important stages of the digital project management process. In web terms, this is the stage where you’re about to hand over the reins of the client’s long-anticipated new online presence. By using tried and tested processes and then tailoring them to PRINCE2 methodologies, here we show you just one stage of a project lifecycle and how thorough the closing stage of a project needs to be to ensure quality.
This is the time (in the short term at least) when the most eyes will be on it. Followers, skeptics and competitors alike will be needling through its features with a fine-toothed comb in the hope that they unearth at least some sort of fault that shows, just like themselves, you’re only human.
Project Managers have 5 main activities to consider when closing a project:
- Prepare Planned Closure
- Prepare Premature Closure
- Hand Over Products
- Evaluate the Project
- Recommend Project Closure
Assuming everything runs smoothly – which it should – then there shouldn’t be a need for number 2. So let’s say then that there are 4 main activities for a Project Manager to consider when closing a successful project.
Here’s some transparency into the daily routine of a Project Manager as I give you a little peek into how we close out projects.
1. Preparing Planned Closure
The first thing to consider when preparing to close a web project is that the site is actually finished and working as it should be. Before the client gets to view the final website, we run some internal Quality Assurance (QA) tests to make sure that the website is fit for purpose.
Cross browser testing
A website isn’t built for just one browser, and one browser will interpret code slightly differently to another browser. Since there are so many browsers out there these days, we tend to stick with the majority of internet users and ensure our websites render perfectly in the following browsers (unless the client requests otherwise):
– Internet Explorer (9 and above)
– Firefox (10 and above)
– Google Chrome
We use a tool called BrowserStack to test cross-browser. It lets you select between browsers and also allows you to test in numerous mobile devices and operating systems so also use it for responsive testing.
If the website is responsive, we think responsively from the get go. We ensure that the design concepts give mobile direction so that a) the client has an idea what the site will look like in mobile and tablet, and b) the developer has something to work towards once they begin work.
Check the contact forms work
The contact form is one of the most important parts to any website. Unless the site is an eCommerce store, the chances are, that without functioning contact forms, the website isn’t going to perform very well. Be thorough here by not only sending a test enquiry through the form but also replying to the email. Make sure that all the agreed recipients are receiving the emails before marking this section as complete.
Run test transactions
If the store is an eCommerce store, then its sole purpose is to drive sales – electronic, automated sales preferably. Test the payment gateways and make test transactions to make sure that notifications of purchase are sent, invoices are received and payment is taken.
2. Hand Over Products
The second thing to consider when closing a project is collecting and handing over the finished products that are created throughout the length of the project. When handing over products, there are a number of things to consider, and spending that little bit longer to create a few freebie products could help you gain a little extra credit.
Who receives the products?
A product is something that is created during the project. So in the web world, this would be things like brand guidelines, screencast tutorials etc. Ensure that there is a designated area or client folder in order to store these products once they are made. From a Project Management point of view, in each product description not only should it describe what the product is and give direction on how to build it, but it should be clear about who is to receive these products and ensure that all the correct recipients get them upon site launch. Efficient communication when closing a project is key.
One thing that clients expect these days is that their website be easily editable without the need to hire developers. So ensuring that the site is built using a Content Management System (CMS) these days is a huge selling point. However, most CMS will only allow you to edit imagery and blog content but are limited when it comes to editing things like the header, footer, home page content etc.
At Tone we make our client’s lives easier and offer them one of the options below:
- A CMS manual – A bespoke instruction manual.
- A screencast tutorial – A series of videos with commentary (we recommend using Screenr – it’s a great platform for creating these).
- Personal training – 1-2-1 training in-person.
Obviously when working with international clients, it’s difficult to offer personal training. And the other downside to option 3 is that once trained, the client has nothing physical to refer back to as they would with the manual and screencast.
However, it’s ultimately down to the client which option they prefer and it all helps in improving quality.
In order for the client to bring the rest of their assets in line with their website, they need to know what fonts, font sizes, colours etc. the website is using. Including things like vector based logos in this document is also great for the client.
With a set of brand guidelines to follow, the client can then go away and make business cards, letter heads, email signatures, van signage – all in keeping with the website thus ensuring brand consistency throughout their business.
If this seems like too much trouble, there’s a great tool that does it for you called StylifyMe. You just type in the URL of the website (must be a live website) and they do the rest.
3. Evaluate the project
You’d never begin a project without first planning it; the same goes for closing a project and evaluating the overall result. If you close a project without first evaluating it, you enter the realm of dealing with dissatisfied customers after site launch.
Compare the initial spec. to the finalised one
As with any project, there’s always going to be a time when you need to manage change. By change I mean anything that needs to deviate from the original specification. The best way to manage change is by ensuring that team members and team managers raise issues to the Project Manager as soon as they arise (or before they arise – think risk assessment) so that the Project Manager can make recommendations for a suitable fallback.
You’ll often find that as long as issues are communicated efficiently with the client, their acceptance criteria can be pretty flexible and waiver somewhat from their original expectations as they understand that some things may just not work and we need to try an alternative. The worst thing you could do is make the changes without notifying the client and then running the risk of the client saying ‘this is not what I paid for’.
Good, solid, day-to-day communication with both client and internal teams is key to successful project completion.
Once a request for change has been made and approved, the Project Manager should update the specification and Proposal to include this change as, more often than not, this would affect timescales and costs. Once the project is complete, comparing the original proposed project deliverables to the actual project deliverables is great for the client to see transparency and honesty. And, providing that all the changes in the spec. have been communicated to the client at some point during the project lifecycle, you’ll find that although you’re not delivering the exact outcome that you promised, the client will still be more than happy to sign it off as complete.
The last thing you need at this stage is to enter a whole new round of amends – schedules and profits will both begin to take huge hits if that happens.
Create lessons reports and add to Lessons Log
Most web agencies will have some form of Lessons Log. A lessons log is just that: a log of lessons. Whenever change happens, it means that something didn’t quite go to plan, and when something doesn’t quite go to plan, there’s always a lesson to be learned.
Now, if the lessons were learned from previous experience (before the project even began), then you’d be able to foresee some of the risks involved and put secondary fallback plans into operation before the risk became an issue.
Review ‘approved’ changes
A lessons report entry into the Lessons Log doesn’t necessarily mean a change happened. A lesson could be logged from a near miss or potential pitfall. So it’s important to review the changes that actually did happen and work out if there was something you could have done better.
Reviewing the changes post-project is the best way to do this. Document what the problem was, what the solution ended up as and compare that to other possible solutions to evaluate whether or not you made the right decision in the end. If you didn’t make the right decision (or even if you did) report it in the Lessons Log for future reference.
Efficiency is productivity and learning from past experience is one of the fundamental aspects of a successful project.
Check for any bugs after site migration
After the site has been signed, sealed and delivered, we give it one final check over. This is to iron out any creases that may have occurred during site migration.
It’s a rarity, but sometimes, things like links and images may still point to the test site rather than the live site so fixing broken images and links as soon as the site goes live will ensure a smooth transition from agency to client and more importantly, a happy client.
Recommend Project Closure
Project Managers run the project on a day to day basis, but are not accountable for directing it. That’s something for the Project Board. The Project Board (in larger establishments) report to Corporate or Programme Management (Managing Directors etc.) but in smaller set ups, the MD is often the Project Board. Either way, the Project Board is whom the Project Manager reports to and must recommend project closure from them before closing it. Once a project is closed, there are a few things that still need taking care of so when recommending project closure, make sure you have the following ticked off:
Back up the website
Close and archive all the documentation used throughout the length of the project and send them to the client. Take a back up of all the site files and theme folders so that you have a final signed off website that you can refer to should you need to.
At Tone we back up our client websites on a regular basis to compensate for any unexpected problems further down the line such as viruses, hacking or corruption.
Benefits Review Plan
Closing a project involves further planning. Namely in the form of a Benefits Review Plan. A Benefits Review Plan is a set of instructions detailing when, how and by whom the benefits of the website will be reviewed.
It details how the benefits of the websites are to be monitored, assessed and gained. Generally, a website will only begin to benefit long after site launch, so you need to be clear about the timescales involved to review the benefits, the people who will review them, the projected benefits made at site launch and the results at the benefit milestones.
Benefits are any sort of measurable improvement resulting from the project. So in web terms, the project would be a new website built for conversion and one of the benefits might be something like a conversion rate increase of 2%, 6 months after launch.
The Benefits Review Plan will document who, when and how the benefit will be reviewed. We use this to review what we promised the client, monitor whether the new website has improved their results and to make recommendations for up-sell should they appear to be falling short of their targets.
Project sign-off doc.
One thing that is vitally important is project sign-off. At Tone we have an internal branded sign-off document that we run through Adobe EchoSign (electronic signature software) to gain a swift client sign-off. This acts as a legally binding document that includes terms and conditions of site launch and protects both client and agency interests.
Testimonial and satisfaction
We love to get feedback from clients regarding their experience with us. So we ask for a fair testimonial (whether good or bad) after site launch which will allow us to address any problems that clients may have faced along the way and keep improving our services for the benefit of clients.
If the testimonials are glowing praises then we use these and create a case study to feature in our Success Stories section of the website. Testimonials are like feedback; accept them regardless of whether they’re good or bad. Take action to address the critiques of the not-so-positive testimonials and you’ll soon see the ratio of positive:negative increase.
At Tone we’ve perfected our digital project management process beyond recognition in recent times and tailored them to follow PRINCE2 methodologies. As such, we now receive a positive testimonial rate of 100% – pretty impressive, but it comes from admitting where you went wrong, putting plans in place to prevent it and learning from experience.
If a client is satisfied with their site and happy to give a glowing testimonial, you should consider adding them to a long-term satisfaction list. Using something like Campaign Monitor, you can keep in touch and recommend other areas for improvement in the hope of gaining some additional custom further down the line – customer retention at it’s most satisfying.
So that’s how we manage part of our processes here at Tone, I’m keen to hear how you do it yourself. Let me know in the comments how you manage your own projects or better still, make me aware of things I could be doing better as Tone Project Manager… after all, learning from numerous Lessons Logs is better than learning from just one!
Let’s learn from each other!
Was this article useful?
Subscribe to our monthly mailing list to receive more articles like this.