Re^2: OT: Project clients

These points assume that the clients know what they 
want ahead of time.
[download]

I see where you are going but if you don't know what you want why do you want me to do something that you will change?

Making people sign off on requirements ahead of time 
isn't a great idea
[download]

I have to disagree here. If this was the case then there would be no need for a business case for a project. A business case has a set of goals and requirements with indicators as to how those can be met (so measured against). Of course the requirements may change but then they can only do so in the face of the business case. If the business case doesn't marry with the changed requirements then either must change. If the business case changes then it needs re-approval as the sponsor or steering group may need to understand the scope of this change. It may change how someone does their job, how long a process takes (etc).

It also means that the project timescale and timeline has changed.

Finally there is a difference between the following (using your example):

all textures will be created from a bitmap.
[download]

and this

All textures will be created by our designers. We must 
agree the formats the application will support as part
of the new workflow in the design team.
[download]

Comment on Re^2: OT: Project clients Select or Download Code

Replies are listed 'Best First'.
Re^3: OT: Project clients by FoxtrotUniform (Prior) on Oct 20, 2004 at 00:50 UTC
(I)f you don't know what you want why do you want me to do something that you will change? Because it's the best I can do. As a client, I probably don't know exactly what I want until I try to do it. I can give you a general idea of what I want, and when you give me a program that does it I can use it for a while, see what I like and what I don't, and ask for updates. Making people sign off on requirements ahead of time isn't a great idea I have to disagree here. If this was the case then there would be no need for a business case for a project. Okay, I think I stated my point a bit too strongly. I don't mean that specifications are useless, and that design and development should proceed on an ad-hoc, seat-of-the-pants basis. What I mean is that getting your clients to sign off on a comprehensive business case that doesn't change, ever, is probably going to result in unhappy clients. If nothing else, the business environment is probably going to change between specification and delivery. By all means, maintain the project's business case: solving the business problem is what your software's all about. When the business case changes, make allowances in the schedule, because changing the program takes time. But it's much better to keep getting feedback over the course of a project's lifetime than it is for the developers to deliver a product that satisfies the initial requirements perfectly and is completely unsuitable for what the company's trying to do now. ("Hey, you signed off on it two years ago, don't come complaining to me if it isn't what you wanted.") Finally there is a difference between the following (using your example): all textures will be created from a bitmap. and this All textures will be created by our designers. We must agree the formats the application will support as part of the new workflow in the design team. Sure there is: the first one is a technical requirement, while the second one is not. Only the first one is at all interesting in the context of my example, which was purely technical. Your misunderstanding is probably my fault; I'm using technical jargon with subtle semantic nuances in a public forum that isn't dedicated to graphics programming. (To me, a "texture" is a chunk of memory that the graphics card can map onto polygons, while a "bitmap" is a chunk of memory representing pixels in a raster image. No designers are involved at this level of abstraction.) This thread is an example of what I'm talking about: we don't really understand each other's assumptions, so we need to go back and forth, clarifying our points and (with luck) iteratively coming closer. `--` Yours in pedantry,`F o x t r o t U n i f o r m` "Lines of code don't matter as long as I'm not writing them." -- merlyn	[reply]
Re^4: OT: Project clients by simon.proctor (Vicar) on Oct 20, 2004 at 08:18 UTC
`We don't really understand each other's assumptions, so we need to go back and forth, clarifying our points and (with luck) iteratively coming closer.` [download] That must make my list in some form ;).	[reply] [d/l]
Re^4: OT: Project clients by radiantmatrix (Parson) on Oct 20, 2004 at 13:38 UTC
getting your clients to sign off on a comprehensive business case that doesn't change, ever, is probably going to result in unhappy clients. If nothing else, the business environment is probably going to change between specification and delivery. The point behind getting a signed business case isn't that it shouldn't ever change. The idea is that it can't be changed lightly, and there is an understanding that altering the business case is going to change your estimate of time and may even require you to re-write code. If I am given a business case, I can make a reasonable projection of how long the project will take and what resources it will require. If the business case changes -- and especially if that change requires re-work -- those projections must change, as I will never be able to meet the original deadline. By having a signed business case (or "deliverables" document), you CYA: the client has an understanding that they are essentially altering the contract. radiantmatrix `require General::Disclaimer;` "Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy	[reply]