Fog Creek Software
Discussion Board

New specs coming up in UAT phase ...

This is a question for people who work in very structured coding environments that stick to defined accepted methodologies.  People who don't know this setting, please refrain from answering.  This is more a prject mgmt question.

We are UAT'ing our software.  It looks like some specs fell thru the cracks, and there is new code that needs to be written. 
What is the proper way to manage this?  Some changes can be delayed, but others are crucial to the software's functionality.  But you can't just stuff in new code during UAT. Should the deadlines be moved when doing development work during UAT?  You would need to repeat UAT testing after the new development. 

Friday, January 25, 2002

What is UAT?

Roman Eremin
Friday, January 25, 2002

Probably User Acceptance Testing.

Friday, January 25, 2002

Then I have no solution for this problem - we don't have "UAT phase" that prevents us from changing the system. We doing UAT for every feature as soon as it developed. These UATs are then automated and tests running daily.

So at any given moment we can add a feature and see if it breaks some others features.

Well, not everything is done this way, but this is an ideal model that we tried to get close to.

Roman Eremin
Friday, January 25, 2002

Try to schedule the 'new' feature for the next release, and not slip the date for this release.

Doing this lets you release 'on time' ... if you can have and keep a good reputation for releasing on time, then the customer might be more willing to accept defering the new feature into the next release (because they can be confident that there will be a next release, and that the next release too will be on-time as promised).

Christopher Wells
Friday, January 25, 2002

By specs that fell through the cracks, do you mean there was stuff required that wasn't specified, or certain specifications were not covered?

I assume you mean the second.  There are two things you can do:

1)Slip your launch date
2)Slip the feature from this release.

This is a client/product manager decision. This is assuming that the feature required is non trivial and will take a significant amount of time to implment.

There is one aspect of choice 2 that may be feasable:  Partial implementation.  "We can't get you X by launch time, but X is really made up of A B and C and we can get you A.  B will come 1 month later, and C two weeks afete that."

A lot depends on the contract with the customer.  During fixed cost fixed scope projects,  a company can take a real beating on this.  However, if your goal is to establish a longer term relationship with the client,  multiple release dates are not only required, they allow you to prioritize features.  Often a must have feature for launch becomes a phase two, then phase 14, then driopeed, as business priorites are changed. 

If new specs are coming up in the UAT phase that were not specified earlier, again alot depends on the contract.  If youare fixed cost fixed scope, do a change order.  This is important, as any feature you give a way without documenting digs you deeper in the hole.  Even if the fee you charge is below cost (for relationship reasons, etc)  get it recorder, speced, estimated, and charged like you did at the start of the process.  Change orders are not a bad thing, and they keep things clean and businesslike.

My father works in the contruction business building shopping malls.  At about the 1/2 point of a project, I'd estime 20% of his time is change order management.  ANd he openes the malls on time.

Adam Younga
Friday, January 25, 2002

My approach has always been to deliver the requirements first and to document new requirements as "Change Requests" with a view to delivering them later. This keeps a nice divide between when you are holding the client up and when the client is holding itself up. Petty sometimes, but I've always found it beneficial to keep this distinction.
Maybe not for small projects, but certainly for medium+ projects. The only problem is when the "Change Request" alters the original requirement, I take a pragmatic approach to this situation, if its a no brainer then I'll just do it, but if it requires re-design then its a next release enhancement.

Friday, January 25, 2002

I am more referring to crucial features that have been missed.  ie: software is rendered useless w/o the new changes, for example a data model flaw. 

How to handle this as far as users/upper mgmt..?  Clearly, coding during UAT nullifies the testing done during UAT, and would require another UAT cycle.    I guess I have answered my own question.  New coding requires another UAT phase, which means slipping the release date.

Friday, January 25, 2002

In my experience working with a software QA dept, the second round of testing is much quicker then the first, as the people doing the testing know what they are looking at. If I was your project angel, I'd suggest having your QA team do/manage the UA testing, and the developers make the minimal changes required to make the system releasable. Then the testing can happen again, with intensive tests on the new functionalty, and at least smoke tests on the stuff that you think hasn't changed.

Jamie Anstice
Sunday, January 27, 2002

Well if its the case that you've developed entirely the wrong thing because the original specification was incomplete or just wrong headed (not that rare an occurrence), its time for everyone to bite the bullet.

Sometimes you just have to begin again.

Simon Lucy
Sunday, January 27, 2002

> Sometimes you just have to begin again

Whoa, begin again?  I've NEVER seen that.  I just meant a missing feature or 2.  If a project needs to be coded again, there are serious, serious problems.  Mgmt. and/or coders, and/or business analysts simply need to be canned if that ever happend.

Sunday, January 27, 2002

Well, you said something significant was missing.

Either it is significant, in which case it calls into doubt the rest of the specification as to whether it bears any relation to reality; or its trivial, in which case being hidebound by the formal process will become a bug in itself (defining a bug as unwanted behaviour).

For instance, it emerges during the acceptance testing that a form which replaces a physical document doesn't take into account all of the combinations that the original does.  If its essentially commentary then there's no harm and the interface can be fixed up, the underlying data and so on.

If, though, their are downstream real processes which need that information then perhaps whoever did the analysis in the first place didn't understand the user's requirements at all.

This isn't even that unusual. 

Simon Lucy
Monday, January 28, 2002

SSSSS wrote:
<< I am more referring to crucial features that have been missed. ie: software is rendered useless w/o the new changes.>>

From your short description the problem seems that the customer was involved only at the end of the process. Software developments is not sequential process of writing specs, going into an ivory tower and throwing the final result back over the wall for user testing a few weeks before the release date. That's a good recipe for disaster.

Software development (including specifications) requires iterations, lots of them. Release proto's, alpha versions, beta versions and release candidates right from the start and often.

Off course, you can write the requirements together with the customer in stone, create a product that perfectly fullfills the requirements and hand it back at the end. The customer will generally tell you that it's not what she expected the product to be. Sure, you fullfilled your side of the contract, but that customer won't recommend you to anybody else.

If the features that are missing are really critical, there's not much choice than to take the loss, delay the deadline, fix the problems and test it again. Ask the customer what she wants: delay with features (which might include increased costs) or release on time without them. That choice makes critical features often a bit less critical.

Jan Derk
Monday, January 28, 2002

I get the impression that you are worried about the customer finding out about someone misplacing specs?  Because it seems like a problem solvable by speaking with the right people. 

It sounds like you're working for a military, and are stuck with a waterfall method ("very structured coding environment" is another euphemism) that you can't go backwards through easily.  Well, if the customer has all these hoops that you have to jump through...  I see no way out but to push the release date.

I can not think of any other choice, especially if you must CYA.  I guess all we're here for is to encourage you.

Frank N.
Monday, January 28, 2002

First, we need to find if the new requirements are actually 'new' or if they were missed out during the requirement analysis.
If it is a new requirement, then there is no problem. Depending on the complexity of the requirements, we can either give it in next release or postpone the dead line by a few days(with client's consent).
If the requirement is something which was missed out during requirement analysis, first option is a work around. Or we can make it a user training issue, if it is a minor one but involves lot of change.

Thursday, February 7, 2002

*  Recent Topics

*  Fog Creek Home