LMS and 1,500 Courseware Adaptations Ain't Cheap - #elearning

In a DoDNews release from last week appeared this announcement:

IBM Corp., Fairfax, Va., was awarded in Sept. 17, 2009 a $20,634,771 firm-fixed-price contract. This project is for post deployment system support for the Army Learning Management System day-to-day labor for operations and systems enhancements for a one year period Sept. 21, 2009 through Sept. 20, 2010. This includes courseware migration of 1,500 existing courses. Work is to be performed in Fairfax, Va., with an estimated completion date of Sept. 20, 2010. One bid solicited with one bid received. Mission Installation and Contracting Command Center, Fort Eustis, Va., is the contracting activity (DAAB15-01-A-1013).

I accept that 1,500 courses is a lot. Some -- possibly a lot -- of the cost is operational -- server capacity, licenses, communications and training -- though the announcement does specify "post-deployment." I accept that the conversions could be gnarly, with lots of structuring and graphics and standardization and who knows what else. But it's a reminder of how critical it is to have content authored for online learning in the first place -- at least in some basic ways. One must presume from the size of this award that there is little occasion for reuse, and that there's a lack of readily available conversion tooling. (Enter the knowledge engineer). But does "migration" imply that perhaps some or all of the content was already in a close-to-suitable format? Unclear.

The better question is, will the next 1,500 courses also cost $20M?

p.s. Assuming that this is the Army's system cited in this contract award, and that the portal is part of their responsibility, I assume that IBM's contracted-for QC hasn't started, as there's a typo in the Army's landing page.

◦

LMS and 1,500 Courseware Adaptations Ain't Cheap - #elearning

Emerging Knowledge Work: Patient Advocacy

Most baby boomers, especially those with surviving parents, were nodding solemnly if they read the NYT story, "After a Diagnosis, Someone to Help Point the Way." The story offered several anecdotes describing the assistance offered by patient advocates. The story's author, Lesley Alderman, like most other journalists, depicts the role played by patient advocates as an extension of the U.S. health care system, perhaps in the same league as home health paraprofessionals.

This characterization is not necessarily incorrect, though patient advocates are unofficial extensions of health networks. Presumably they're generally not referred directly by providers, and have an uncertain and ill-defined status in the health services sector. Further, there's an assumption, borne out by ad copy on some health advocacy websites, that a primary purpose for patient advocacy is to ensure expeditious and fair treatment of insurance claims. This function is valuable, but represents a business rather than a health care source of support.

A broader interpretation, one favored by knowledge engineers, sees the patient advocate at least in part as a knowledge worker. The patient advocate's knowledge of the health care system is the role's key asset. That body of knowledge is a moving target, steadily increasing in depth and challenges.

Consider just a few of the issues touched upon by a patient advocate:

• Risk management
  
• Cost-benefit analysis
  
• Federal Government workflow (e.g., Medicare)
• State Government workflow (e.g., Medicaid)
  
• Multiple providers with possibly unshared medical records
  
• Lack of access to automated processes
• Potential lack of consensus on recommended treatment plans
• Potential lack of consensus between family members
  
• Lack of direct access to drug interaction detection software
  
• Privacy considerations
• Need to rely upon
  
• Expertise in specific disease treatment plans (e.g., diabetes, hypertension)
• Differences between provider facilities -- e.g., inpatient vs. outpatient
• Advocate may be introduced late into the mix after many issues and decisions are already in play
• Knowledgeable use of web-based forums, information sites
• Ability to train patients and family members in the proper use of web-based information assets, even when some information provided there may be unreliable or confusing
• Risk disturbing patient-provider-payor relationships while acting as expeditor-facilitator
  

And that's just a start.

The challenges are numerous, but the demand for quality patient advocacy may one day be keen among those who both recognize the value of the service and can afford it.

Photo Credit: Markus Hanser

◦

Emerging Knowledge Work: Patient Advocacy

Software Architecture vs. Domain Complexity: Overstated Claims

The folks at SEI know something about software architecture. It's not surprising that their Saturn Network voice opines -- or rather, bemoans -- that poor software architecture adds to complexity and a host of related problems -- especially maintainability. Anyone who's taken over a software project of any magnitude can attest to how a different or better architecture could have been improved to simplify the transition to a new team.

Hindsight is 20/20. Yes, projects morph and grow in ungainly, unplanned ways. Sometimes they are wrongly planned, which is SEI's point.

But something is missing. What is left out of this scene is the unacknowledged complexity of the subject matter being automated. Today's ERP, air traffic control, or web analytics application has complexity that increases at least as steadily as the resources used to automate those processes. Not mentioning domain complexity while discussing software complexity is a troubling omission. The omission is important because it goes to the heart of the sort of competencies needed to architect software systems. There is an unstated assumption that this should be the purview of software engineers, but an equally compelling case could be made that software engineers are less likely to grasp the subtle ontologies of systems brought on line to solve new problems.

A complete vision of the domain's model is unlikely to become clear until too late in the design process. Grasp of central use cases and critical requirements is likely to elude all but the rare software specialist who is also familiar with the domain being automated. Domain Specific Languages are part of the answer, but they too may be too late in the game.

◦

Software Architecture vs. Domain Complexity: Overstated Claims