Delivering Successful Software Solutions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
According to a study by the Standish Group, 31 percent of all software projects are cancelled before they are completed. This fact should terrify everyone involved in software development. In fact, it suggests that most software development efforts should never be undertaken because the risks are too high. In this article, I'll focus on how to identify and mitigate the inherent risks associated with software development to turn the odds in your favor. I'll do this by focusing on the three key success factors: process, people, and systems.
Process
Over the last several years, I have consulted with many companies. These companies were both large and small, spanned various vertical segments, and supported both internal and contract development. With rare exception, however, they all had one thing in common: None of them had a software development process. A well-defined process is the key to a successful solution. This applies whether you are building, selling, or managing.
Delivery
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 farm house? 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, 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.
Project Management
Along with the delivery process, companies should have a project-management process. The project-management process is concerned with tasks, due dates, and milestones. The delivery process dictates that a design should be created; the project-management process dictates who will create the design and by when. Most companies have some form of project management, but my experience is that the process is inadequate. Project management is a full-time job to be accomplished by dedicated project managers.
Returning to the home-building metaphor, the project manager for a new home is the general contractor. Typically, the general contractor adds 20 percent to the cost of a new home for his services.
Over the years, I have known several people who have tried to save money on their new home by acting as their own general contractor. This means that they were personally responsible for coordinating the carpenters, electricians, and plumbers. They also had to order supplies, coordinate deliveries, and get inspections. What a headache! I don't know anyone who thought it was worth the effort.
Not too long ago, I had a new home built, and I used a general contractor. One day, I brought my family to visit the home while it was under construction. We pulled up to the site and parked in the street. My wife and kids got out of the car and immediately heard someone in the garage yelling at the top of his lungs. As we approached the house, the yelling got louder, and we could make out a string of profanities.
At some point, the general contractor, who had been doing all the yelling, spotted me coming up the driveway. He stopped yelling and left the garage to meet me before I was able to enter the building.
"Good morning, Mr. Hillier," he greeted me.
"Hi Larry," I said, motioning to the garage. "Any problems?"
"Not a thing, Mr. Hillier, we are right on schedule."
Now, I thought, that's project management!
Sales
Most technical people want nothing to do with sales. However, everyone should recognize that the delivery process is really an extension of the sales process, and vice versa. In fact, the series of events that occurs from the first cold call until the final customer satisfaction survey is really a single process.
At our company, we utilize a consultative sales process that partners with the customer to solve a business problem. The entire focus of the process is to identify a business problem and solve it through the use of consulting and software development. This model is not unique to our company, but the idea of treating it as a single process is not always evident in other companies.
Salespeople seem to be naturally resistant to using a process. Salespeople often speak in vague terms about potential successes. They report progress with a lead by saying that they "feel good about this one." This approach often leads to a poor sales forecast and an inability to close business.
Making the sales effort part of the overall process enables you to manage the sales effort and determine the status of any potential deal. Our company uses a CRM system and a grading scale to create a sales pipeline. We also clearly identify the integration points among sales, delivery, and project management. For example, once a sales prospect reaches a certain milestone, a project manager is assigned. The salesperson may still be the lead in the effort, but the project manager creates a project plan and prepares to acquire resources. When the deal is closed, the project manager immediately takes over, with little transition required.