All of this was very well documented in the Chaos Report. If
interested, check out
http://dimsboiv.uqac.ca/~sboivin/C2005/8INF814_Ete05/raw/CHAOS_1994.pdf.
smcphelan <[EMAIL PROTECTED]> wrote on 08/11/2005, 02:01:22 PM:
> 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"
> To:
> 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
-------------------------------------------------------
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
