This Happens a Lot

There is one scenario I run into on a regular basis. I am called in to consult with a potential or existing client and asked something such as this: “We want you to build a solution to manage our accounts payable [or our accounts receivable or our material requisitions or . . . ].” My response often is something such as: “Why don't you look into Ajax Software Company's accounts receivable package. I think it will do just what you need, and since it is built on Web services, it will integrate with everything else you are doing.”

The usual response to my suggestion is the client considered that already, and the solution would cost the company $85,000, and the client thought I could do it for less. Besides, the off-the-shelf solution covers only 90 percent of the client's requirements. Here's the rub: The missing 10 percent of the solution is not what really concerns the client–what concerns the company is $85,000, and it figures it can get me to say I will build the solution for less.

The Goldberg Variation

Then there is what I like to call the Goldberg variation on this scenario (as in Rube Goldberg). In this variation, I am called in to consult and informed that six months ago my client decided to build a custom solution instead of purchasing that shrink-wrapped software that was only hitting 90 percent of their requirements. Now, six months later, the client has no solution in sight; it is past its promised delivery date, and it needs help bringing this mess to completion.

It is too late to fall back on the off-the-shelf solution without sacrificing bodies along the way, so the decision is made to complete the custom application. My client naively asks for an estimate to help complete the solution. Now, if I had agreed to build a custom solution, I would have a complete set of requirements; we would have a nice, modularized architecture built on best practices for SOA; we would have a complete data map; and we would have defined points of integration for each module.

As it stands now, all we can do is try to help the client cobble its design together and get it working in some fashion. The best estimate I can give the company is something such as three months of time and material at a specified rate per hour. It gets worse. Since we didn't design the application, there will be no warranty. If we get into user acceptance training and there are issues, the client will be forced to burn its resources and our resources until the issues are resolved.

To Code or Not to Code?

Creating your own custom applications is a risky business. Even the most successful and admired organizations may not have what it takes to create enterprise-level custom applications. Having skilled and talented software developers on staff is not a guarantee of a successful product. First, we must consider the motivation that drives an organization to build rather than buy. Let's be clear we are not talking about small, one-off point solutions that proliferate in most organizations. There probably is a legitimate business case to be made for developing point solutions in-house. Of course, that process can be fraught with problems, too. If you are going to roll your own one-off solutions, you need to build them all on a standard platform and use a standard methodology. Does your organization even have coding standards? And I'm not talking about standard naming conventions.

There are two rationalizations used by organizations to justify building custom software applications:

o Existing software solutions do not meet business needs.

o We don't want to spend the money needed for existing software solutions.

I doubt whether there ever is a valid justification for building simply because you can't afford to buy. There is simply no way an organization can build production-ready software for less money than it would take to purchase software with the same functionality. Economies of scale alone dictate building a one-time solution is going to be more expensive than the cost of reusing and reselling a solution.

It Doesn't Fit

The first justification for creating custom solutions is the interesting one. There are certain industries that are forced to create custom software because there are no off-the-shelf solutions. Some verticals have so few key players software firms don't find it worthwhile to build solutions for those verticals. Whoever is in that space typically understands that and probably has some core competency in software development.

Then there are those organizations whose needs are just different enough from others so existing software solutions really don't fit well. Once again, a little disclaimer: I am not suggesting there is ever justification for creating custom HR systems or custom ERP systems or custom accounting or custom CRM systems. What can make sense is creating a custom solution where there is no commercial product that readily can fill your business needs.

Maybe you have a need to integrate a green-screen policy management system with a self-service customer service site. After doing your due diligence, you come to the conclusion if you are going to satisfy that business need, you will require a custom application. But that is only the first step in this process. Deciding that a custom solution is required does not justify that custom solution. Only when the true cost of that solution is determined can we make the final decision whether the return on investment justifies the expense.

Let's Get Real

So, you have decided a custom solution is the answer. And here is what separates the men from the boys: You now need to decide whether you want to build the solution in-house or retain someone else to do the work for you. Hiring a trusted partner to build your solution is the least risky and the most expensive. It is the least risky because your partner understands how to build custom software and how to manage the process. It is the most expensive because the hourly rates your partner is charging are significantly higher than your internal costs.

Risky Business

There are only a few risks involved with retaining an outside firm to do your development work:

o You might end up hiring an incompetent partner.

o The requirements either are incomplete or inadequate.

o Scope creep.

You can mitigate the first risk by doing your homework. Talk to other firms that have used your potential partner and validate its performance. Interview the people who will be working on your project.

A few years ago–when I was on the other side of the fence–I issued an RFP for a major software project. When I began to interview the project staffs from the firms that replied to the RFP, I discovered none of them possessed the required skills to bring my project to completion. It was obvious they would be learning how to do this project on my dime. If I was going to pay for on-the-job training, I decided it might as well be my own staff that received the training. I made the decision to do the project in-house. But the real truth is what I decided to do was move the risk to my own staff, where I could have total control over that risk. That particular project was successful. I doubt any of the firms that responded to my RFP could have pulled it off.

The second risk is the easiest to control. Your vendor will begin with a requirements-gathering phase–probably called discovery. It is the vendor's responsibility to gather and document properly the business requirements of the project, and it is your responsibility to make sure the vendor is correctly scoping the requirements. If your vendor is not getting detailed requirements and feeding them back to you for approval, now is the time to get a new vendor. Without a clear road map of the business deliverables, it will be impossible to design and build the software deliverables.

Duh!

Scope creep is the primary risk of any software project. Once the discovery is done and the business requirements are agreed upon, they must be locked down. And unless something extraordinary arises that mandates a modification in the requirements, nothing changes. It is your responsibility to insist the project's business sponsors understand they need to define and finalize the project during the design phase. Returning to the project 30 days later with a new feature request is not acceptable. And beware of any vendor that readily agrees to scope changes. Consultants who always say yes to client requests put the project in jeopardy.

Do It Yourself

Let's look at the other side of the coin and assume you have decided to build your custom solution in-house. That is a bold move but is not necessarily an unwise move–provided you are prepared to do what it takes to be successful. The risks described above for an outside partner still are applicable. It is far easier for a vendor/consultant to say no to a senior VP than it is for an IT project manager.

There are dozens of factors that make for a successful internal software project, but there are a few issues I see time and again in failed (or less than successful) projects.

Design the entire system before you start coding. Testing proof of concept is OK, but remember the more work done planning and architecting upfront, the easier it is to code on the back end.

Insist on rigid source control and have a tried-and-tested process for regular builds and releases. If you don't understand this, your project probably is at risk.

Ensure you have the proper development, testing, staging, and production environments in place. Do not allow or force your developers to work on machines or virtual machines that are not part of the final solution. You can't afford to be three months into a project and discover each developer on your team is working in his or her own (probably unique) environment. Most projects require environments that replicate other production systems and databases. These environments need to be ready to go on day one.

Culture Shock

I am not quite done. There is an additional factor you need to consider. Software development is an intense process. Late nights and long hours are often necessary. Some corporate cultures do not foster that type of work. Some, in fact, forbid it. Make certain your development team and its supervisors (and their supervisors) understand the commitment it takes to be successful. I have been there. I have done that. If you aren't willing to put in the effort, maybe you should be doing something else. Consider the alternatives.

Please address comments, complaints, and suggestions to the author at [email protected].