Part 3: Technology
Now we are ready to look at technology -- the target of all the planning and preparation described in articles 1 and 2. As you probably can guess if you have read the preceding articles, I am not going to recommend specific products or technologies, but to provide you the wherewithal to make your own decisions. We would rather teach you to fish than give you a fish!
Technology and Time
Technology and Time
Technology is related to time. A specific technology is invented or developed at a point in time, it spreads over time, and eventually becomes obsolete. Because of this, a technology cannot be evaluated except in relation to time. Its value, suitability, purpose, and even glamour are all related to the time at which the assessment it done. Thus it should come as no surprise that one of the six critical factors in evaluating a technology project is the maturity of the technology, which I classify as Old, Current, and New.
(By way of review, in my last article I discussed how to evaluate costs, benefits, and risks. Although costs and benefits can be analyzed for any type of project, I believe that technology projects are unique in their high risk of failure. In my paper "Risk Factors in Technology Projects" I identified six factors for evaluating risk in technology projects -- but it all comes down to the fact that technology introduces change to the organization, and change is always risky.)
As we all know, using New technologies tends to increase the risk that a project will fail. Some of the reasons for this are:
On the other hand, an organization cannot simply resist all new technologies in the hope of avoiding risk, because reducing risk by using only Old technology leads to inefficiency, which is just as bad or worse. New tools are developed because they permit more benefits to be achieved per unit cost. To take an obvious example, the labor cost of entering data into a database is no more than that of typing the data on slips of paper, but the database provides benefits the paper does not.
Remember, the ultimate system will never arrive, so you cannot justify inaction on those grounds.
Another way of looking at technology age is the diffusion of technology. "Diffusion" is the economics term for the spread of technology through its potential audience. Technologies diffuse according to a sigmoid (S-shaped) curve, like this:
It should be clear by now that the decision to use any given technology is dependent on its age, and thus the decision will change from year to year. In other words, there is a continual obsolescence going on, in which a technology that is now New may be Current in a few years and Old a few years after that. In reality, the pace is not that fast; most technologies take about ten years just to move from the laboratory to the market, and another ten years to become Current. The World-Wide Web is a notable exception, which is why it has caused so much change in business and society; but the Internet was designed in the 1960s, so it exhibits the more usual rate of diffusion.
Since technology is always changing, there is a continual danger of falling behind the curve (literally, the sigmoid curve). No organization can afford to stop making decisions about adopting technologies for long. Catching up means making much bigger steps than staying current, and thus higher risk. Instead, I recommend that museums except for the smallest continually experiment with new technologies in pilot projects (that is, in Noncritical Focus activities using the Intensive approach -- to use terminology from "Risk Factors in Technology Projects" cited above). This is the best way to stay current and to make decisions about what is suitable.
To say this another way, here are some guidelines:
Technology Assessment and Strategy
I recommend that museums have a long-range technology plan, based on the museum's strategic plan. This plan will outline the technology strategies and policies to be followed over the subsequent ten years or so.
One method of generating such a plan is my company's Strategic Technology Plan, or STP™, a methodology that provides a framework for decision-making. For example, an STP can help ensure the CMS is part of your overall technology strategy. The STP provides a systematic approach to studying the museum's data, existing technology, priorities, and policies, and results in a year-by-year implementation plan. For more information, see "A Rapid Method for Information Planning".
Of course, the STP is only one approach to developing a long-range technology plan. The important point is to do the planning and to have a plan. However, I do not believe that a museum with no experience in this area should undertake such planning without a consultant who has experience in this specific area, as it is easy to spend a great deal of time (years, in some cases) gathering information and then not be able to make use of it.
Having a long-range plan (whether for technology or anything else) does not mean you must then undertake crash projects that change everything at once. I have seen this approach fail too often to recommend it. On the contrary, my philosophy is, "Plan globally, implement incrementally." By having a long-range plan, you can then implement pieces of it over time with the confidence that they will all work together in the end. Without such a plan, you will probably make decisions that result in incompatible technologies, systems that do not meet long-range needs, systems that are replaced too soon, and other costly problems.
Standards and Policies
Standards are one of your best strategies for risk reduction and cost reduction.
Museum people generally well understand the value of standards in risk reduction. Most museums would not consider buying a CMS, for example, that did not run on a standard computer platform, or that did not use a standard type of database management system such as relational. These are strategies to ensure that you can salvage part of your investment if the vendor stops supporting the product.
Standards can also reduce costs, such as the cost of converting non-standard data. Museums last far longer than computer systems, so the cost (and pain) of data migration every five or ten years can add up to a lot of money. Fortunately, museum data tends to be fairly stable; I have seen 19th-century hand-written accession ledgers at the Smithsonian that contained similar data to that collected today.
Standards can also help you take advantage of future developments in technology. For example, if an excellent image-compression technique is invented five years from now, will you be able to use it? If you are using a standard image format now, there will certainly be conversion between them. For a proprietary format, maybe not.
National and international standards
Although I am a great believer in standards and their value to the community, you do not have to become a great standards expert in order to acquire a CMS. This is because relevant standards tend to become incorporated into the CMSs on the market. Fortunately, our field has become mature enough to support standards work by those who are interested, which benefits us all.
I include in this section not only standards approved by the official standards bodies, but also those developed by noncommercial bodies with a national or international focus.
Here are a few standards you should know about:
In contrast to national and international standards, industry standards arise from commercial interests. Actually, the motivation of both kinds of groups is the same -- to improve interoperability and efficiency. In fact, many national/international standards, such as ASCII and JPEG, began as industry standards.
Industry standards usually begin with a single company's need to solve a problem. For example, the GIF picture format was invented by Compuserve in order to compress images for transmission to its users. Other companies, either collaborators or competitors, adopt the solution for marketability reasons. Quite often competitors will modify the solution somewhat to gain an advantage, or just because they see room for improvement. When it reaches the point where the various solutions are incompatible, there is usually some move to reach agreement in order not to alienate the market. Thus an industry standard is born.
The early stages of rapid improvement are beneficial in the long run, although confusing to those who must cope with incompatibilities. It is worse when a technology is frozen into a standard too soon -- it may never be developed to its full potential. (The QWERTY keyboard and the VHS videocassette are often cited as examples of this.)
There is a looser meaning of "industry standard" that is gaining currency. Marketers now speak of their products using an "industry standard database," meaning only that the database uses the relational model. The problem is there is no industry standard for relational database management systems, so the term has very little meaning when used that way. (There is a theoretical definition of "relational," but no widely used database management system implements it completely.)
Although you do not need to be an expert in industry standards, it is hard to have a discussion about systems without using names of standards, so some familiarity is helpful. The easiest way to get this knowledge is to subscribe to one of the mass-market computer magazines, like PC Magazine.
Internal standards (Policies)
Despite all the standards discussed above, there is still need for internal standards, otherwise known as policies. Policies will affect the daily work in the museum more than the broader standards already discussed.
How can policies help? Here are two sentences from the imaging policy of a client museum:
Policies like this ensure that imaging projects throughout the museum will have long-range value. With the addition of policies about resolutions, color bit-depths, and other technical details, the results of various imaging projects over the years will be compatible with each other.
Policies are not simple or inexpensive to develop -- just simpler and less expensive than having no policies. To stick with the imaging example, consider the costs of rephotographing objects or rescanning photos if the original work was not of sufficient quality -- not to mention the wear and tear on the objects.
Policies must be put in place fairly early in the life of a technology, and must be monitored and enforced. Although it is obvious that a museum-wide program should follow policies, it often happens that a project that starts as an experiment becomes the foundation for a museum-wide program. Early development and monitoring of policies can ensure that even the experiments take heed of the future and their technology decisions can be justified in terms of long-range strategies. Policies need not restrict creativity and experimentation, but they should differentiate between experiments and mainstream activities.
Policy development is really a planning process. I suggest you review my suggestions on planning in article 1, especially about stakeholders. For a policy to succeed, it must have the "consent of the governed," otherwise it will be ignored; thus it is essential to ensure that all points of view are considered and incorporated.
Technology policies should address the specifics of implementation, even mentioning products when appropriate. Naturally this means they must be periodically reviewed and revised. Sorry -- there's no quick and dirty solution here!
Here is an example of an actual imaging policy whose development I led for the Los Angeles County Museum of Art, which has kindly allowed me to use it here. I have added notes and explanations to the policy to point out the important features. The original policy was developed in four two-hour meetings over a period of a few months, with some email discussion between meetings. There were about seven persons working on it, including representatives from a curatorial department, education, information technology, photography, and visual resources. As you will be able to see in its revision history, the policy has been revised several times as the museum has responded to new needs and new technologies.
Perhaps you've heard the saying, "Borrow a thousand dollars and the bank owns you. Borrow a million dollars and you own the bank."
Because all vendors of CMSs are small businesses, this principle colors the entire relationship between a vendor and a museum. Put another way, a major contract can affect a vendor's entire business. It is important to remember that the largest CMS vendor has around fifty staff, and one of the major vendors for years had exactly four. And none of them are getting rich as in dot-com rich.
The vendors are small because the museum systems market is small. There are only tens of thousands of museums in the world, and in any given year, probably only a thousand or so are looking for a CMS, and only a few hundred will purchase one. That's not many customers to go around, compared to the number of customers of the companies that shape our unconscious ideas about business, like Coca-Cola, Sony, General Motors, and IBM.
Because the market is small, the most productive attitude is one of collaboration. Adversarial positions are bad for you, the vendor, and the community. For example, to require large financial penalties that if invoked would drive a vendor out of business makes little sense. You certainly won't get your system running that way, and no one else will either.
On the other hand, many vendors take a very casual attitude to their client's schedules. Lying about delivery dates is not unknown. This is deplorable, and while an adversarial approach will not work, I do not advocate being soft either. Vendors with such attitudes should be avoided until they change their ways. Check with your colleagues about their experiences. If you feel you must use that vendor's system despite the scheduling uncertainty, at least you will do so by choice.
In other words, you are adding the scheduling uncertainty as one of the decision factors, and evaluating it along with the technical features, cost, and other factors.
I do recommend financial penalties be written into the contract to be administered when the vendor is clearly not working on your system or data. Such penalties will cause vendors to plan their workload and staffing better than some do now.
The size of the penalties must be calibrated to inflict pain, but not ruin. Five percent of the contract amount for each month's delay up to a maximum of twenty-five percent is a good guideline; after five months you may want to cancel the contract anyway. The contract should make very clear under what conditions the penalties will apply, and these conditions must be fair. It is no good blaming the vendor if the museum has delayed the project through its own disorganization or poor planning.
Museums must also realize that vendors have to make money. I heard a story from one vendor who was asked to make three out-of-town visits to sell a $1000 product. This obviously doesn't make sense from a business point of view -- the cost of a single trip would be more than the purchase price. This is a hard attitude for some to understand who have worked in penurious non-profits all their careers. But remember, a vendor who is not making money may not be around next year to provide you with the systems you need.
The most unpredictable aspect of implementing a CMS is data conversion. The other steps in implementation, like delivery, installation, and training, can usually be scheduled with a few weeks notice, but data conversion is a highly specialized and complex task. The vendor may have only one person or a few qualified to do it, and for a large museum the work can take six months or more.
Data conversion by its nature is unpredictable, and speed can be the worst enemy of quality. It takes time to study each data element and the range of values, and to develop algorithms to standardize it. In other words, the slowest vendor may give you the best database in the end. Do not sacrifice the long-term value of your data in order to get running a month sooner.
Buzzwords are the common currency of technology. If you don't understand them, you almost cannot communicate. On the other hand, like well-worn currency, buzzwords fade and blur over time; and the longer they are popular the less meaning they have. Terms like "object-oriented," "interactive," "metadata," and "web-enabled" have dozens of different meanings.
Thus buzzwords are not a reliable way to choose technology products. Besides the lack of precision, you will soon discover that vendors who hope to stay in business will find some way to describe their products using whatever the current buzzwords are. This has reached the point where Sun advertised a product as "fully buzzword compliant" (it's a joke!).
However, if you need to know a buzzword, here are some good sources:
So if buzzwords are not the way to choose products, what is? As you may imagine if you have read the previous articles in this series, the answer is to use a good process and to put experienced people on your team. The truth is, it is far more important to know your organization's real requirements than anything else.
I have discussed the planning process in article 1, and the project-management process in article 2. These are the preparation stages for the procurement process, which has your statement of requirements at its core.
The purpose of a competitive procurement process is three-fold:
Readers from government and university museums are probably familiar with their own organization's procurement process. They will also probably be required to work with a procurement office when buying systems. This is usually a help, although disguised as a hindrance. For one reason, the procurement office will insist on an objective, competitive procurement process, which is to your benefit. Second, there are many details to be specified when acquiring a system, such as installation, testing, and maintenance, and the procurement office probably can help with these.
Now I have to introduce some acronyms: RFP, RFB, RFQ, and RFI. These are various ways of asking vendors how a problem could be solved.
RFP stands for Request For Proposals, and is a document describing your problem which is sent to companies to ask them to submit proposals for how they can solve the problem. Some organizations use the terms Request For Bids or Request For Quotations instead. The RFI -- Request For Information -- is a bit different. It does not ask for formal proposals, but only for information. It is usually used early in the process of trying to solve a problem, especially one that is hard to describe in terms concrete enough for an RFP. Normally to acquire a CMS, only the RFP is required.
The major steps in a competitive procurement process are these:
Parts of an RFP
The next article outlines a sample RFP.
Usually you want to make a decision quickly, usually within a few weeks after proposals are received. So the evaluation team should be scheduled and meetings set up for this ahead of time, based on the procurement timetable. You should be aware it can take half a day just to read a single proposal, and at least that long to score it and discuss it, plus more time to compare proposals and make a decision. A week is not unusual to evaluate three or four proposals.
The procedure is for each person to read each proposal, scoring it by themselves. Then the group meets to compare impressions and scores, and consolidated scores are developed. This helps bring to light any misunderstandings. There will probably be a need to get clarifications from vendors.
Proposals that are obviously "non-responsive" need not be scored in detail, for example, if a mandatory requirement is not met, or if critical information is missing.
After the consolidated scores are developed, the weights are applied to come up with a total score for each proposal.
The reason for a numerical process is to eliminate factors like lobbying and personal relationships from the decision. It is as objective as any human process can be, especially if the committee contains a variety of points of view (but five is enough members). So what happens if the top-scoring proposals don't agree with your gut feelings? This means something went wrong in the RFP development -- requirements overlooked, weights assigned wrong, etc. The best cure for this is prevention. While developing the requirements, you have to be devious in thinking about the implications of each one, making sure the requirements don't make any assumptions, how to prevent vendors from being ambiguous, how to verify what vendors tell you (by thinking of points for the demo), etc. It requires a mind like a lawyer's, to think of all the ways around a question and how to prevent them.
As you probably realize by now, a competitive procurement is a lot of work, but it is far better than acquiring the wrong system. It should be kept in mind that it is a lot of work for bidders too, so keep requirements few. It is better to receive for full explanations of a few dozen requirements than sketchy information on hundreds. Allow bidders sufficient time to prepare the proposals. Thirty days is the usual time, but that is just barely enough, since a thorough proposal may take an entire week for an experienced employee.