http://qs321.pair.com?node_id=400711


in reply to OT: Project clients

  • If you don't say you what you really want then you cannot complain when it doesn't do what you wanted it to
  • Only you understand your requirements, state them as fully and completely as possible. Write them down. Get other people to read them.

These points assume that the clients know what they want ahead of time. I don't think that's necessarily a fair assumption - there's no reason to expect that they're omniscient.

Let me give you a somewhat monomaniacal example. I keep a bunch of utility code around for my own use. I'm both the client (writing applications using these libraries) and the developer (writing the libraries). When I'm writing the libraries, I usually stick with a simple interface until I know what I want. When I'm writing the applications, I run into a lot of mistaken assumptions at the interface, and modify the libraries appropriately.

For example, I do a fair bit of real-time 3d graphics hacking. One of my assumptions was "a texture is always created from a bitmap". I ran into trouble when I tried to build textures procedurally on the graphics card.

The point I'm trying to make is that people aren't likely to know what the Right Thing To Do is until they have some experience with the problem. Making people sign off on requirements ahead of time isn't a great idea; planning for requirements changes (yes, and allowing a lot more time for development) is more realistic.

--
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

Replies are listed 'Best First'.
Re^2: OT: Project clients
by simon.proctor (Vicar) on Oct 20, 2004 at 00:27 UTC
    These points assume that the clients know what they want ahead of time.
    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
    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.
    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.
      (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

        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.
        That must make my list in some form ;).
        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