Flexibility – or rather the opposite – is a perennial problem in human service information systems. Whether deploying a commercial off-the-shelf (COTS) package or building in-house, project teams frequently run into situations where the system cannot cost-effectively be modified to satisfy stakeholders’ needs. In extreme cases, the gap between desire and possibility can cause a project to be cancelled. More commonly, the consequences play out slowly and painfully over years: the human services agency accepts the system’s limitations and the frustrated stakeholders develop manual workarounds or sponsor parallel silos or simply do without. Of course, the software’s inflexibility, which was too costly to remedy, is still costly – but the agency incurs the expense through reduced effectiveness and efficiency.Though widely acknowledged when it creates misery, up until now inflexibility has not been a problem that the software industry and human services agencies have dissected in great detail or discussed very publicly. So it is encouraging that flexibility surfaced last November as one of the three critical factors for success cited by a white paper from the American Public Human Services Association (APHSA) and Microsoft. The report, “Achieving Maximum Value from HHS IT Systems,” summarized the results of a survey of human service information technology leaders at the state level. Respondents emphasized that “it is no longer reasonable to expect that the technology a state deploys will remain static”1 and recommended that agencies implement effective change management, choose flexible platforms, and ensure that appropriate resources are available. Microsoft, in turn, advocated for agencies to deploy new breeds of technology solutions that can be easily modified, particularly service-oriented architecture (SOA) frameworks that are amenable to being developed and enhanced incrementally over time.
So far so good – these are eminently reasonable suggestions. But there is much more ground to be covered. If every human service information system that fails because of inflexibility were followed by a clear-eyed postmortem, a whole host of far-flung causes would be implicated. Procurement practices, project management approaches, analysis and design methodologies and architectural decisions can all contribute for good or ill. Achieving highly flexible information systems, therefore, will only be possible if technology leaders can home in on the causes of inflexibility wherever they may lie. The key is to lift up the issue of flexibility and face it proactively throughout the project.
Here are five practical ways to do that:
- Procure flexibility, not just functionality. Procurement documents set the stage for everything that will come later, so it is critically important that they emphasize flexibility. A request for information (RFI) or request for proposal (RFP) is an opportunity to evaluate vendors’ thinking and capacity. As far as possible, an RFI or RFP should specifically list the areas in which the eventual information system will need to be easily modifiable. It should ask vendors to describe how they would achieve flexibility, referring both to project management methodology and, if the vendor already has an off-the-shelf product, to its specific architectural features. Listing the areas that must be easily modifiable can be challenging, though, if agency staff are only familiar with their requirements here and now. In that situation, it makes sense to seek independent outside expertise about how that particular kind of human service program varies from place to place and how it may need to change over time.
- Create scenarios to examine the cost of modifications. Vendors and system designers frequently market their solutions as being easily modifiable, but what does that really mean? It’s up to the buyer to figure that out! An effective way to do so is to write up a set of imaginary change scenarios and walk through what it would take for the proposed solution to accommodate them. Suppose that program eligibility rules were relaxed or tightened, or client demographic categories were reformulated, or a program changed its model of providing services and therefore its workflows, or a new performance measurement initiative mandated that additional data on certain outcomes be collected. Where in the architecture would these changes need to be made, and how many hours of labor by whom would be required to design and implement them? Before buying into a proposed solution, a project team – with the help of knowledgeable technologists who are independent of the vendor or system designer – should calculate the total costs of a few imaginary modifications.
- Encourage stakeholders to imagine shifting boundaries. Drawing a clear boundary around the business environment and the scope of the application is part of a good project manager’s job. Many will try to take the shortest possible route toward firmly nailing down business requirements so that system development can proceed. But when that approach combines with tightly compressed deadlines, stakeholders can come under pressure to make decisions in such haste that they overlook the need for flexibility. To prevent tunnel vision, the project’s sponsors should build in extra time and explicitly encourage stakeholders creatively to visualize how their environment might look if the current boundaries of the agency or program were to shift, or if their responsibilities were significantly altered. For example, human service programs that are entirely separate today might need to coordinate their efforts or exchange data tomorrow; imagining such possibilities can point toward architectural decisions that will facilitate change if and when it happens.
- Designate a champion for the cause of flexibility. Flexibility does not just happen – it must be specified and designed. It must arise from the insights of subject-matter experts and stakeholder representatives who are able to think about how their agency’s work might change in the future. Yet in a project team, those representatives may feel that their hands are already full just making sure that their current requirements are understood. The project manager, in turn, must attend to controlling the scope and monitoring the progress of deliverables with an eye to the timeline and costs. In this high-pressure mix, who will advocate for making sure that the resulting system will end up being easily modifiable? It can be easy to lose track of such an invisible and abstract quality. To prevent that from happening, the project team should designate a champion for flexibility who is tasked with reviewing functional and technical design decisions and asking hard questions about how they might constrain future change.
- Put the data architecture front and center. The movement toward service-oriented architecture (SOA) has made software applications more modular and interoperable. But with all due appreciation for this advance, many of the most intractable problems of flexibility remain largely unaddressed because they do not lie in applications architecture at all. Rather, they are problems of the structure and meaning of data. Unfortunately, the implications of choices in data architecture are rarely presented to the stakeholder groups who will be directly affected by them. It is hard to see why, since researchers have noted that the impact of data modeling on the quality and success of an information system – including its cost, ability to meet stakeholders’ needs, flexibility and capacity to be integrated with other systems – is greater than any other phase of software development.2 In this regard, the human services sector is in a particular pickle. A human service environment is a complex and fluid social reality that is inherently difficult to model, and that difficulty is exacerbated by the sector’s core concepts and terminology, which are often so imprecise that they provide a poor foundation for developing solid and flexible data architecture. This problem has been examined in detail elsewhere, and a method for resolving it has been presented with examples of successful use.3 In brief: the requirements elicitation phase should not merely consider functionality but should also create a rigorous domain model in collaboration with stakeholders from all the constituencies that will use the system. This technique is effective for clarifying ambiguous requirements, surfacing unresolved questions about system boundaries, and pointing toward patterns of data architecture that can make for a more flexible system. It is also helpful for ensuring that the software will collect and structure data in such a way as to facilitate the production of performance indicators, which have become an increasingly important reason for deploying human service information systems.4
References:
- American Public Human Services Association and Microsoft Dynamics (2012), “Achieving Maximum Value from HHS IT Systems: Critical Success Factors for Agency Transformation”, p.9. Available at http://www.aphsa.org/Home/Doc/APHSA_Microsoft_White_Paper_110912.pdf [Accessed 15 February 2013]
- Moody, D. and Shanks, G. (2003) “Improving the quality of data models: empirical validation of a quality management framework”, Information Systems, Vol. 28, pp. 619-650.
- Coursen, D. (2012) “Why Clarity and Holism Matter for Managing Human Service Information (And How the Sector Can Achieve Them)”, Data Administration Newsletter (April). Available at http://www.tdan.com/view-articles/15967 [Accessed 15 February 2013]
- Coursen, D. (2012) “A Taxonomy of Barriers to Producing Performance Indicators on Human Service Programs”, Data Administration Newsletter (September). Available at http://www.tdan.com/view-articles/16344 [Accessed 15 February 2013]
