in reply to OT: Project clients

Replies are listed 'Best First'.
Re^2: OT: Project clients
by Jenda (Abbot) on Oct 20, 2004 at 12:36 UTC

    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

[reply]
Re^2: OT: Project clients
by radiantmatrix (Parson) on Oct 20, 2004 at 13:50 UTC
    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.

    [download]

    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
[reply]
[d/l]
Re^2: OT: Project clients
by Joost (Canon) on Oct 20, 2004 at 13:15 UTC
    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 :-)

    "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]
      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.

[reply]
      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?
[reply]
[reply]
Re^2: OT: Project clients
by Anonymous Monk on Oct 20, 2004 at 19:00 UTC
    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).

[reply]

In Section Meditations