It seems there's two kinds of developers: those who think they can whip it up in an afternoon (optimists) and those who are sure it's yet another government boondoggle, sure to suffocate in its own red tape (pessimists). Neither strategy seems to have a long track record of success :) And I should know, since I've been burned in both camps. Caution is a good trait in consultants and developers; pessimism perhaps less so. Realism is the hardest thing to find in our industry.
Ken: yes, the project seems interesting, and yes, I'd be skittish about state agency funded or non-profit managed projects: both sometimes have motivations at odds to the successful completion of projects. These are risks to manage, as Dave somewhat frankly pointed out :) I would be concerned about state agency acceptance criteria (there are state regs, in many states), payments, and project structure: a fixed bid demands a fixed specification, a fixed specification often means you get what you ask for, but not what you need. (I once sat in on a RFP pre-conference, with reps from The Big Five consulting firms plus IBM and HP. Despite the small scope of the project, it was clear this would be a big budget item.) So the three concerns are: business aspects, project structure and technical feasibility. All three are different axes of the venture, and any one of the three can be a show-stopper. Mini-projects, with small, carefully-defined goals, can succeed better than grand plans. They're not only under the radar of bigger projects; they give client and dev teams natural points at which the project can be redirected, teams can be swapped out, and schedules adjusted. Examples: 1) Develop a paper-only specification of front end, back end, processes, import/export formats, sample reports. Estimate the scope and budget of step #2. 2) Develop a pilot web project to demonstrate the feasibility and usefulness of the main app. Estimate the scope and budget of step #3. 3) Scale the pilot project to a medium-sized county, fixing issues found and identifying additional requirements that emerge. Yeah, estimate the scope and budget of step #4 & 5. 4) Determine the costs to go into production: 24x7 monitoring, hot sites, backups, disaster recovery, archiving, etc. 5) Rebuild the pilot project into the production version. How hard could that be? If possible, you'd like to introduce as many aspects of Agile project management into the mix as possible. The abysmal failure rate cited in many studies is, to my mind, a fault of poorly thought-out, poorly-designed, or poorly funded projects which could be success if proper focus, money and time were applied. "The journey of a thousand miles begins with the ground beneath your feet" also can mean that if the first step's a misstep, you're off on the wrong path. The fixed-bid, fixed-spec format is the equivalent of asking for a moonshot: hit another body traveling at an unknown variable speed at a huge distance for the smallest amount of money imaginable, with one try. When "Failure is not an option" that means it is inevitable. Breaking up a big job into a bunch of smaller, somewhat-independent tasks means that revisions and changes are part of the project, not trying to re-route a waterfall mid-drop. My two cents, a couple of times over. On Thu, May 29, 2014 at 1:42 PM, Ken Dibble <[email protected]> wrote: > Thanks everybody for your enlightening comments so far. > > Boy..a lot of traumatized people out there! > > Remember, this is not a "specification", it's a "feeler". A clear > specification certainly would be issued before anyone is asked to bid. > > Perhaps a bit of background would help: > > Currently the state's developmental disabilities service agency has a very > big, very complicated web-based document-management/workflow system called > CHOICES. It is based on some MS proprietary web application development > software whose name I can't recall right now. It was developed about four > years ago and its use is mandatory for thousands of people working under > contracts with this state agency. It only works in IE versions 7, 8, and 9. > It doesn't work in the two most recent versions of IE. It doesn't work in > any other browser. MS promised some pointy-headed IT guy that the system > would be "updated" to work with other browsers but it never was. The > underlying MS software itself is not even being updated in a timely > fashion, BY MS, to work with its most recent platforms. And the agency > itself has no budget to keep the application updated. > > The system I'm talking about is not anywhere nearly as complicated as this > example, nor will it require anything like the amount of data storage or > user concurrency as this system. The CHOICES system is an example of what > can happen when somebody depends on a big proprietary software house for > stuff that needs to be kept current. > > "Commercial solution" providers lie. They make promises they have no > intention of keeping. So yeah, if the developer who builds it can't be > bothered to keep it updated in a timely fashion for a reasonable fee, you > bet your ass we would want to be able to find another developer to do that. > > And yes, there might not be money for updating at some point. In which > case, no updates would be expected. What's the problem? > > Now, for the system I'm describing. > > It's a data warehouse for querying and generating reports. Data uploaded > to it will contain no personal identifying information, just surrogate > primary keys to keep the records separate. Therefore it has NO HIPAA > compliance requirements. I have researched HIPAA extensively; I do it all > the time. There's a big difference between what CYA lawyers, and paranoid > IT Department heads, think HIPAA "requires" and what it actually does > require. > > Uploads would be via CSV or perhaps XML files. Not hourly, daily, or > weekly. Perhaps quarterly. Perhaps, at most, monthly. > > This is not a "medical" application. The data to be stored consists mostly > of demographic stuff that changes over time, and very simple dated service > "events". > > It's not a real-time end-user data-entry system. It's designed purely to > accept periodic bulk uploads and enable queries on the data it stores. > Number of sites uploading would never reach 100. Number of people who need > to query the data would never exceed 200. Very little of this access is > likely to be concurrent. > > Again, a state agency would purchase this. It is not going to be resold. > > The flexibility thing: For example, we want to be able to report on the > disabilities of the people served. Suppose today we have a list of 20 > disabilities: arthritis, spinal cord injury, diabetes, brain injury...etc. > Now next week the state agency adds five more disabilities to the list. The > system needs to be able to accommodate that sort of thing as a > "configuration" issue, not as a hard-coded feature of the interface or the > back end. There could be various sets of other specific data points in the > categories of, for example, income ranges, or race/ethnicity categories, or > education or employment levels. I already do this sort of thing all the > time with my main system. It's not very hard, but it does require > forethought. > > The system needs a flexible query system in order to cross tab any number > of demographic data points with each other or with service data. Also stuff > we've all done, also requiring forethought. > > It will also need some minimum number of hard-coded reports, and more > would need to be added over time, for a fee. > > That's all. No secret hidden agenda to rip off hard-working developers > here. > > Do you people make a lot of money by distrusting and bad-mouthing > potential customers when they come to you with ideas?? > > Jeez people, take a breath. :) > > Ken Dibble > www.stic-cil.org > > > > > > > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cacw6n4ua_nq6qe5d0mgmzxyisxvle2ve_cg64y3tcvgork1...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
