|
|
|
||
|
|
|
Ten Tips for Successful Projects These tips are intended for a situation where a new computer application is being considered which pertains to marketing, sales, or customer support. Some examples are sales force automation (SFA), customer relationship management (CRM), and campaign management. My clients have generally been concerned with four components. First, there is a database. Second, there is an online user interface for capturing and retrieving data. Third, there is a way to get reports from the database. Fourth, there is a way to perform data analysis, including graphics and statistical modeling. 1. Business Objective. Make sure the business objective is clear. I have seen some very expensive applications developed for reasons that were never fully explained. Avoid scope creep, the "While we're at it..." syndrome. Also avoid scope shift, as in "We thought we wanted this, but now we want that..." Sometimes it helps to think of the business objective in terms of a marketing plan. Imagine that you have to sell the project to an external customer. What are the target market, product, place, promotion, and price? 2. Business Process. Computer applications are part of larger business processes. Every computerized business system has a human interface of some sort. Introducing a computerized system changes the way people do business. A critical task when introducing a new application is making sure it helps humans do business. An application is worthless if it doesn't help people do their jobs. On the other hand, there is no point automating an obsolete business process. When designing a new application, make sure it handles tomorrow's business needs, not yesterday's. I heard this comment in a design review meeting: "It sounds like you have a lot of historians and no visionaries." Look ahead, but not past the business objectives. 3. Data quality and integrity. Design these into your applications. I have seen so many data disasters, from systems designed to throw out exceptions rather than write them to a log, to databases with accounts that weren't owned by a customer, to summaries that didn't cross-foot with the details, .... Sometimes having no data is better than bad data, since the bad data will be believed by some people, and it's hard to prove to them why the data is unbelievable. 4. Performance and capacity planning. If a computer system is too slow, people won't use it unless they have to. If they have to use it, slowness increases the time for a person to process a business transaction. The employees are paid to wait, and customers are also kept waiting. Performance is also important on the analysis end. I have seen database servers where a large query took two hours when it should have taken twenty minutes. 5. Operational data and management data. Design systems to capture management information. Many computer applications are designed to capture only the minimum amount of data required for operations. Managers ask me reasonable questions that I cannot answer because the necessary data was not captured. For example, I had a client who worked in a retail operation. The client asked me how many sales were made in stores, or by phone, fax, or internet. Place is part of the marketing mix, so this was important to know. I did some research, and found that the sales system had the minimum amount of data to process a transaction: customer name, shipping address, items ordered, shipping method, etc., but not how the order was received. 6. Managers want answers, not reports. A while ago I attended a lunch with a number of other management and information technology consultants. Educationally, we were a diverse group, from no college degree to PhD. However, we had all considerable experience in management information systems (MIS). The topic of discussion was an online management reporting system that one of us was working on. The conversation went something like this: "Managers don't want online reports. They don't want to have to log on and print them. They'd rather have a paper report dropped on their desk." Now, I have to admit that some of these remarks were not made with the most positive intention; however, I have recounted this story many times, and no manager has ever contradicted it. 7. Policy and technology. Don't try to substitute technology for policy. A policy is a decision made by management regarding the the course of action to take in a particular business situation. The problem arises when management refuses to make policy, and requests a computer program or database instead. I have to be careful giving examples of this, since they tend to identify clients in embarrassing ways, so here's a hypothetical example. A company is experiencing an increase in customer complaints. Rather than examining the policies for customer service, the company buys a computerized customer service application. 8. New technology. What's new? A few years ago, when I was an IT consultant, a recruiter asked me what sort of computer system I was working with. I answered MVS, one of IBM's mainframe computer operating systems. She laughed and said "Oh, that old stuff." She went on to ask if I knew any of the new technology, like UNIX. Let's get the facts straight. MVS has evolved from the System/360 operating system developed by IBM in 1964, while UNIX has evolved from the Unics operating system developed by Bell Laboratories in 1969. Economies of scale are lost by mixing different technologies. Many companies have opportunities to save money by using the technology they already have. A lot of the savings come from unnecessary systems support personnel. Here's why. Many large companies have an existing IBM mainframe computer system. Supporting the system is a staff of MVS systems programmers, operators, tape librarians, VTAM network technicians, DB2 database administrators, and programmers who are skilled in languages like COBOL and PL/I. Then some VP with a big budget decides he or she has to have new technology for their pet project. For example, an Oracle database, that has to run on UNIX, and the dialect of UNIX has run on a DEC Alpha computer. In order to support this new technology, a new support staff must be hired with UNIX systems administrators, operators, tape librarians, TCP/IP network administrators, Oracle database administrators, and programmers who are skilled in the language C. Even the printers and terminals are different. In many cases, the application that runs on the new technology could have run just as well on the old technology without additional support staff. This point is not limited to IBM versus UNIX. I have had clients at companies which used the Informix DBMS on HP-UX, Hewlitt-Packard's dialect of UNIX, where some VP decided to bring in Oracle and DEC's UNIX, and then had to hire a new support staff. "New" doesn't mean better. In the case of UNIX, it doesn't even mean new. 9. Databases are never comprehensive. When designing a new database, it is important to consider how the data can be related to other databases. Much of the value I provide to my clients comes from using data analysis and statistical modeling to answer business questions. The data that is analyzed and modeled frequently comes from multiple data bases. Even companies with data warehouses don't have everything in one database. This point relates to the economies of scale that result from a single type of computer system. One advantage of mainframe technology is that all the data is already in the same place, if not the same format. Getting access to the data is a matter of calling the data security department. At companies where each application has its own UNIX system, pulling data together requires multiple logon IDs and database IDs, and copying all the data to one computer where it can be synthesized and analyzed. 10. Tools don't make you a better analyst. After Jurassic Park was released, the head animator for the movie gave a talk about the special effects. He said that young people were becoming interested in animation because it is now done using computers. He went on to say that they had the wrong idea. Computers don't make you a better animator, they are just better pencils. There has been a proliferation of data analysis tools with graphical user interfaces (GUIs). The vendors of some of these tools claim that they put the data into the hands of marketing managers. Data analysts, statisticians, and programmers are no longer needed. These claims are exaggerated. The data visualization tools make pretty pictures, but they are limited to three dimensions. Marketing problems often start with a hundred or more dimensions that need to be explored. The graphical tools that I have seen could help someone find only the most superficial associations in the data. Moreover, databases are never comprehensive (see the previous tip), and at some point, thinking has to go on (see The Atkins Principle). GUI tools don't make you a better analyst. They are just better pencils.
|
|
|
Ingraham Consulting 662 The
Alameda 510/527-5625 |
|
home | services | case studies | competencies | about us | contact us
All Rights
Reserved |
|