The vision thing
Scot Hillier
Developing a CRM system requires a good idea of what the system should accomplish. This tip, excerpted from InformIT, illustrates that need pretty well.
When discussing the importance of process, I often use a home-building metaphor. I ask customers to imagine that they want to construct their dream home. I ask them to imagine the home. Is it a colonial? Is it a farmhouse? Is it on a cul-de-sac? Is it on a large plot of land? The answers to these questions constitute the "vision" of the final product. This vision is generally present when a customer buys software as well?the customer can see the product in use. People are working more productively; the company is more efficient. A vision, however, falls far short of the information required to actually construct the project.
When it comes to building homes, most people understand that vague vision statements are inadequate to deliver the final product. No one would want to bring in a cement truck to pour a foundation based on a vision statement like, "My dream home will have a big front porch." Nonetheless, people seem to think that this is possible for software developers.
In the process of building a house, the vision is translated into a design through the use of an architect. The role of the architect,
Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning editorial writers on the latest customer relationship management (CRM)and call center technology issues today. Our goal is to keep you informed on the hottest issues facing this fast-changing industry.
Hannah Smalltree, Editorial Director
of course, is to define the final product completely on paper
before any concrete is poured. It's far better to throw away paper than to jackhammer concrete.
Unfortunately, as obvious as this statement is, many customers are simply intolerant of the design
process. Many, many people have told me that designing a system on paper seems like a waste of
time. As a result, the software development effort is date-driven under tight deadlines, which
invariably results in failure. Make no mistake, one of the primary reasons for failed projects is
inadequate design. If you start coding without a correct design, your chances of failure are
extremely high.
Consider the following true story from a company I worked with recently. The company was selling consumer goods, but this effort had grown out of the original personal shopping service on which the company was founded. The personal shopping service was small at first but grew rapidly, and the company began to add customers. Eventually, the customer list became large enough that a customer relationship management (CRM) system was required to keep track of the work. Like many companies, this one hired a consultant to create the system?and that's where the trouble began.
Although the consultant understood the needs of the business and represented that he could create the CRM system, no one at the company was capable of judging the quality of the work created. The success criteria was simply that it worked. If the consultant was able to demonstrate functionality, then it was assumed that the application was constructed correctly. Perhaps you have used this same criteria to judge software products. I know that most companies I work with use this principle at some level.
The problem with judging software based on the demonstrated feature set is that features are not the only concern. Other questions must be answered before you can determine for certain whether the product is right for your company. In particular, this company did not determine how well the application would perform as more data was stored in it and more users accessed it. The company also never asked critical questions about the software's capability to be used on the Internet, or whether it had an easy mechanism for connecting to others systems. All the company worried about was the feature set.
Happy with the new system, the company continued to grow. When the Internet boom came along, this company naturally wanted to make its services available to Web consumers, so it had its internal developers create a Web interface to the CRM application that customers could use to place orders. Unfortunately, the system was not prepared for the onslaught of orders received via the Internet. It turned out that the system crashed as soon as more than 15 Internet users accessed the system simultaneously. That's when I was brought in. The problem with the system was its architecture. The system had been designed as a single component?or building block?that selfishly used system resources. This meant that the system used memory and database connections without regard for sharing them among many users. Because of this design, each user received dedicated resources in large quantities that soon taxed the system to the point of failure. This type of failure was never considered because the company had been so focused on features, and no design process was utilized.
To read more of this tip, click over to InformIT. You have to register there, but registration is free.
This was first published in February 2001
Join the conversationComment
Share
Comments
Results
Contribute to the conversation