Approach

The mission of my consulting practice is to help public service organizations become more effective and more efficient through higher quality information systems—and at the same time, to reduce the risk, expense and pain associated with information system projects.

Information systems can be designed to collect and provide meaningful data that meets the needs of all stakeholder groups; to flexibly evolve as an organization’s needs change; and to support the integration of data across public service settings.

That’s a higher bar than most information system projects aim for. Achieving it requires using design methods that may be unfamiliar to many practitioners. Those design methods, though, are not really new. They’re underwritten by a rich tradition based on systems thinking.

Twenty years of work in this field have led me to develop six key practices that I’ve found lead to more successful information system projects.

Six Practices

#1: Focus on laying a solid foundation of data architecture first.

In the construction industry, workers lay the foundation of a building first, before they set up the girders, floors and walls. There’s no other way, of course. And once the building has risen, it’s hard to go back and make changes in the foundation.

The same is true when building an information system. Software developers have to lay its foundation—which is the data architecture—before they can build interfaces and logic. And once those have been built, it’s hard to go back and change the data. That’s why 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.*

When information system projects come to grief, the problems are very often related to poor data architecture. And that, in turn, is typically the result of a software development approach that emphasizes the application’s functionality first, and then infers the data needed to support it.

Fortunately, there’s a clear alternative. It’s sometimes called the data-centric approach. That means focusing on designing the data first, and working on the processes and functionality afterwards.

Good data architecture is the bedrock on which everything else rests. Investing care and effort on that—at the beginning—will pay handsome returns over the life of a project.

#2: Create a clear box that non-technical stakeholders can see into.

Dealing with information systems can be stressful for stakeholders who don’t have a deep background in technology. One reason is that they often feel left in the dark about what’s going on. When talking about requirements, it’s customary to treat the information system as a black box, a mechanism whose inner workings are hidden from view. Non-technical stakeholders are usually asked what they want the system to do for them. But only the technologists are expected to understand what’s inside it.

In fact, that black-box approach creates a barrier to communication. It can even imperil a project. Decisions about the inner structure of an information system will determine how well the system can meet stakeholders’ needs—both those that are clearly known and the ones that have yet to emerge. When stakeholders aren’t made aware of design decisions, it’s easy for problems to go unnoticed for so long that they become costly to fix.

Fortunately, there’s no reason why an information system needs to be a black box. It can just as well be treated as a clear box with an inner structure that’s open to view. Key non-technical stakeholders can, with a bit of coaching, find it quite easy—and even fun—to learn to think about data architecture and the implications of different possible decisions. Creating a clear box that everyone can see into is a straightforward way to ensure that everyone understands what an information system will and won’t be able to do.

#3: Think of the information system as a model.

An information system is typically thought of as a useful mechanism. It’s designed to satisfy defined requirements. It’s like a sort of box that receives inputs and produces outputs.

That point of view is necessary, but it’s not sufficient. Making a list of requirements won’t guarantee a comprehensive plan and a good design. One reason that so many information system projects are challenged—whether in timeline, cost or functionality—is that in gathering requirements, it’s easy to miss things. Another reason is that focusing too tightly on inputs and outputs often leads to design decisions which are so narrow that they foreclose future possibilities.

Fortunately, there’s a simple way to foster a broader perspective. It’s to think of the information system as a model of the organization’s work and environment. The model must contain data representing all the facts that are of significant interest to stakeholders.

This approach frees up the insight and foresight of both the subject matter experts and the technologists. It leads stakeholders to a deeper understanding of their world and how the system needs to support them. That’s the first step toward creating plans and designs that will comprehensively satisfy the requirements of both the present and the future.

#4: Bring operational and analytical perspectives together.

Most public service organizations are complex. They’re wholes made up of many interlocking parts. There are front-line operational workers and levels of management. There are staff who work on performance measurement and, in many instances, on program evaluation and planning. There are senior leaders who make policy and look outward to monitor the organization’s external environment.

All of these roles depend on data, but in different ways. Needs for analytical data can be particularly dynamic and hard to pin down, because answering one question often leads to asking new ones.

This complexity creates pitfalls for information system projects. It’s easy to end up with a system that meets the requirements of only a few specific roles, or that collects data which can only address the questions that have already been formulated.

Fortunately, there’s an effective way to tackle the complexity head on. It’s to build a integrated team of subject matter experts that includes perspectives from all the major operational and analytical roles. That mix creates a rich conversation of a kind that is new for many organizations. It can lead stakeholders to a more powerful and shared understanding of all the kinds of feedback loops that the system will need to support.

#5: Make sure that language has a clear and shared meaning.

Just as the foundation of an information system is its data architecture, the foundation of data architecture is human language. Data is made up of statements in language, nothing more and nothing less.

A fact stored in an information system—such as “Jane Smith lives in Australia”—is language. And the information system’s ability to store that particular fact is based on a more general assertion: “A person can live in a country”. That’s language too.

In everyday life, people often take the language they use for granted. But when designing an information system, that can be a major pitfall. Every organization has its business terminology, and it seems natural to design information systems around that language. But in many instances, the terms used in an organization’s day-to-day work may be vague or ambiguous. And stakeholders in different functional roles may understand the same term in different ways. When flawed terminology gets embedded in data architecture, the flaws eventually hobble the system’s ability to provide the information that the organization needs.

Fortunately, organizations have the power to examine—and even change—the business terminology that they use. The process of planning an information system is a golden opportunity to do that. Public service organizations can often benefit by reviewing and refining the use of basic terms such as program, client, case, enrollment, referral and outcome. This leads to more solid data. It can also foster a clearer understanding of the organization’s processes, its goals and even its mission.

#6: Anticipate emerging needs.

An information system can’t do everything. There must be boundaries around its scope. Stakeholders need to have a clear and shared understanding of what is included and what is not.

Over time, though, stakeholders will often want to shift the scope of an information system’s functionality somewhat. New needs often appear when an organization acquires a new line of business, or when a regulatory framework changes. New needs also emerge simply as a result of the organization learning more about its own work and environment: collecting and interpreting data in an information system creates a feedback loop which changes the organization’s understanding of itself, and often leads to demands for new kinds of data.

As new needs emerge, the system’s sponsors often push it to meet requirements that were not part of its original scope. That’s a challenge that tests the original design of the system: Is it feasible to modify it? Too often, the answer is simply no, or that the cost would be too high.

Fortunately, it’s possible to design information systems to be flexible enough so that they can accommodate many emerging needs. Figuring out the data architecture first, paying close attention to the meaning of business language, and leveraging the creative tension between operational and analytical perspectives will all tend to result in more flexible information systems.

And there’s one more practice that helps a lot: casting a wide net to understand the organization’s work and environment broadly, beyond the immediate scope of the system being designed. Business processes which initially seem tangential can turn out to have significant implications for the eventual scope of the system. Stakeholder groups that are not included in the initial design process often appear later with important needs that must be met. Trends in the outside world can give clues to kinds of functionality that may be needed in the future.

An organization is made up of many interconnected parts, of which an information system usually serves only a few. But to anticipate how the system may need to be modified in the future, it’s a good practice to take the time to understand the organization and its environment as a whole.

*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.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.