Fog Creek Software
Discussion Board

Last minute changes

It's one week before the deadline for a project that has gone on for 2 years, and the client is making lots of last minute requests and changes.
Should I go ahead and make the changes, even though they won't extend the deadline? One of the changes, for example, requires re-designing the database. We have already tested the application and there won't be time to test it again.

Sunday, September 22, 2002

Your client should be aware that all changes may extend the deadline. Sure, sometimes it doesn't, but a DB change may introduce other issues that may not be discovered immediately. Personally I'd be telling the client to write an enhancement list which you will scope out after the product is delivered.

Sunday, September 22, 2002

No way. If they won't extend the deadline why should you add more features!

Matthew Lock
Sunday, September 22, 2002

If the changes introduce bugs, who's going to be the blame? I doubt the client will feel it's their fault.

Adrian Gilby
Sunday, September 22, 2002

(Sigh). GET the blame.

Adrian Gilby
Sunday, September 22, 2002

You know the answer.  "Version 2."

Remember to spin it to the client like you're doing them a favor.  Which you are.

Sunday, September 22, 2002

What I have seen is such "last minute" changes typically introduce bugs somewhere in the system and are really untraceable unless you do a full regression testing of the system (becomes a real pain... ).

As a Project Manager your reply to such changes should be a firm "NO" and if the client is too keen on having those changes put-in (which they generally are.... !), then you should negotiate on Time and the Money part (as per the "contract"). If the above things to not fetch any results then better stick to your earlier firm "NO".

Well, the best line to follow is "Deliver something which works fine but doesn't have a few features rather than something which is full of features (which the client requested at the last minute) and has lotsa bugs here and there".

Also if such things are happening regulary at your place then you need to take a serious note of it and put a "Change Management" policy / system in place to tackle such issues. May be involve the client also while finalising the terms of the change mgmt. process.

Monday, September 23, 2002

Your project plan should have lots of assumptions, one of which is feature freeze at a certain point, additional features cost time and money.

I'd try to pass this one to upper management, while making a _new_ project plan for the feature enhancements - the new enhancements are a new waterfall immediately following the current one.  (I'm assuming you are using some kind of iterative model here.  If not, it's just a new waterfall.)

In any event, you get to come back with "Well, the project will be done on-time and under-budget.  In order to test the changes you have requested out properly, we'll need a new coding, integration, and system test phase - so those can be done in an additional month with a cost of $XX,YYY.

When they balk and insist you can skip the tests, just point out that could create quality problems.  If they say quality i sn't an issue, point out that "Maybe quality isn't an issue to you, but, honestly, our reputation of producing high-quality software is a selling point, and I'm afraid I can't jeapordize it ..."

Or some things to that effect.  I hope that helps.

The XP model is to expect and anticipate change.  Complete feature freeze is probably unrealistic.  My best advice is to roll with the punches, and make sure upper mgt and the customer are aware of the consequnces for the decisions they make.


Matt H.
Monday, September 23, 2002

"We have already tested the application and there won't be time to test it again."

I think you have answered your own question. You can not be seriously considering shipping without testing. Wether or not you can deliver (make your deadline) without the requested changes will depend on your contract.

Just me (Sir to you)
Monday, September 23, 2002

Let's focus on another (more psychologic) point here,

It's a customer's typical reaction to add 'last minute' features. From his point of view, ending the project can be frustrating for many reasons :

- His 'I-m-proud-to-handle-it' project will be released, and go to production.

- Your team will no more be at his disposal to discuss features, load handling, GUI design, etc ...

- It's his last chance to have you do things for free (with no extra bill).

Generally, the best thing to do is to speak about the end of the project very early, to smoothen the 'orphan customer effect' at every step along the way. But I assume you run a little short of time for this.

Here's what I'll do :

I believe you have a time period called 'guarantee' in which you will keep one part of your team (maybe only yourself) to work on last minutes bugs.

At this point, bugs and new features will be difficult to distinguish.

Tell your customer this period can be used to add 'light weight' features because you never get so much bugs at the end of your projects.

Then, when you go to guarantee (which means he signed the project end), correct the last 'real bugs' and negociate hard for what you can do for him during the last days you have on the project.

If you're good at it, everyboby wins :

- you're on schedule, so your boss will be glad.

- you made everything possible to add the features your customer requested, so he's pleased.

- You specified (and sold) V1.1 (maybe you can call it V2, if the database change is huge) during the guarantee so your 'sales friend' will also be pleased.

I know it won't be easy, but keep in mind that ending a project is never easy. It's always your hardest task as a project manager.

Monday, September 23, 2002

It depends on how big the changes are, up until this point I would imagine that your client has been "ignoring" the problem of how to test and use the software.
Now the project is actually about to go live I assume the various departments at the client have suddenly woken up to the fact that "frobozz sales ordering" is changing into "widget sales ordering" and have actually bothered to fire up the software, they're now moaning 'cos they know if they leave it they'll be stuck with something unworkable.
Its very difficult for developers to understand that until the client can use the software, most clients will ignore it. Here I try to force people into using early versions by physically going round and discussing it with them. However often since I'm talking to someone whose knowledge of the problem domain isn't first hand things get missed. This is particularly true of "sales" type applications (which is why I used it as my example above) because you'll often end up talking to the manager rather the poor telesales folk who really have to use the software and often use the "View/Hidden magic" menu option.

In practical terms heres a little check list of stuff I would think of at this stage:
a) Can you afford to do this? How are you being paid? Is this on a time basis or on a fixed price? If it's on a fixed rate then all you have to worry about is feature creep, get a written list and point out that anything else will cost more money. If you are still making money then do it, the arguments and management time burnt up afterwards if you stick to the original spec can be horrendous, but always get that list on paper, and write to the client thanking them for their list and confirming that any further changes will be chargable. If it's on a time basis then most of this doesn't matter too much but perhaps charging a lower rate to fix this list might politically be a good idea.
b) Time as always at this stage is tight, see if you can negotiate some extra time to perform more testing. If you can't write to the client documenting that while you can perform these changes in your opinion extra time should be allocated for testing and the client will be going live at their own risk.
c) If you stick with the current spec, can the client still run their business (or sell the product)? If not it will be no good to them so whats the point, you'll just end up with a bad debt. Failing that quote them for doing a version 1.1 with the stuff they need fixed along with a time scale (I assume a month or two would be sufficient)

If the client insists upon a course of action (e.g. going live), document why you feel this is a bad idea and give them your recommended course instead. If at the same time you can document the fact that the client has had three interim versions of the software and did no in-house usability testing and it's a real shame that nobody looked at it (perhaps give them the "get out" that you know the "sales team" are all busy people etc so you don't offend them too much) you'll then be in a much stronger position should it all go rotten.

Having lost a couple of court cases where the sales folks never wrote anything down just discussed it verbally, I can only stress that writing it down and faxing it over is a good idea. In particular if you sent "bill" a fax detailing your concerns wrt time/testing as result of the changes, when "bills" boss talks to your boss when it all goes wrong the ability to wave a fax which says "I told you so" can be really useful.
In my particular domain (accounting software) for users who are doing an upgrade from our previous version we ask them to sign a checklist saying that they have checked they can buy and sell products with the new version (they often had some odd modification or program perhaps four years ago we've all forgotten about) So far we've only had to wave the document at one customer who phoned up demanding instant "free" changes because his sales invoices had the wrong prices.

Monday, September 23, 2002

PC, you should just laugh if anyone asks for changes one week before the deadline of a 2-year project.

Monday, September 23, 2002

You mean there are two year projects that *don't* have changes introduced in the last week? Yeah, right. Next you'll be telling me Santa is real.


Thursday, September 26, 2002

They call them successes.

Saturday, September 28, 2002

*  Recent Topics

*  Fog Creek Home