Buy vs. Build

To meet an organization’s software system requirements, an alternatives analysis of commercially available solutions (packaged software) should undertaken. A Buy vs. Build Analysis evaluates three potential solutions: packaged software (i.e., buy), custom-built software (i.e., build), and a hybrid approach (in which both custom software and prepackaged components are integrated into the solution).

Option One:  Packaged software, or commercial off-the-shelf (COTS) software, is generally geared toward either a vertical market, in which the system performs a range of business functions for a specific industry (manufacturing, retail, health care, restaurants, etc.), or a horizontal market, in which the system can serve a wide variety of industries (not specific to any industry or business). IF an organization’s requirements are not industry-specific, more generalized software solutions should be considered rather than those targeting businesses with industry-specific needs.

Option Two:  Custom software is developed either for a specific organization or for a function that is not addressed by packaged software, and is generally not targeted to the mass market. It would be specifically designed for the organization’s particular requirements and can be tailored to fit exactly the task order process. Custom software is much more flexible than packaged software and can incorporate specific business processes that do not exist in a packaged solution; further, it can be modified as the organization’s requirements and business practices change.

Option Three: A hybrid software solution is one in which both a COTS system and custom-built software are combined. This approach is viable when a COTS system meets a portion of the requirements and can be effectively integrated as a component of a larger software system. The same limitations and advantages as mentioned above apply, but the COTS application does not need to address all of the requirements. This configuration typically works best when the COTS system addresses system requirements that are fairly common (either across industries or within an industry), such as scheduling or collaboration. Additional integration, licensing, and maintenance costs apply for this arrangement.

Factors to consider in buying:

• Is a COTS system available? How closely does it meet the requirements? What does it cost? How good is it? What has been the experience of others using this software?
• If no COTS system is available that meets the requirements, is a COTS system still the only viable alternative?
• Are the requirements sufficiently defined, facilitating an informed selection of a COTS system?

Factors to consider in building:

• Can outside vendors build the solution? How experienced are they building similar systems and how well do they understand the business processes involved?
• Is this system essential from a strategic standpoint? Does it support a core competency? Are security or competitive secrets a concern?
• Is there a COTS system available that closely meets the requirements?
• Can the necessary technical resources be obtained?

Common factors to consider:

• What level of integration with external systems (Contractor Accounting System and Databases) is required?
• What level of flexibility is necessary in the security model and is it important to have user definable security roles?
• Is a customizable feature set (Reporting, Search, Alerts, UI) a priority?
• How powerful and adaptable do the system’s document management capabilities need to be?

Agile & Traditional Development

With much of the fundamental project infrastructure (scope, priorities, estimates, schedules, risks, etc.) in a constant state of flux, it has never been more important to steer and manage decisions within an overall business context and drive project goals towards business value.

An extreme may occur in traditional software development  processes when the planning process is at such a detailed level that the project never really gets started.  Once the scope, plan, and objectives are fully defined and agreed upon, the team realizes it used 50% of the time and budget for the project to define the plan. Subsequently, the dates and costs of the plan are obsolete. The team needs to go back and revise the plan again. One realizes this approach does not work because the planning phase never ends and work never begins.

Agile development  is a methodology used to describe how to deliver projects on time and budget based on the scope. Given the rapid change in technology and business needs, it is impossible to accurately plan and schedule a multiple month software project up front.  This approach offers the necessary planning and control but also the flexibility to accommodate change.

The scope of this analysis will be limited to an examination of the traditional process to software development  and where this approach fails to yield the desired results.  This process will be contrasted to an alternative approach known as Agile development . This approach that has been gaining momentum in the software development  and business communities, demonstrating success in addressing the shortcomings of a more traditional process.  This process analysis will attempt to demonstrate how Agile development  will allow organizations to deliver projects on time and within budget, while simultaneously ensuring greater customer satisfaction.