Sample Content Preview
Chapter 1 Outsourcing Software You have a need.
If you didn't have a need, you wouldn't be considering a software development project. (Well, perhaps you just enjoy developing software and hoping that a need for it pops up sometime. That's a hobbyist approach to software, and there's nothing wrong with that, but it isn't how most people approach this kind of work.) It seems like a simple process: you have your need, you describe the need to someone else, that person writes a software package that fills your need, everyone is happy. Unfortunately, it very rarely works that way!
You have a need—but you might not know what that need is yet.
It's ironic but true—just because you have a need doesn't mean that you accurately understand it. It is common for businesses to think they need one thing when in fact they need something very different. It is also common for a business to know that it has a need—usually a problem that needs to be solved—but to have no idea of how that need can be met.
Jones Metalworking has a computer-automated production process that automatically cranks out stainless-steel widgets. They also have a website that automatically takes orders online and produces a daily listing of what needs to be produced.
Jones Metalworking's management might think, "We need to hire someone to type the sales list into the production computer." Or they might think, "We need a software package that handles both orders and production in one integrated system." However, their actual need is for some type of "bridge" that will take the sales list and connect it with the production process, so that everything that is ordered will be produced. This could be a person, or this could be software, or it could be something entirely different—but their actual need is for the connection of these two business processes, not for more staff or a different software package. When considering your needs, try and drive your analysis down to the most abstract level. Figure out what your business need is. The odds are good that a software solution can meet that business need—but not always. Don't decide that software is the answer to your need until you accurately understand what your need really is.
But once you do determine that the way to meet your business need is either by changing some existing software or creating a new piece of software, you are on your way defining a software project.
What is a software project, anyway?
A software project can be anything from modifying an existing program to display a particular number in red rather than black, to creating a complete suite of integrated programs that interact with users, each other, and multiple types of hardware, networks and databases. The software itself may be used only occasionally by you or your employees, or it may be an integral part of your flagship product. These factors must be considered when deciding whether outsourcing is appropriate for your project.
Creating a New Software Solution—the Components of a Software Project A software solution is more than a computer program, and a software development project is more than just hiring a programmer to write some code. When you are considering the use of outsourced resources to work on a software development project, you can choose to outsource the entire project, or any of the following components. And you may want to choose one firm to take care of all of the components you outsource, or you may want to choose a different provider for each.
Specifications: A written description of what the project entails, this is the blueprint of the project. See Chapter 3 for more information about specifications. Program Code: This is what most people think of when they think of software: the instructions, written in a language such a C++ or Java, which tell the computer what to do. The program code will usually include a user interface (some method in which the user interacts with the software), instructions to process or act upon the data provided by the user, and perhaps interfaces to other software or to a database.
Ancillary Programs: In order for software to be deployed to end users, it often requires an install/uninstall program, special customization/security modules, or components to allow communication with different types of hardware. These ancillary programs need to be defined, written and tested just as the mainline programs do.
Documentation: On-line help, user manuals, training guides—these can all be very important part of a software package.
Quality Assurance: Although you should expect programmers to check their code for errors, software should be put through a separate, rigorous test cycle to insure that it works as required (and as documented). Testing software is a complex and important part of the development process and should not be left as an afterthought. Chapter 6 covers this area in more detail.
Creating a New Version of Existing Software
Perhaps you have already created a wonderful software product that's popular and profitable in its original market. You now want to make another version of the product that would tap into a different market.
Create a customized version that targets a different type of customer. For example, a company that sells ticket management software to theaters and sports teams wishes to create a version that handles student enrollment for training companies. If your staff are not experts in the new target industry, you may want to bring in experts in that industry to help design the changes. In this case, you may want to outsource the creation of the requirements documents but have your staff handle the creation of the software itself—assuming that you didn't outsource the creation of the original product.
Port software to a different platform. Perhaps your software runs on Windows PCs and you want to have a version that runs on Macs or Linux machines. Or maybe you have traditionally supported Oracle and SQL Server but are getting customer requests to support MySQL. Rather than purchasing a bunch of new equipment and hiring staff who understand the target platforms (or sending your staff to be trained), you might want to outsource the creation of the alternate version(s) of your software to developers who already have the expertise and the necessary hardware and software environment.
Translate software into a different language. Creating a version of your software to sell in another country will almost always involve creating a new user interface and translating the documentation to handle language differences. This may be true even if you are targeting another English-speaking country, since the various "flavours" of English have different spelling and syntax issues. Depending on the type of software, other changes may also be necessary in order to comply with local privacy and data security requirements, or to be acceptable culturally or legally in the intended market. Localization projects are often very well suited to outsourcing, as it is usually more effective to hire a firm that is familiar with the language, culture and operating parameters of the target country than it is to try to develop that expertise in-house.
Project Visibility
Another way to look at software projects is to consider how visible they are both within your company and to the outside world. Most software can be divided into three broad categories:
Internal software—such as accounting, payroll and inventory systems that are used by you or your employees to manage your business. You customers generally have no direct contact with this type of software. This type of software is often purchased outright (such as Quickbooks for small business accounting or Goldmine for customer contact management). If your company's needs aren't met by an off-theshelf product, outsourcing the development of the software you want may make sense, because it's unlikely that your employees will have the expertise and time to do it internally.
Software used by/for customers—such as your web site, self-service kiosks in your store, on-line and over-the-phone sales and service systems. Again, your employees will likely know how to use these systems, but they may not know how to create or maintain them, so outsourcing may be sensible here. However, because this software is visible to your customers at least some of the time and because this type of software can be extremely "mission-critical", if you do outsource it, you will want to be very confident in the developer.
Software that is sold to your customers—such as a video game, a tax accounting package, or the CD component of a book package. If the software is a major component of your product, you may have the expertise in-house to develop it yourself—after all, that is the business you're in. If it's only a small piece of your product, however, you may want your staff to focus on the other parts and to outsource the software portion. As with the previous category, this type of software is visible to your customers, so the margin for error is much less than with an internal project (most businesses can cope if their employees must work around an awkward software user interface or wait for an upgrade to an internal system, but asking customers to accept a low-quality or late product can lead to lost sales).
Project Size as a Determining Factor
If your software project is very small, and you have the appropriate resources inhouse, outsourcing may not make sense. This can be especially true if you want an existing piece of software modified. By the time you've explained how the software works and what you want changed, you may be able to make the change yourself (or have an employee do so). On the other hand, a small, self-contained software project, such as a developing an Excel spreadsheet for your salespeople to use to create job quotes for customers, may be perfect for outsourcing—especially as the first project you assign to a new contractor. Large, complex projects are often wellsuited for outsourcing, but definitely require a developer with sufficient resources and with experience in managing such jobs.