Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^4: Improving Your Ability to Estimate

by dws (Chancellor)
on Feb 14, 2005 at 06:53 UTC ( [id://430708]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Improving Your Ability to Estimate
in thread Improving Your Ability to Estimate

If you understand what your client is ultimately wanting to achieving, you will see (much of) the scope creep before they do.

When you start thinking that you're smarter than your client, and that you can know what they want before they do, you're on very dangerous ground. You may be right much of the time, but when you're wrong you can find yourself down a deep hole.

If you do not really understand what they ultimately want out of the project, then you don't know whether they really understand what they want.

You avoid this trap by showing your client working software at frequent intervals, and by asking "Is this right? Is this what you meant?", letting them clarify, change their minds, let you know about new requirements, or smile and nod. You both gain understanding and trust incrementally.

Scott Ambler has a talk titled Are You Agile, or Are You Fragile that touches on this problem.

  • Comment on Re^4: Improving Your Ability to Estimate

Replies are listed 'Best First'.
Re^5: Improving Your Ability to Estimate (needs)
by tye (Sage) on Feb 14, 2005 at 07:45 UTC

    I'm rather shocked at how rarely I see one phase of software development that I was taught: Needs analysis. If I'm working on an important project, I don't just take a spec that is handed to me; I study the needs of the client / customer and analyse them. The needs often start out as a spec. But, in my experience, if the client is savvy enough to get the spec right, then they don't usually go contracting the work out.

    Most of the mistakes I've made in contracts is when I've let the client dictate what was to be done without analysing whether that really made sense and pushing back quite hard with what my analysis says should be done. If the client disagrees, then I need to work to find out whether I'm missing part of the picture or the client is.

    There can be differences of opinion as to how to do something, and often the client gets to dictate those since they are paying (but sometimes I get to dictate them since I'm the expert being hired and so should know what I'm doing). But if there is a disconnect as to what is needed, then the project is going to go quite badly.

    And the most common way I've seen for the needs analysis to be done wrong (other than "not at all") is for the person doing the design to not talk to the ultimate consumers of the proposed work. Talking to the boss who is going to pay you is just the first step. You need to talk to the peons doing the work and see how they really do things and discuss how they'd use what you are considering writing.

    So, yes, I usually know what the client needs better than any one of them does once I've taken on a project. I may not know what they want better than they do, but I don't care as much about that so long as the paperwork is clear -- since I've experienced giving them what they want but didn't need and found that to be much worse for all involved than giving them what they need but didn't think they wanted that was also what was spelled out in the contract (which prevents them from easily dismissing the work which gives them time to realize that they did need it -- usually soon after they give it to their peons).

    Of course, I make an effort to understand what they want and to explain what they'll be getting. Proper expectations make things go so much more smoothly. But wants are harder to pin down than needs and specifications, so I try harder to make sure the latter line up. You can do a lot to verify needs and specifications but for "wants" you are stuck with how well they can communicate what is in their head.

    If I ever ask a client "Is this what you meant?" that's a red flag that I'm nearly driving blind.

    - tye        

Re^5: Improving Your Ability to Estimate
by etcshadow (Priest) on Feb 14, 2005 at 08:17 UTC
    When you start thinking that you're smarter than your client, and that you can know what they want before they do, you're on very dangerous ground.

    Well, that's not what I said. You're right: it's dangerous (and basically always wrong, for all intents and purposes) to think that you are smarter than your clients. But that doesn't mean you should assume that they are smarter than you. What I meant to describe was more of a partnership. They are going to know the subject matter better than you. That's basically a given. You are going to know how to develop software better than them. That is also a given.

    That's the point, really... if you get into the business of letting your clients design your (as in your and theirs, remember: it's a partnership) software, alone, with you as a passive requirements-to-code translator, that's where the problems start. When saying that you will see the scope creep coming before they do, what I mean is: you have experience developing software, and they don't. If you really understand what the client wants, and you have any experience with similar situations, then this will give you a heads-up to potential issues. Use that forewarning of danger as an opportunity to avoid it. When you encounter those watch-signs, ask questions that the client never bothered to give you the answers for in advance (because they, lacking your experience at software development, will not have thought of all the potential issues).

    ------------ :Wq Not an editor command: Wq

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2024-04-20 00:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found