"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."
To piggy back on what Ted says here, I have done at least 100 projects
for major corporations. They were all very specific and very targeted
in scope and all very successful. Many of them ran up to or over 20
years. These projects were ordered and managed by transportation people
and the applications worked with data from on board computers. IBM
tried to do the same thing with some of these companies and failed
because of their large scale approach.
On 5/29/2014 12:25 PM, Ted Roche wrote:
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/[email protected]
** 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.
