Arden, we collaborate with Regenstrief quite a bit, because we are affiliated with them.
And "yes" I have much interest in the "adapt-for-adoption" activities associated with VOE. Frankly, my prediction is a slightly different pace of adoption than some of the hype here (and other places) suggests. But as adaptation happens, and the product is made more mainstream, and best of breed add-ons are added, and support solidifies, things should become clearer. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Forrey Sent: Thursday, August 11, 2005 10:03 AM To: hardhats Subject: RE: [Hardhats-members] Estimating project cost and schedule Rich: Your comments hit the nail on the head and indicate how the VistA Community MUST organize if it is to truly succeed. The essentail overll perspective is Enterprise View Life Cycle Principles. THe MDC was set up to articulate the overall Life Cycle Principles into M environment realted language -that needs to be pursued and will tie togther your experience in the NUclear engineering with the healthcare community. You other key point is that the healthcare professions have a different current view of the Conceptual Content for the Enterprise View and Richard Davis has commented on an appropriate approach. A concurrent step is to dvelop close relationships with the Health informatics education to show how the Conceptual Content is linked with the implementation engineering using LIfe Cycle Principles to yield as useful product in a similar fashion to nuclear engineering and for the same reasons. That Hardahts possess the insight and talent to put together the structure to do this even though healthcare IS more complex. There are VistA adaptation projects in Indianapolis. One aspect is the various ways to use the LOINC vovabulary in support of care modalities not yet well covered by the VA. Regenstrief is just down the street; have you had any discussions with them about various uses of the LOINC vocabulary within modules of VistA other that for the names of lab tests which many still order like a box of soap from the supermarket having no other cognitive function. You may also have in-VA perspectives on this same subject that will be valuable to VistA adapt-for-adoption activities. A related question relates to the broader issue of Terminology Management for VistA architectures that all adopters will need to address. We look forward to your comments. On Thu, 11 Aug 2005 [EMAIL PROTECTED] wrote: > Steve, I must say my experience mirrors yours at least in the medical > software business. I think the domain of medicine is so broad, and so > complex, and still so reliant on the skills and knowledge of clinicians, > that it remains very non-deterministic, and will always be that way. > > Plus, medicine changes rapidly. I was thinking the other day, about many > people in my parent's generation who might have benefited by taking statins. > > Developers are usually computer scientists or engineers, not clinicians. So > there is an obvious "expertise" gap between them, which impedes > communication. > > I know a Doctor who has a degree in computer science. He went to medical > school just to learn the domain of medicine so that he could write software > for medical applications. > > This is an extreme case of learning the domain you are writing for, but a > good educational path if you're up for it. It certainly benefited him. > > When I worked designing software for the nuclear industry, it was different. > Mechanical, electrical, and nuclear engineers specified how the software was > to work, based on well-defined mathematical equations and known quantities. > > We talked the same language. > > Paradoxically, it was a much simpler domain than medicine. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of smcphelan > Sent: Thursday, August 11, 2005 7:01 AM > To: hardhats-members@lists.sourceforge.net > Subject: Re: [Hardhats-members] Estimating project cost and schedule > > 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 > > > ------------------------------------------------------- > 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
