Once upon a time, the mainframe was. The mainframe hosted complex corporate applications that required a very disciplined and sequential approach to requirements definition. In particular, it required requirements to be fully flushed out before coding began. Changing requirements en route was a big no-no and (mostly) constituted a too expensive proposition.
That era is gone, although it has been noted that some environments still exact the same sequential and disciplined approach to requirements definition, which dates back from mainframe times. The generally accepted approach in software development now calls for iterative (or evolutive) development. You figure out what you need, then you build some. By building some, you can better articulate further requirements. The cycle continues.
Similarly to the passage from sequential and disciplined requirements definition to evolutive requirements definition; I advocate to go from "specific capability evolutive requirements definition" to "integrated information management planning".
It is not good enough to adopt, as a starting point, "we need a content management system", or "we need a document and records management system". Other starting points are equally not valid: "we need a new records management policy", "we need a new training program". The optimum starting point should be: "we need a sound information architecture promoting integrated information management". Note: I actually believe that integrated information management nicely paves the way to ulterior knowledge management, but this is a contentious issue best left to be discussed at another time.
What of reality? How to achieve "the real thing" - a supportive and compliant information environment?
Here's the recipe. Many of these concepts (including Standard Information Management Frameworks) are fully explored in a new 3-day course offered at the Canada School of the Public Service:
- Just as architects need blueprints, general need battle maps and accountants need ledgers; information managers need a standard information management framework from which they can plan, design and develop the optimal information architecture for their Department - Agency - Company. The development of such a framework has been hampered by the lack of recognition of "information management" as a unified management discipline. I will explore these topics in a conference I'm giving at the ARMA Canadian Regional Conference in two days (sessions T31, T41).
- The Standard Information Management Framework answers the following questions: what are the necessary and sufficient components, in order to implement integrated information management? What is necessary to take into account, in order to develop each of these components? How can information management Vision and key Principles be tied to these components? And, last but not least, how can directives and end user guidance be derived from all of this?!
- The Standard Information Management Framework has nine components: information context, information requirements, information resources, information activities, information roles / services / products, information training / education / standards, Recorded Information (includes Data, Records and Library Management), Information Technology and Architecture Optimization. These nine components, when developed and applied to any particular environment, constitute an Information Management Architecture. You need all components. You do not need other components.
- Six areas of considerations need to be taken into consideration when developing the IM Architecture: Compliance (with legislation, regulations, policies, etc.), Business Context, User Empowerment, Interdependencies, Constraints and Trends & Opportunities. Each of these categories need to be populated with relevants "considerations", for example, in any given work environment, a complete inventory of applicable legislation related to information management, and then, for each such Statute, the information manager should analyze what is the impact of that legislation on any, many or all IM Architecture components.
- Vision and Principles need to be taken into consideration when developing the IM Architecture: Each organization, even within a large Department, is unique, and will warrant a distinct information management vision that should be tied to its role and mandate. Selected principles will vary over time; depending on where senior management wants to focus efforts. Examples of principles include Life-Cycle Approach, Accessibility, Security, Accountability, etc.
- The IM Architecture needs to be translated into IM Directives to realize the potential of integrated information management. Directives should be written from end end user point of view and help them do what they need to do, daily (here is a draft example in a particular environment).
To compare the old and the new, one could say that whereas the old approach saw Compliance (sometimes), the Business Context and User Empowerment (ideally) taken into account to flush out the requirements of a subset of Information Technology (any given IT capability - e.g. Content Management System, etc.); the new approach formally adds Interdependencies, Constraints and Trends & Opportunities into the equation, not only to define "requirements" for a specific IT capability, but to architect the complete IM solution (which is larger than the total IT solution).
In that integrated analysis, one must let himself or herself be influenced by Trends & Opportunities. For example, the ways in which the marketplace is naturally shaping itself into "categories of software" is pertinent. For example, there is a category of solutions catering to documents and records management. Another catering to practice and case management (often in law firms). Another catering to generic web content management. If your "client" has a set of requirements that spans the entire spectrum covered by these three category of solutions; will you ignore these "marketplace facts", or will you structure your Request for Proposal accordingly, by articulating three distinct sets of requirements?
Just defining requirements is not good enough. One must get involved in becoming more knowledgeable in current trends & technologies; one must become more knowledgeable in how the marketplace confirms standard ways to manage information (e.g. wikis, blogs, syndication via RSS, etc.) and, most importantly; one must take a stand on deciding how to best marry a set of business requirements to a set of solutions. If information managers do not do this, who will?
Along that vein, I believe that when these "categories of software" are studied, you become familiar with the good and the not so good. Best features will become apparent. From these best or desirable features, you can build a list of criteria to iteratively assess solutions in a particular category. All of this work and analysis should be done in the spirit of integrated information management, not with any agenda of promoting a specific product.
Now here comes the tough part.
If you have done all the work previously explained, then you can make some judgment calls. And start figuring out your top picks in any given category of solutions. For example, after completion of this kind of analysis; if you come to the conclusion that you require a web content management system; and that the environment in which it needs to be deployed corresponds to features A - B - C being mandatory or desirable; and that such features are best implemented in a particular solution, do not be afraid to take the next step. Do not let the old disciplined and sequential requirements definition process hijack common sense hardly derived from an integrated approach analysis. Go forward. That may take some wrestling with proponents of the old approach, insisting that you stick to "requirements definition" and do not concern yourself with investigating solutions; go forward anyway. And hopefully, in the process, your colleagues will realize that you are doing something potentially novel: implementing a solution that works from all angles. Of course: that solution flows from an integrated approach analysis. ;-)
