Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

OT: Project clients

by simon.proctor (Vicar)
on Oct 19, 2004 at 23:33 UTC ( [id://400701]=perlmeditation: print w/replies, xml ) Need Help??

This is related to Perl only in that I finally decided to write this down after people have been using one of my more inflammatory business web apps (it forces people to do work and communicate with each other). Note, I have used the *royal we* below. If your company isn't like this tell me where to send my CV ;).
I'm about to go on even more project management and my pre-activity questionnaire made me mull over something I have been wishing for a while.

The original question - what would you like your clients to be saying about you if you accidentally overheard them talking about you to one of their co-workers?

My answer? How about:

How can I better act as a client to Simon and his colleagues?

Ok, probably a little wet behind the ears at first reading but I feel quite serious about this. We spend time and money on choosing from a variety of management processes, tools and learning ways to communicate. Often through roleplay, discussion groups and generally anything to get us out of the office.

We do our utmost to get some kind of spec and (if lucky) a budget and business case. We fight against an overwhelming tide of politics, empire building, fixed timescales and infighting - sometimes within the team. We go to meetings with members of the client group and patiently sit through the usual run of character assinations and territorial markings.

Etc ... etc ... etc.

What we don't learn is how to be a good client.

So, in discussion with some work friends, at the gym and online, we started to come up with a list of things that would make a good client. Feel free to comment, add or ridicule any.
  • If the spec changes, the project time goes UP.
  • If you have a fixed timescale you have a reduced feature list
  • Cutting documentation to save time means only one person understands the application so pray they don't leave or die
  • If you don't say you what you really want then you cannot complain when it doesn't do what you wanted it to
  • Looking pretty and actually working are two different things
  • Any time quoted is always wrong - more time is always needed
  • Ringing the developer twice a day will not make them work faster. Nor will asking them to report via email, spreadsheet or other communication format.
  • Never say how something should be implemented. You are not the expert.
  • Only you understand your requirements, state them as fully and completely as possible. Write them down. Get other people to read them.
  • You are an expert in your chosen field - your service provider (developer or whatever) most likely is not. Always remember this in answering any question or in providing any information of any sort
  • If there is a business case for the project and the requirements of that are met in full then the project is a complete. It is also a success.
  • Always remember to say thank you - someone has worked hard for you

Replies are listed 'Best First'.
Re: OT: Project clients
by FoxtrotUniform (Prior) on Oct 20, 2004 at 00:00 UTC
    • 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

      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

Re: OT: Project clients
by raptnor2 (Beadle) on Oct 20, 2004 at 00:35 UTC
    Very interesting questions.

    To address these issues you should go to a more formal requirements process that forces the customer to sign off on their requirements. Letting them know that any changes effect cost and schedule (positively or negatively). Acceptance criteria is signed off with the requirements.

    This isn't designed to box them in, but a more formalized relationship seems to work the best. Everything is documented and agreed upon. Changes are welcome, as long as they understand that one change can, and usually does, effect everything else.

    A contractor that works on a house does the same thing. There's no difference in the working relationship of the two, and they have had time to perfect it.

    My two cents anyway.

    Cheers,

    John

      To address these issues you should go to a more formal requirements process that forces the customer to sign off on their requirements. Letting them know that any changes effect cost and schedule (positively or negatively). Acceptance criteria is signed off with the requirements.
      This assumes that you haven't done this already. This is my point. You have done all of this and you have learned many various ways of doing it according to what is the flavour of the month. It may be the MSF, the UP or whatever. But I could just have easily added the following to the list (though they show the more cynical side of my feelings towards corporate UK).
      • Do not ask your service provider to hack in data to the app because of a promise you have made and then swear at them when someone gets a few emails by mistake
      • Do not use your position in the company to allow you to change your mind arbitrarily and force through whatever it is you want even in the face of all the project work done so far
      • Do not assume that your service provider will be more than happy to work a string of 14 hour days to meet your arbitrary promises because if they don't you will look bad
      • Do not attend board level meetings promising what the application will do without first referring to the business case, that you have *taken with you*, each time you make a promise.
      • Do not assume you can make the project go quicker by simply putting more people onto it. Especially by not thinking you can just employ a load of school leavers or apprentices who have zero experience. Don't assume that your service provider can simply train them up. No - it isn't like your nephew doing it in their bedroom for a school project.
      • Because you don't understand your service provider it doesn't mean they are lying to you or pulling the wool over your eyes. They aren't making fun of you either.
      • If the answer doesn't meet with your experience then ask yourself who is the expert. If it is the other person then perhaps you should trust them rather than spend the next three weeks doing it your way - because you can - and only have to do it the other way as nature originally intended.
      etc etc etc.
        They almost certainly are making fun of you, but only because you deserve it.
Re: OT: Project clients
by pg (Canon) on Oct 20, 2004 at 05:15 UTC

    My wish list:

    • Wish my clients really know what they want
    • Wish my clients don't change their mind so often
    • Wish my clients read my documentation seriously
    • Wish that I can write my documentation with regexp, so its meaning is much more precise
    • Wish my clients don't start their user acceptance testing in the last week of the four weeks time allocated
    • Wish your co-workers don't blame each other when something goes wrong
    • Wish your co-workers mention each other's names when there is some success
Re: OT: Project clients
by castaway (Parson) on Oct 20, 2004 at 10:06 UTC
    In a slightly 'other view' opinion: As a technical person in a certain field, one shouldn't expect clients to know half of these things, or even to take account of them (even though in most fields, if you change your mind about you want, the result is likely to take longer).

    Thus, in your first contact with a new client/customer, these things should be laid out in the original contract, or whatever it is. Even with less formal, 'internal' clients, effort should be made to make sure these things are clear. Write them down, hang them on your door, whereever. Thus, when such a problem comes up, you can point to that document, and say 'yes, sure we can do that, but, it will take longer..'.

    Another item:

    • Know in advance how you will *test* the results, dont think about it after the project is done. (This usually helps define the actual spec).

    C.

Re: OT: Project clients
by Anonymous Monk on Oct 20, 2004 at 11:52 UTC
    • If the spec changes, the project time goes UP.

      While I think it's important clients realise that changing the specs might not always happen without a price, I think that you as a developer aren't doing it right if they get a fear of changing specs.

      Over time, peoples expectations or wishes change, for various reasons. A change of demand from their customers (or users). A merge of companies or divisions. New features in third party software my software is going to interface with. Better understanding of the problem that needs to be solved.

      I rather have customers that know their changes can be dealt with in a reasonable way.

    • If you have a fixed timescale you have a reduced feature list

      This I do not understand. First we discuss the feature list, then we discuss the timescale. Then we make a deal. We don't reduce features just because the timescale is fixed.

      If I were a customer, and you'd reduce the feature list because the timescale is fixed, I won't pay you.

    • Cutting documentation to save time means only one person understands the application so pray they don't leave or die

      That's not the developers problem, is it?

    • If you don't say you what you really want then you cannot complain when it doesn't do what you wanted it to

      Specs should always be written by both sides. If the spec isn't want the customer really wants, then the blame can't entirely lie at the customers side. He doesn't (fully) understand your language, but you should realize that you don't (fully) understand his.

      Try this for an exercise: write a spec what the surgeon should do to remove your gall stones. Are you sure you want the surgeon to perform the operation according to specs?

    • Looking pretty and actually working are two different things

      But not multiple exclusive.

    • Any time quoted is always wrong - more time is always needed

      I rather not have customer say that about me!

    • Ringing the developer twice a day will not make them work faster. Nor will asking them to report via email, spreadsheet or other communication format.

      Why does a customer even have the phone number or email address of a developer? That's why there are (account) managers.

      But it is important to keep customers informed about progress. Any large project should have milestones, and customers should be informed when those milestones are reached. Or when they are not reached on their targetted date. You like to hear what's the status of perl6 is as well, don't you?

    • Never say how something should be implemented. You are not the expert.

      Only partially true. They have more knowledge what their in-house expertise is than you. You may decide that Windows is a better platform to run your application on than Unix, but if they are a HP-UX only shop, you have to be very convincing that your application is worth hiring Windows expertise to keep the underlaying platform running.

    • You are an expert in your chosen field - your service provider (developer or whatever) most likely is not. Always remember this in answering any question or in providing any information of any sort

      Now, if only developers would have the same curtesy towards customers...

    • If there is a business case for the project and the requirements of that are met in full then the project is a complete. It is also a success.

      Dream on! Complete projects that meet the specification can be a success. But a lot of times, they aren't. It's only a success if both parties are satisfied. And for parties to be satisfied, one needs more than staying inside the specifications.

      Few things are more frustrating than to have to ask the client how do they want this or that detail via an account manager. Especialy since the account manager usualy knows next to nothing about programming and nothing at all about the client's domain. No specs are ever complete and having someone from the client company/department you can go with your questions to is indispensable. If you have to ask your account manager to ask their account manager to ask someone who actually has an idea what they are doing and your question and their reply is mangled by those two managers, you are wasting time. Since you either have to wait or switch to some other part of the application. And such switches slow you down.

      So, no, clients should not have programmers' phone numbers, but programmers should have the email/ICQ/AIM/Y!/... of the client's employee they can contact.

      Jenda
      We'd like to help you learn to help yourself
      Look around you, all you see are sympathetic eyes
      Stroll around the grounds until you feel at home
         -- P. Simon in Mrs. Robinson

      Why does a customer even have the phone number or email address of a developer? That's why there are (account) managers.

      Well, firstly, it can happen when one works as an independant contractor. I often am my account manager. Secondly, when I'm hired by an agency, I often work at the client's site alongside people with jobs related to my project. This is great, because it allows a fantastic level of communication between your client and the developer/consultant.

      However, management does sometimes abuse the situation by "bugging" the developer about project updates to the point where more time is spent on status reports than is spent developing.

      I have actually, on several occasions, made a status report like:

      [Project Status Update] #lots of required manager-speak and details Summary: - I continue to debug the application, much as I have for the past sev +eral days. - I continue to write these updates, which causes further delay on pro +ject work.

      Suprisingly, every time I do that, the requirement for daily updates goes away. :)

      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
      Cutting documentation to save time means only one person understands the application so pray they don't leave or die
      That's not the developers problem, is it?
      It is, because the only one who will understand the app is the developer. That means wasting a lot of time explaining the application, or becoming an extension of it; "Can you put these 2 MS-Word pages in our Content-management system? We can't remember how it works". In my experience developers hate doing that :-)

        It is, because the only one who will understand the app is the developer.

        And it's not; it's a responsibility the business has willingly shouldered, and delegated to the programmer. I've been in this situation more than once--the business chooses to cut corners now, ignoring future costs. That is their perogative. But it is not (necessarily) the programmer's responsibility to set policy.

        I'd say putting in 2 MS-Word pages in a CM system takes X hours. Those X hours are of course billable. Or do you work for free?
      If you have a fixed timescale you have a reduced feature list

      This I do not understand. First we discuss the feature list, then we discuss the timescale. Then we make a deal. We don't reduce features just because the timescale is fixed.

      If I were a customer, and you'd reduce the feature list because the timescale is fixed, I won't pay you.


      The timescale is not fixed if you can discuss the feature list, then the timescale. A fixed timescale means that your completion date is fixed before starting talks about what features you want.

      You can't expect someone to implement an arbitrary number of features when the timescale can not move (well, I suppose you can expect anything you want, but you will also be sorely disappointed with reality).

Three steps to sanity
by bibliophile (Prior) on Oct 21, 2004 at 14:30 UTC
    I've found (in any non-trivial but non-monstrous development) that the following works well (from dev perspective):

    • Build a *minimally functional* app based on client specs. Plan to throw it away; you will anyway.
    • Based on feedback, build a second minimally functional app, knowing it will evolve. Evolve it based on client priority list.
    • Once everything has more-or-less settled down, redesign based on what you now know the client *really* wanted, and reimplement.

    Much (most?) from step 2 ends up in step 3, so it's not really "wasted" time... :-)

        Thanks for the links... interesting reading, but not really what I was getting at :-)

        I was aiming for (though I seem to have missed the target!) the idea that you shouldn't put a ton of effort into building a system until you understand what system to build...

      Build a *minimally functional* app based on client specs. Plan to throw it away; you will anyway.

      Not even Brooks believes that any more.

      In fact, near the end of The Mythical Man-Month's 20th-anniversary edition, Brooks acknowledges that his advice to "build one to throw away" sounds suspiciously like "make sure the one you keep suffers from the second-system effect", since it's going to be the second system you build. :-)

      Non-dogmatic refactoring has worked well for me. Don't feel obliged to reuse code that sucks, but don't feel obliged to throw it out just because Brooks said so in the 1970s, either.

      (While we're at it, why stop at three steps?)

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

        Refactoring, yes... but I would include "refactoring" of both the design, and my understanding of the client's understanding of the design. And of the client's understanding of the problem. And my understanding of the client's understanding of the problem.

        Hmm. I think what I'm trying to get at is simply that the system you end up implementing may bear little resemblence to the system you *thought* you were going to build :-)

        (Why three? Just MHO. Seems to be enough iterations to get to the right design, without being too many to do in a reasonable time frame. <shrug>)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://400701]
Approved by BrowserUk
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (5)
As of 2024-03-29 09:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found