So, you’ve tested the site and are approaching the sign-off phase but before you can jump the last hurdle the client turns around to you and says, “Well actually, I’d like it to do….”
You check back through your Technical Requirements Specification and lo and behold, what’s been asked of you was never in the TRS and has never been mentioned. So, what do you do?
I’m going to go ahead and do it anyway of course!
Are you now? And so the project begins to creep, and creep, and creep until what the client finally signs off on bears no resemblance to the original project. They’re happy but you’re out of pocket and way behind on other projects.
When a client asks you to add something to their site, it’s time to put your best Business Analyst hat on and see whether what is asked for is necessary for the project. Will it add any value to the project? Is it actually relevant? Will it be used? Is it worth it financially?
Ask your client why they want this add-on? You’d be surprised at the number of people who will say “I read about it in…”, “Everybody’s doing it…”, “So-and-So’s got it…” Yeah? So what?! If it’s not going to add value to them, why bother?
Of course, if the addition is relevant and worthwhile then you need a way of handling it so it doesn’t become a millstone around your neck. This is where the change request comes in.
I had one client who asked for an addition to a website, “Sure thing” said the Project Manager, “We can do that for you.” And so the cycle of creep began.
Because the change was never properly scoped out, spec’d out (or anything “out” for that matter) we delivered what we thought the client wanted – big mistake! A revision was made, then another, then another. Soon we had essentially lost the profit on the original job and 3 other projects were backed up all because of one client and the merry-go-round they put us on.
Eventually the client was happy (we weren’t of course!) and what they finally signed off on was actually the first revision we’d sent to them! If the change had been scoped properly in the first place we would have known what was expected of us and what we were to deliver. Also, due to a clause in the contract, because the client messed us around so much and went back to the first delivered option we would have been able to claw some (much needed) money back.
Okay, I don’t fancy going ’round in circles. What do I have to do?
Firstly, sit down with the client and see if what they want is actually worth doing and is it worth doing now? It may be beneficial to wait 3 months after the website’s launch to roll out the specific feature they want (for example when they have a big enough user base). Will it add any value to their website and/or business? Will it be out of date in 6 months? Will they actually use it?
If you feel that the addition is indeed worthwhile, this is where the change request form comes in. The form allows you to scope out the details of the addition rather like a mini TRS. Listing what it’s supposed to do, functionality, how it will fit in with the existing site/infrastructure etc. This will then allow you to estimate how long the project will take.
Whether you charge for the addition will depend on how long it’ll take, how much profit is left in the budget and how much you want to impress/retain the client. For example if you really want to work with the client again you may throw the addition in as a freebie, if you really couldn’t care less about them and have already lost money on the project then you may try and make a bit back (although we’d never overcharge now, would we ;)).
Once you’ve decided on the charging, the sheet is presented to the client, outlining the functionality, delivery date and cost (if applicable). The client then signs this off and the design, development and testing takes place.
When the addition is delivered, the client will either sign-off on it and the project moves to the sign-off and delivery stage, or they’ll ask for further changes. Again, if this wasn’t in the TRS or the previous change request you repeat the process.
This practice is very useful as you have a fully documented trail of changes and the client can see the escalating cost of the project quickly – which is great if you want a way to dissuade them from further work for the time being!
In conjunction with the Contract and the TRS, the Change Request form is very useful if the client tries to blag their way into the “but you said it would do…” mode of thinking. You have a fully documented trail (with their signature on it, hoorah!) to prove what the site was meant to do and what it does now.
Change requests are also useful for identifying “problem” clients – you know the ones I mean, always on the ‘phone asking for this, that and the other. With a Change Request Form you can track these clients, see how much time they’re costing you (and therefore money) and see if they’re actually worth keeping.
And, another benefit of the change request is that when you revisit the site in a year’s time to do some work you have all of the modifications documented so you don’t have to ferret around in the code trying to figure out what you did all those months ago!
Sounds great! What do I need on it?
Basic elements of the Change Request Form include:
- Client Name/Reference Number
- Revision Number – Useful for keeping track of how many revisions/what stage you’re at
- Revision Request – What has the client asked for, how will it work?
- Date Requested
- Time required for revision
- Due Date
- Client signature (although they could agree by email – but make sure you keep it!) & date signed off
The above may vary depending on the nature of the client and project but it should be enough to allow you to keep track of the changes and the move forward to the next stage – Sign-Off and Delivery
Featured Image: Photo by Markus Spiske freeforcommercialuse.net from Pexels
Managing Web Projectsfull course
- Managing Web Projects #3 – The Pitch
- Managing Web Projects #2 – The Workflow
- Managing Web Projects #1 – The Brainstorm
- Managing Web Projects #5 – The Contract
- Managing Web Projects #4 – The Quote
- Managing Web Projects #7 – Sourcing the team and Managing the Project
- Managing Web Projects #6 – The Technical Requirements Specification
- Managing Web Projects #8 – The Design Process
- Managing Web Projects #9 – The Development Process
- Managing Web Projects #10 – Testing the Product
- Managing Web Projects #11 – The Change Request Form
- Managing Web Projects #12 – Sign-off and “Delivery”
- Managing Web Projects #13 – Invoicing the client
- Managing Web Projects #14 – Maintenance Contracts
- Managing Web Projects – The Whole Shebang
Subscribe to our mailing list
Join Hundreds of readers who have access to exclusive downloads and content