Future of Health IT: Trends and Scenarios

Forget Everything You Know About Healthcare Information Systems | healthsystemcio.com

While continuing to poke around on the HealthSystemCIO site today (thanks to the Clinical Groupware Collaborative for the pointer, BTW), I came across a very insightful piece from Dan Morreale on the possibility that stand-alone EHRs may be obsolete.

Without a doubt, EHRs play a vital role within our traditional healthcare delivery model, characterized by independent physician practices and well-defined care delivery systems. As the pace of change has accelerated, however, we have to question how well the EHR — as a stand-alone information silo lacking longitudinal context — is able to handle the demands of coordinated delivery models. It’s time to forget and rethink the model.

via healthsystemcio.com

Essentially, the problem with existing EHRs is that they are a) hospital-centric, and b) payment-oriented.

Hospital centricity means they are targeted at the large enterprise rather than small businesses like most primary care practices and IPAs). An enterprise can impose software on their employees. A small business must have systems that their staff (especially clinicians) find useful, and most EHRs aren't especially useful to primary care providers (PCPs) in the patient encounter.

Nor were they designed to be --  I'm not roasting the EMR community for designing to the requirements of their target market. A PCP's information requirements are very different from those of the specialist or hospitalist dealing with a patient in the hospital for (in most cases) a previously diagnosed condition with a pre-existing plan of care. PCPs deal with often-nebulous complaints that may take more than one visit to pin down into a definitive diagnosis.

Moreover, care planning for the ambulatory patient, especially those with multiple serious chronic conditions, must take many more factors into account than the in-patient setting.  The patient's home- and community-based informal and paraprofessional support network must be taken into account. Those traditional EHRs that capture such information, and not all do, may nonetheless fail to provide timely access to it.

Blumenthal Suggests Different Paths to MU | healthsystemcio.com

Rather than requiring all eligible providers and hospitals fill out what is generally the same checklist for Meaningful Use, organizations which prove they are achieving outcomes far beyond the norm could qualify right off the bat, suggested National Coordinator for Healthcare IT David Blumenthal, M.D., at the October HIT Policy Committee meeting.

via healthsystemcio.com

HealthSystemCIO's Anthony Guerra posted a brief report suggesting that maybe there will be different ways to meet the Meaningful Use (MU) criteria. Or maybe different criteria, I can't quite tell from his remarks.

Just what every family practitioner needs right now -- more uncertainty about HITECH! It's not surprising that a wait-and-see approach may be the path of the vast majority in the 2011 first round of MU.

We at Cielo are hard at work on activities leading to MU certification, but we are working hardest on meeting a higher standard, Meaningful Usability.

A primary care provider may find that their newfangled IT system gets in the way of delivering quality care at the same time they are purportedly documenting it. That may be Meaningful Use by HITECH standards, but it's not Meaningful Usability. We are on track to deliver a system that improves the quality of the patient encounter in addition to documenting the improvement for HITCH and other P4P/P4R purposes.

Can crowd-sourcing help improve the quality of home- and community-based chronic care?

I've already spent too much time today blogging, and need to get back to work, but I did want to pass along an idea that struck me as I read the following in a press release on a new academic research venture at the University of Southampton in the UK:

Embryonic and relatively unsophisticated examples of current human interactions with autonomous software entities include the crowd-sourcing that provides a growing element of our traffic information, user-generated content for weather reports, and our interactions with software that can find us hotels according to our preferences.

Professor Jennings says: “We are fast approaching an ‘era of ubiquity’ where each of us will become increasingly dependent on multiple smart and proactive computers that we carry with us, access at home and at work, and that are embedded into the world around us.

“This will profoundly change the ways in which we work with computers. Rather than issuing instructions to passive machines, we will increasingly work in partnership with highly inter‐connected computational components (agents) that are able to act autonomously and intelligently.”

Professor Jennings, of the School of Electronics and Computer Science at Southampton, believes that human-agent collectives – people and computational agents operating at a global scale – offer tremendous potential and, if realised correctly, will help meet key societal challenges.

However, these benefits are mirrored by the threat of equally concerning pitfalls as we shift to become increasingly reliant on systems that interweave human and computational endeavour.

via www.ecs.soton.ac.uk

The question this raised in my mind is this: Is it possible that ubiquitous computing and crowd-sourcing could be the key to informing the informal community-based support networks of chronically ill patients on how best to provide the care and support such patients urgently need?

I'm going to try to find time to explore this thought in more depth, but can't make promises: my personal and professional lives are a bit too full at the moment to commit to this!

Cielo Clinic, Meaningful Use, and ACOs: My New Obsessions

As regular readers probably already know, I've been hiding out for several months now, getting up to speed in my new position as Chief Technology Officer at Cielo MedSolutions LLC. It's a natural next step for me, because Cielo is commercializing a University of Michigan Health System spinoff technology with which I was intimately involved in my previous position as a research informatician.

The spinoff technology was ClinfoTracker, a relatively simple and straightforward prompt and reminder system for primary care providers (PCPs). Now it has evolved into Cielo Clinic™, a clinical quality management system that can dramatically accelerate a practice's ability to participate in pay-for-performance (P4P) and pay-for-reporting (P4R) programs.  Participation in P4P/R programs translates directly into additional revenue for the practice, and it does so by facilitatinbetter quality care through delivery of evidence-based medicine in situ in the PCP-patient encounter.

There are other applications that support P4P/R participation, of course; some of these also provide alerts that are crude equivalents of Cielo Clinic's prompts and reminders. By "crude"

Cielo's compelling advantage stems from its focus on capturing and using clinical data rather than relying on billing data to drive its rules engine.  Rather than rely on ICD-9, the standard for coding problems in the US third-party payer world, Cielo Clinic employs ICPC and ENCODE, which are specifically designed for the primary care setting. Billing data has been shown to be unreliable for quality management in primary care.

Moreover, Cielo Clinic tracks clinician's response to the prompts. This ensures that, for example, if a physician has already advised a patient to undergo a colonoscopy based on a prompt driven by current clinical guidelines for colorectal cancer screening, and the patient refused, that prompt will not reappear for one year (or at a longer or shorter interval of the clinician's choosing, based on their knowledge of the patient).

We've been working on a new product that will soon become manifest in the marketplace, focused in part on the obvious buzzword of the day: Meaningful Use (MU), the benchmark the HITECH Act will use with its implications for direct patient care providers of $44K in incentives to adopt health IT.

However, we see HITECH and MU as blips on the strategic radar. The real opportunity -- and challenge -- in primary care health IT is in the development of Accountable Care Organizations (ACOs).

Lisa Bielamowicz, MD, Managing Director with the Health Care Advisory Board, the research division of The Advisory Board Company (ABC), recently posted a video entitled Keys to Success With Accountable Care Organizations on the MedPulse Business of Medicine newsletter from Medscape (free membership required to access). It's an 8-minute video that gives some good insights into how PCPs, their local hospitals, and the specialist practitioners with whom they collaborate can work together to improve patient care while reducing costs under the aegis of ACOs.

Can Open Source solve the health information integration problem?

I have a vested interest in better health informatics at the primary care level, both because I am a patient and because of my consulting relationship with Cielo Medsolutions LLC. In the current political environment, with its emphasis on throwing money at the problem, I fear for the public health. Bad health IT is worse than no health IT.

How would I define good health IT at the primary care level? I define it in terms of accuracy and completeness.  For your electronic health record (EHR) to be accurate and complete, the information in it must be up-to-date and cover all key facts about the state of your health and the care provided to you. Because many patients have multiple providers, this means that your EHR must be available to all participating care providers, both to read and to update.

Providers often use different EHR systems from disparate vendors, most of whom store data in proprietary formats, and each of whom has a fiduciary responsibility to its shareholders to resist dilution of control over the health information managed by the vendor's software. Moreover, providers belong to different HIPAA covered entities (i.e. custodians of records containing HIPAA-protected health information).

Thus the challenges in achieving a seamlessly integrated health record are daunting, spanning the technical, political, and regulatory realms. Nonetheless, their is a significant push at the Federal level with bipartisan support to achieve health information integration.

Third-party payers have already compelled a degree of standardization with respect to some of the information in the EHR, though the information they need for efficient claims processing is only a subset of what is needed from the care provider perspective. Adequate or no, at least it's a start.

In addition to the provider and vendor challenges, both because providers can make data entry errors and because the patient does not always take the provider's advice, the record must also be available to the patient to read and update. This latter problem is a matter of providing a patient portal to the integrated EHR shared by the providers, and while it presents its challenges, this is an easier problem to solve than getting to the integrated EHR in the first place.

Solving the political challenges, both inter-vendor and at the governmental level, is outside my scope. I do, however, have some insights into the technical challenges to health information integration, in particular the syntactic and semantic obstacles that must be overcome.

Getting information out of proprietary systems is essential to making it available for integration, and there do exist commercial entities who specialize in "cracking" proprietary schemas. Recently, though, I learned of the existence of an Open Source initiative in this arena, which brings me to the interview linked below from opensource.com. In it, Jason Hibbets of Red Hat interviews Matt Mattox of Axial Exchange, a company that provides an Open Source data interchange appliance and sells services related thereto.

I'll provide a taste from the interview, and leave you to read it (or not) without further commentary on my part. I'm still investigating them so I can't provide an opinion of any sort with respect to Axial, but I do have to say I find their business concept highly intriguing.

When you take a system where suppliers create their own demand--which is what happens when physicians both diagnose and treat illness--and combine it with model where a third party picks up most of the fees, costs can rise quickly.

In terms of the care model, the physician practice and acute care hospital were designed in the early 1900s. Medical knowledge has evolved dramatically since then. Today, there are relatively inexpensive ways to treat conditions that a century ago were understood only by their symptoms. We have an opportunity to re-organize our institutions around the state of the science.

These changes won't happen overnight. The first step is to extract data from locked-down proprietary systems so that health information can be made available to the appropriate people at the appropriate times. Once the data has been freed, we can begin to innovate around new care and payment models. Freeing clinical data is the problem we're working on at Axial.

via opensource.com

The Cost of Fear | Why Docs Don't Embrace Technology (Dr. Rob)

I recently read a post on Dr. Rob's Musings of a Distractibel Mind blog on the barriers to adoption among primary care providers and their consultants. I found it very insightful. It opens with a description of an interaction between Dr. Rob and a consultant, in which he offers to exchange information via email and met with silence followed by a polite refusal. He goes on:

This is a typical reaction I get from my colleagues when suggest using the new-fangled communication tool called email.  The palms sweat, the speech stumbles, and the awkwardness is thick in the air.  It’s as if I am suggesting they join me in an evil conspiracy, or as if I am asking them to join my technology nerd cult.  There is a culture of fear in our healthcare system; it’s a wall against change, a current of stubbornness, a root of suspicion that looks at anything from the outside as a danger.  Instead of embracing technology, doctors see it as a tool in the hands of others intent on controlling them.  They see it as a collar on their neck that they only wear because others are stronger than them.

via distractible.org

Email, Fax, and HIPAA

Comments on the blog suggested that the objections might be based in part on security concerns. The consultant may prefer fax over email as a better way to protect patient privacy.

Sadly, many folks think that faxes are somehow encrypted and therefore secure, but they are not. Their advantage over email in this respect is that faxes contain image data, which would be harder to mine for useful information than the plain text of most email. Transmitting HIPAA PHI in either is a violation of the HIPAA Security and Privacy Rules.

There are ways of encrypting both fax and email transmissions. The former requires a commercial product of some sort, the latter either a commercial solution or arcane and cumbersome freeware technologies.

It seems like a better approach would be a shared system that uses HTTPS for all communication. GMail can do this, and HTTPS is now GMail's default transport layer for its user interface, but whether or not communication with any remote mail system is secure is situation-dependent and opaque to the sender and receiver. It is unclear whether the GMail databases are HIPAA Security compliant. Our Health System uses Groupwise for internal communications, which is encrypted both in transport and storage, with all storage maintained inside the data centers and behind the firewalls of the covered entity.

PHR systems like Google Health and Microsoft HealthVault offer another alternative. In both cases the information is "owned" by the patient, who must grant access explicitly to others; all inter-system communication over public channels is encrypted. DOD's MiCARE system (http://bit.ly/dlz2iW) interfaces with both PHRs, providing relatively painless and secure sharing of health information between and among primary, secondary, and tertiary care providers, consulting clinicians, and non-clinical care providers. The only catch is that the patient must trust the MiCARE system to identify, authenticate and authorize external systems that need to read from or write to the PHR.

Whether Google Health and HealthVault are truly secure is an open question. I have found no explicit assertion from either that their back-end databases are encrypted, though both employ extensive physical and administrative controls at their data centers. Not providing any details of their technical controls (e.g. encryption of databases) is probably wise, since any information at all would be potentially useful to hackers. Still, an assertion that the back-end database are encrypted would be appreciated by patients and by liability-sensitive providers accessing their systems.

The Real Issue

All that said, the most substantive objections to the use of email in the minds of healthcare providers are probably social and psychological rather than legal or technical. Use of email may be perceived as a slippery slope to being lured or compelled into more extensive IT adoption. Primary care physicians in particular are late adopters of technology, and with the lack of emphasis on usability in many systems currently available, it is difficult to blame them for their reluctance in this regard.

I recently sat through a vituperative diatribe from a family physician whose employer adopted one of the major EMR provider's systems over a year ago, and she stated that the system actively interfered with her ability to provide care. Her objections were multiple, but most prominent were twofold.

First, the system demanded excessive navigation due to inflexible and poorly designed user experience design and information architecture, leading to severe reduction of direct contact with the patient and broken concentration. Second, the system overwhelmed her with prompts and reminders she had long since determined were irrelevant for a given patient. The system provided no way to suppress them, which she was told was due to liability issues.

Another physician I overheard in the YMCA locker room was lamenting the fact that computerization had led to a requirement that he spend more than half of what had previously been his lamentably small amount of free time on nights and weekends updating the EMR. This was in his view better than attempting to use the EMR system in situ.

I know there are many success stories in primary care EMR adoption. Dr. Rob is one of them, and I personally know of a number of others, including my own family physician. The Federal initiative to computerize primary care is laudable, even though the road ahead will be rocky for some time to come.

Hopefully the systems that end up dominating the primary care EMR marketplace will succeed based on usability, quality, and workflow flexibility rather than on company name. The enterprise-system vendor offerings in the primary care arena tend to be dumbed-down, check-the-box knockoffs whose designers seem oblivious to the unique and highly variable requirements of primary care clinics and practices. Which vendor(s) will succeed, and on what basis, and with what ultimate effect on the public health, only time will tell.

Personal Tech: Medical Apps for the iPhone

From NY Times Personal Tech: Medical Apps for the iPhone

After a lot of time reading "best medical apps" stories online, asking Twitter users for their suggestions and reading online reviews, I finally boiled the list down to about 50 promising apps. I tried them out and further winnowed the list to a bunch that I ultimately demo'ed in my talk. Eventually, the video of the talk will be posted at ted.com/talks, but in the meantime, here's what I covered.

(I haven't really given them full-blown testing, so read the online reviews before you spend good money on them. Except for the free ones--you've got nothing to lose!)
--Dave Pogue

I read David Pogue's personal tech blog at the NY Times to keep up on consumer IT trends, but this post from a couple weeks ago seemed really relevant to the readers of FutureHIT. I've been putting off posting because I wanted to say something eloquent, but work and home life have made that impossible. I'll settle for a few hints at what I believe are the most interesting among the items Pogue lists. I'm focused on the ones targeted at health professionals, but the consumer tools have a lot of potential as well.

• OsiriX. "An amazing viewer of medical images (X-rays, scans of all sort)".  I think this is probably just a DICOM viewer, but it requires special server software, so it may be adding some value. Regardless, it's very cool.
• AirStrip OB. "Lets an obstetrician monitor a patient’s status, right down to the baby’s heartbeat, from elsewhere in the hospital (or the town)."  As Pogue points out, this is a good pointer at the types of remote monitoring applications we can expect to see as ubiquitous/pervasive computing moves into the mainstream.

Actually I will mention a thought I've had about one of the consumer apps...

• Retina. "It’s for color-blind people like me. You hold it in front of something—clothes in your closet, for example—and it tells you by name what color you’re seeing."  This is an examplary augmented reality application, intriguing not so much for what it does -- which is of great value, I don't mean to denigrate it -- but for what it portends.  As image analysis becomes more sophisticated, it's easy to picture diagnostic tools that will look at the patient in visible light and infrared and point out diagnostic signs the clinician might overlook. A more prosaic application not yet built but within the reach of current technology would be a program that "looks" at the patient and points out relevant facts and decision guidelines based on the part of the patient's body on which the phone's camera is focused.

I think all this is intimately related to the technology I spotlighted in my recent post on the Open Data Kit, which is aimed at moving advanced tech for the clinician into community settings. As I said in that post, these types of tools will serve the developed world as well as the developing world, because even in the most advanced economies there are segments of the population that are underserved because they can't or won't go to a traditional healthcare provider setting.

There are challenges in all this that take some of the rosy glow out of the picture, notably patient privacy and truth maintenance, i.e. making sure the various information stores relied on by the remote devices have the most up to date information, and can update it as well. In addition there is the very real concern I feel as a patient that healthcare providers may become overly dependent on distributed computing and communications technologies, and be at a loss when connections break down (and they will, oh yes, they will).

Nonetheless, on balance the future for these technologies is bright and getting brighter, and the value they add is potentially enormous.

Agile Methodology and the Conversational Meta-Methodology: Part two

In my earlier post, I expressed some reservations about Agile methodology (or possibly, about misapplications thereof, I'm open to persuasion).  I introduced the Conversational Meta-Methodology as an antidote to the problems cited in that post. My rant continues here with a different problem I'm seeing very clearly in my current project.

I'll repeat an important clarification from the earlier post briefly: my current project doesn't appear to be failing at all, in fact I think it will result in a kick-ass product, and the part of the product that will be of greatest ultimate import is the component where the Agile approach (and the Conversational Meta-Methodology) have been followed most religiously.  The problem I'm describing here is one that, if it were overcome, would have resulted in "kicking it up another notch", as Emeril would say.

In twenty-five years of commercial and enterprise product development, I have worked on many systems that can be viewed as distributed data repositories, or more generally, distributed resource frameworks that may encapsulate both data and behavior. Application of best-practices software engineering principles leads to a more-or-less standard architecture for such systems, in effect a high-level architectural design pattern.  It consists of the following components:

• A query front-end, in which the end user (human or machine) expresses queries in some abstract query language, and receives results rendered in some desired output data structure. 
• A controller, responsible for partitioning the work to be done, dispatching subqueries to remote data sources (workers) in parallel, monitoring their progress and reporting progress to the front-end, aggregating results received from the remote nodes in some standard format, performing aggregate transformations on the composite result set, rendering the aggregate results into the desired output form, and returning the results to the front-end. The controller also provides graceful degradation in the event of exceptional occurrences, such as a remote node being unavailable or receipt of a malformed query.
  Another common but by no means universal function of the controller is to provide a master entity index, to identify real-world entities represented in multiple remote data stores and provide a common unique identifier for such entities.
• Remote end-point adapters that can map the abstract subquery it receives onto the local data store(s), retrieve data, and translate as needed into the standard format employed by the controller. The adapters can provide a wide variety of additional functions, such as deidentification, performing local aggregate functions on their result set, or running procedural code that processes or even generates local data.

DBMS developers, database architects (DBAs) and others will recognize how this pattern describes the internal structure of an enterprise DBMS. The remote data stores in the above description may be different schemas in the same database, different database instances, or simply ad hoc algorithms that can be delegated to worker threads in order to parallelize query execution on a single local data store.  The abstract query language is SQL if the database is relational, and the aggregate operations are stats functions, grouping, sorting, and so on. The adapters may do sorting and the controller does a merge of sorted results. It's all pretty familiar stuff.

Here's a diagram that shows how this applies to the architecture of a DBMS. There are a lot of variations on this theme, but the picture holds for the DBMS I have worked with over the years. Click on the picture to open full-size in a new tab or window.

In a DBMS, the subplans are queries against various data storage resources -- tables, indices, and so on -- as specified in the retrieval aspect of the overall execution plan. "Develop execution plans" covers a lot of ground, since this is where rocket-science algorithms like cost-based optimization are applied.  Of course this diagram only looks at the query side of a DBMS (the "U" in "CRUD"), but the picture is not overly different for updates and deletes, or even for DDL operations that affect the metadata (aka data dictionary tables in a DBMS).  The "Group and order" and "Perform aggregate transformations" boxes are often interdependent and may occur in a different order than shown here, depending on the transformation plan. Nonetheless, I would maintain this is a reasonable high-level view of DBMS architecture, and it conforms well to the pattern described above.

To make it more specific to this blog's readership, the diagram below shows a healthcare-specific instance of the pattern (click to open full-size in a new window). What makes it healthcare-specific is the Honest Broker with its Master Patient Index for HIPAA compliance. The ontology mentioned in the diagram represents the problem domain for the purpose of formulating abstract queries and structuring results, and therefore is a lot like a cross-enterprise data dictionary, a syntactic data model. If it is a true ontology, though, it overlays semantics on the syntactic structure and can be used for reasoning activities.

Driven to Distraction - At 60 M.P.H., Office Work Is a High-Risk Job - Series - NYTimes.com

On Wednesday, the Transportation secretary, Ray LaHood, called the broader phenomenon of distracted driving a “deadly epidemic” at a meeting on the issue in Washington. Real estate brokers, pharmaceutical sales people, entrepreneurs, marketers and others say they have little choice but to transform their cars into cubicles. In this merciless economy, they say, they have to make every minute count, and respond instantly to opportunities and challenges.

And they argue that the convenience of constant contact — and the chance to tick off items from an endless to-do list while driving — far outweigh what they think are slim chances that it could lead to a wreck.

via www.nytimes.com

The NY Times has been running a series on the perils of multi-tasking while driving. Today's installment highlights how work pressures, often self-imposed in the case of knowledge workers, are causing people to kill themselves as well as innocent bystanders through stupid mistakes made while trying to be on the telephone, send email, and drive all at the same time (or similar combinations of ICT activities).

It may be that in our culture, this pattern of behavior is Darwinian natural selection at work, though the loss of innocent bystanders doesn't quite fit the pattern. It does represent a continuation of the obliviousness we feel with respect to the dangers of multitasking. In addition to this kind of life-threatening danger, there are less obvious but more pervasive effects. In a paper published earlier this year in PNAS Early Edition, "Cognitive control in media multitaskers", Ophir and colleagues described a controlled behavioral trial in which they showed that media multitasking degrades personal productivity and effectiveness:

A trait media multitasking index was developed to identify groups of heavy and light media multitaskers. These two groups were then compared along established cognitive control dimensions. Results showed that heavy media multitaskers are more susceptible to interference from irrelevant environmental stimuli and from irrelevant representations in memory. This led to the surprising result that heavy media multitaskers performed worse on a test of task-switching ability, likely due to reduced ability to filter out interference from the irrelevant task set.

In all likelihood, many of us in the knowledge business will be as oblivious to this evidence as we have been to the numerous past studies of the dangers of using cell phones while driving. Sad, but true, I fear.

Agile Methodology and the Conversational Meta-Methodology: Part one

I'm involved in a project that uses an online Agile project management system. It's not a big project in terms of number of participants, but the personnel are distributed across four institutions in three different states, none closer than a hundred miles to any of the others. When it becomes manifest, it will be a major achievement in the world of biomedical research, and it may result in technologies with commercial potential, even though they will be delivered under an Open Source license.

As stated in the opening sentence, the project employs the Agile approach. It's the first time I've worked on a project branded as Agile. I'm capitalizing the word to distinguish it from the adjective "agile", because the methodology may be Agile, but that does not guarantee Agile projects are agile in practice.

---

I should say up front, in case any reader knows the project of which I'm speaking (and I'm sure some will), the project is moving along nicely. It has its ups and downs as with any project, but it is on track to be successful.

My critique here is directed at how the Agile approach as we are practicing it is getting in the way of the project approaching its full potential, which potential is well beyond the contractual scope as originally defined. The limitations I'm describing here could easily cause a different project to fail, but that isn't happening on my project. I'm happy with it, but I could be happier.

---

The problems I'm seeing with the Agile approach may relate to subtle misapplications of the Agile approach in projects involving distributed teams, and I suspect these are widespread in the industry. These problems stem from tacit cultural biases and preferences.

I say 'misapplications' because people I respect and admire are ardent Agile enthusiasts: for example, long-time friend and colleague from my commercial product development days, Rich Sheridan of Menlo Innovations. If Rich says it works for projects like mine, and he does, I know I have some learning to do. I'm still at odds with his viewpoint at present, but I know I'll probably be convinced.

An example of the kind of tacit cultural bias to which I'm referring is the tendency of software engineers to want someone else to talk to the end user. This is not at all due to laziness or indifference. Often shy and introspective by nature, most productive when left alone in silence, software designers and programmers often believe that the process works best when there is someone who can tell them what needs to be done, and then leave them alone to do it. There are often organizational policies that proscribe developer conversations with end users, and these factor into the equation as well.

This in turn is related to a more pervasive cultural bias, the assumption that intellectual constructs like the requirements or design for a product can have persistent, stable existence independent of the minds of the stakeholders (most importantly, the customers, sponsors, and implementers).If they did have that sort of stability, requirements could be written down and "thrown over the wall" as the saying goes.

Some projects must force this level of stability, for systems engineering reasons -- the software for the NASA Shuttle is an example -- but for most projects, requirements are fluid and dynamic, and worse, are never the same from one stakeholder's mind to another even at any specific point in time. Moreover, this fluidity is not limited to requirements analysis: the same can be said for detailed product design.

I'm not against creating requirements and design artifacts, whether in Agile user stories, in IEEE-standard formal documents, or UML models, as long as everyone who matters in the process understands that the documented version is always incomplete, always wrong, and never incomplete or wrong in the same way twice, i.e. at any two points in time during the life of the project.

In project management, the saying goes, Plans are nothing, but planning is everything"; I would paraphrase that here as "Requirements documents are nothing, but the requirements analysis process is everything."

To see the fallacy in the assumption of stable, documentable requirements, recall the cliched party game "Telephone". One person starts with a somewhat lengthy and usually gossipy anecdote, and whispers it into the next person's ear. That person whispers it into the next person's ear, and it proceeds in this sub-rosa serial fashion until the story has been told to everyone at the party. At the end, the last person recites out loud what the story has become in the series of translations, usually to the merriment of all present.

The telephone game metaphor in software development produces something like the ubiquitous "What the Customer Wanted" cartoons, an example of which is shown here, stolen from Allan Jardine's blog (click to open full-size in a new window):

 

The lesson of the Telephone game is that communication often happens without comprehension. When done well, projects using the Agile approach should be characterized by lots of communication.It is the ongoing conversation, not the artifacts, that ensure a successful project.

For that reason, when I listen to any software development methodology, I look for the points where meaningful conversations will occur. A 'meaningful conversation' in this context is a timely and thorough conversation about product and process that builds and continually refreshes a shared mental model of the vision, mission, and goals of the project -- a mental model that all participants acknowledge will evolve over time.

If these conversations occur throughout, involve all relevant stakeholders at their points of occurrence, and form the real basis for the collaborative work, the methodology will result in a successful project, barring the occurrence of any of the political, financial, and other disasters that can kill even the most promising efforts.

Rich Sheridan agrees with my premise that we were doing Agile development back in 1986 -- in fact, all the successful commercial projects we knew about used some methodology that would fit into the Agile paradigm. What we lacked was a trademarked brand wrapped around a coherent description of some incarnation of our "methodology". Rich learned that lesson well, and his group has registered a trademark for the term High-Tech Anthropology®. Menlo peddles a methodology, to put it crassly, but it's no con game -- what they teach you is eminently workable in practice, and I highly recommend their services.

That said, I think Rich would agree that their flavor of the Agile approach works as well as it does because it is an incarnation of what I will now name the Conversational Meta-Methodology, rather than as a result of any rote technique that they teach you. In fact, one of the things they will teach you is that all the rote techniques are intended to do is to work toward a shared mental model of the project as it evolves over time. It's the process, not the artifacts, that are the key to success.

To disclose my personal interest in this matter, I wrote a book back in 2002-2003 called Design Conversations: Envisioning Content-Rich Enterprise Systems. It's as much about requirements analysis as it is about design. I've gotten great feedback from many of the several dozen people who have read it (including a few who downloaded it to their Kindles), but it hasn't started a movement. Maybe it's time to trademark the Conversational Meta-Methodology^TM, write a manifesto, work up some curricula and a YouTube video or three, and found an institute of my own. :-)

I'll come back to this in a soon-to-be-written post and show how it relates to my current project.