4

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?

3

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.

  • 1
    Trouble is a lot of these amendments are asked once they see the work, so if I do kanban which I do, it just means that more items are added to the list delaying sign off. – bobo2000 Feb 16 '17 at 17:12
  • @bobo2000 Why is that a problem, assuming the work is shown to them early and often? – Sarov Feb 16 '17 at 17:23
  • It isn't if you look at it from that perspective, but from my perspective I want to minimise scope creep and get work delivered. – bobo2000 Feb 16 '17 at 18:10
  • 1
    @bobo2000 Is the customer happy? That's the number one goal. If they are, then perhaps all you need to do is look at how your write the contracts up front to make sure you end up equitably compensated for your work. Change will happen, no matter what. Alternately, when the client ask for something new you can respond with "Yes, and what should I not do instead?", which can then lead to the compensation conversation again. – Joel Bancroft-Connors Feb 20 '17 at 21:28
1

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.

1

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.

  • The issue I have with this type of approach is it leans towards "cover my ass" instead of "realising that requirements for projects change during a project". It's a bit archaic, and why agile is getting so popular now. It's time, as project managers, we start realising that waterfall just doesn't work most of the time. Waterfall allows us to say: "See? You agreed to it all those months ago!" and makes the client feel like they're getting cheated, and totally ignores the fact that at the start of a project is when we know least about it. – dKen Feb 19 '17 at 4:09
0

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.

0

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.