Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
I generally find signing off projects hard. Every time I think that I am about to sign the project off, something crops up unexpectedly with the client asking for last minute amendments.
This can lead to delays, or my budget going out of whack.
Is this normal?
Whether or not it is 'normal' is highly subjective and contextual.
What is more important is whether or not it is a problem (which I assume it is, otherwise why are you here asking about it?), and, if so, how to fix it.
The problem you have is that of clients asking for last-minute amendments. This can be broken down into two sub-problems: 1) The client is asking for amendments. 2) The client's amendments are being asked in the last minute.
The first sub-problem is never going to go away, for the simple fact that users do not know what they want. Users are incapable of providing a complete description of what they want at the onset of a project, because they simply do not know.
Thus, the only viable approach is to solve the second sub-problem. Namely, that these amendments are being made in the last minute. This is the entire idea behind Agile development. By obtaining customer feedback early and often, by the time you finish the project, there is nothing new for the customer to even see, and thus they (ideally) will have no further feedback for you.
That sounds like there was only an informal change request process and maybe an informal project close process?
The idea of a change request process is to make situations like this less likely. The client requests a change, they're told to give more details, and then they're informed how it will impact the budget and scope and schedule. The act of getting them to provide more details ensures they can't fire off rapid requests for change like this: "Do X...no wait do Y! Wait wait and do Z too!"
Telling them that the budget and schedule increase will also make them think twice about whether that "small" change is really worthwhile.
If this keeps happening, at some you may have to lean on the business contract for the project. There should be some kind of definition of done that satisfies both the client and your company.
It can be all too common, yes.
PMBOK does refer to several techniques which can help the process, however;
When collecting requirements and then feeding into scope - obtain customer acceptance requirements.
Build a work breakdown structure, containing 100% of the work required to deliver the project.
When you're reporting on the project progress, always report against the key scope and work breakdown structure.
These techniques aren't foolproof, but if you continually refer to what you have agreed you are going to deliver, it makes it a lot clearer to the customer what is being delivered. That way if the scope has honestly changed, you can instigate the agreed change control process (something else you should agree with your customer) and determine budget impacts.
Its boring, methodical work to collate this, but that's the secret of successful project management.
Defining scope is hard - service provider and service consumer are in tension - the service consumer wants maximum scope at minimum cost while the service provider wants maximum profit and minimum scope.
If scope is nailed down up front and aggressively managed, signoff is easier. If scope is not strictly defined and managed, all the ambiguity floats to the end of the engagement.
The task is hard - it can be done up front or late.
A specific answer to your question depends on a couple of factors. I see from a comment above you say:
I want to minimise scope creep and get work delivered
Which would change my suggested solution, as opposed to if you were thinking:
I want to deliver a useful and successful product for my client
Those two things don't necessarily go hand in hand. From the sounds of things your major frustration is changes to scope late in the project. So, if your ultimate goal was to minimise scope creep and get the solution delivered, then defining the requirements up-front and sticking to your guns will maximise your chances to finish the project and deliver it. However, it very well may annoy your customer since you seem to be inflexible and difficult.
The alternative is to accept that people change their minds, business requirements change and being a bit flexible makes the client much happier and the product likely better. In this case, manage the changes by making it 100% clear you're okay with a few last-minute changes, but that you will charge for them and they may need to wait until you finish other work.
Ultimately, the question could be summarised as: do you just want to finish the work, bank the cheque and start on the next job ASAP, or do you want to give your clients a great experience and a better product?
Disclaimer: I've made a ton of assumptions here since there wasn't much to go on, so apologies if I've misread the situation. Let me know and I'll delete this response if so!
