How do you accomplish this and still keep goodwill with the customer?
4. It's better to take MORE time in the design stage to get it right,
then having to go back and re-engineer the entire product.
5. All aspects of the design and code have to be traced to requirements,
if it isn't in a requirement then it's a feature creep OR you missed a
critical requirement.
I have never worked on any project where the customer was able to fully
define the specifications. They can give general guidelines and sometimes
these are very specific if the customer is extremely knowledgeable. But
most times they are not. They do not see the full scope of the project
(i.e., specifications) until they start seeing the software in action. Then
they realize requirements which we would call scope creep. Actually, the
real problem is that the customer is not an IT professional and they do not
realize what can be done ( or not) and thus they give specifications based
upon what they think can be done. Then when they see the application they
begin to realize what actually can be done (or not).
It also depends upon who the customer is. There should be much less scope
creep or none if the customer is also an IT professional. However, the
history of VistA is to let the actual users of the proposed software define
the specifications. I cannot tell you how many times I gave them what they
asked for and they agreed. But that is not what they meant. Hopefully if I
had done my job right, the changes only involve minor modifications. In
fact, good programmers in the VA will anticipate the need to change their
code when the customer finally sees what they asked for and will design that
software to be easily modifiable. There are costs with this approach both
in terms of efficiency and actual costs.
When I mentioned goodwill, I was referring to the developers response to the
customer when scope creep occurs. If you are going to nickel and dime them
to death for all specification changes, then you will develop ill will with
the customer.
----- Original Message -----
From: "Piet van Weel" <[EMAIL PROTECTED]>
To: <hardhats-members@lists.sourceforge.net>
Sent: Thursday, August 11, 2005 12:55 AM
Subject: Re: [Hardhats-members] Estimating project cost and schedule
> I would agree that it deserves a more serious response. Yes, estimating
> cost and schedule for software projects is notoriously difficult;
> however, I have been on both sides of the fence.
>
> I have had good teams which were so predictable with the estimations
> that it was very cool to watch them work; unfortunately, their managers
> undercut their estimates in order to make "time-to-market". In the end
> they ALWAYS made their initial estimations!
>
> I have had good managers which were ALWAYS good with their estimations;
> unfortunately, they were always undermined by their own team.
> Unfortunately it was the teams estimations which ended up being used and
> not the managers!
>
> All in all there are some very simple rules to follow:
> 1. Manage end-user expectations
> 2. Either project timelines OR features are written in stone, but not
both.
> 3. Have all requirements be signed off on by the end user. (IF
> developing for a specific client)
> 4. It's better to take MORE time in the design stage to get it right,
> then having to go back and re-engineer the entire product.
> 5. All aspects of the design and code have to be traced to requirements,
> if it isn't in a requirement then it's a feature creep OR you missed a
> critical requirement.
>
> I'm sure many of us reading this could go on for quite a long time on
> this list.
> So instead I'll just list a couple of books here if you're interested in
> learning more.
>
> Software Project Survival Guide (Steve McConnell, Microsoft Press)
> Rapid Development (Steve McConnell, Microsoft Press)
> How to Manage a Successful Software Project (Sanjiv Purba, Wiley)
> Manageing the Software Process (Watts S. Humphrey, Addison Wesley)
>
> Realistically in the end it comes down to what Gregory said: "There is
> no silver bullet."
>
> Likewise I have no connection with the VistA Office project.
>
> Piet van Weel
> [EMAIL PROTECTED]
> Open Source QA Developer
>
>
> Gregory Woodhouse wrote:
> > This is a topic that deserves a more serious response. Estimating
> > cost and schedule for software projects is notoriously difficult.
> > Throughout my career, I've seen various "magic bullets" that are
> > supposed to make the job easier, but none of them really work very
> > well. Quite honestly, one of the questions I dread most from my
> > manager is "How long will this take?" And quite honestly, I've really
> > never found a better guide than experience and my own (informed)
> > intuition. I think that I am reasonably good at estimating how long a
> > project will take, too, but my estimates usually are based on at
> > least an idea of how the problem will be solved, and that requires a
> > degree of understanding of the basic issues involved. It just doesn't
> > work very well to say you are producing X amount of "stuff"
> > (measured, say, in function points), and that it will take Y units of
> > effort to do it. What seems simple can be very challenging, and what
> > seems large and complex can prove to be largely routine. How do you
> > know which is which? More often than not, you don't until you are
> > well into the design phase. What can you do? Estimate risks based on
> > knowledge of the problem domain and input from developers and
> > analysts, and then try to amortize that risk over the project. (After
> > all, some things are likely to be easier than you expected, too.)
> >
> > Just to be absolutely clear: I have no connection with the VistA
> > Office project.
> >
> > ===
> > Gregory Woodhouse
> > [EMAIL PROTECTED]
> >
> > "It is foolish to answer a question that
> > you do not understand."
> > --G. Polya ("How to Solve It")
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Hardhats-members mailing list
> Hardhats-members@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
