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