As I claim in The Software Engineering Life Cycle for Outsourced Projects, Part 1, a pure Agile methodology may not be appropriate for a company looking to outsource the development of a software project. A "throw-it-over-the-wall" pure Waterfall model may not be appropriate either. I believe the best model to follow for this type of project is to take a two-phased approach.

The first phase is a definition phase, which includes close collaboration with the contract developer. In this phase the developers and business analysts (people who may work for either the company or the contractor that are required to document requirements and design) work closely with business stakeholders to define requirements, use cases, user interface designs, and support workflows. The result of this phase should be a set of models and documents such as wireframes, use case stories, or system requirements specifications.

Only upon the completion of this phase can the contract developer give an accurate quote and timeline for the development, testing, and deployment of the final solution. The cost of this first phase can be variable, as a good contractor will be contributing some of its most valuable consulting services at this time, but if the dedication from management is there to make it happen upfront, then the timeline can be kept short and contained.

If contract negotiations for the development phase are completed and the project is commissioned, then the contract developer can begin the second phase of coding, configuration, testing, and deployment. Developers shouldn’t disappear behind a wall, however. Constant, frequent review and change won’t be required like in an Agile project, but there still should be defined checkpoints and deliverables - perhaps resembling an iterative SDLC model. User Acceptance criteria and test plans (UAT) should be drawn up at the onset of development, and this should be the final gate for delivery of the project and completion of the development contract. Beyond this, the commissioning company should also have a plan for maintenance and support for the software system. If the plan is to cut the contract developer loose after delivery of the finished system, then steps should be built into the project for the proper training of in-house staff and support resources.

A company can have a software system developed for them by an outside company without dedicating their internal resources for a constant Agile process, while at the same time having confidence that their contract developer is building the system that works for them with a known budget and timeline. It simply requires an appreciation for what really is involved in a successful software project.

Jim Schweitzer is the Director of Commercial Technology Services at Vision Point Systems, inc.

The series:
The Software Engineering Life Cycle for Outsourced Projects, Part 1
The Software Engineering Life Cycle for Outsourced Projects, Part 2

For further reading:
Software Development on Handshake 2.0

In his guest post for Handshake 2.0, The Software Engineering Life Cycle, Ryan Hagan suggests that the Waterfall model for software development is only appropriate for "ordering software to see a finished project sometime in the future."

To be even able to “order” software assumes that a company must have invested a great deal of time in defining what that software should be. If a company does make an attempt to define a software system on their own without consulting with developers, then likely they have "unicorns" in the requirements spec - features that sound nice on paper and may even be possible, but will raise the complexity (read: cost and risk) to an unbearable level. This might seem on first glance as if a Waterfall approach would lead to wasted effort or uncertainty, but to me, this isn't a problem with the model itself, but with the sponsoring company's management of the initiative. 

Likewise, I don't believe that the Agile model is the answer for a project like this either. I assert that an Agile model will have two specific disadvantages for a company whose business may be in some industry other than IT. First, it can place too much demand for the dedication of internal resources for constant review and testing. Secondly, it's too difficult to set an end-to-end budget and timeline for what it will ultimately take to see a finished product. 

My company, Vision Point Systems, is a contract software and systems engineering company. Sometimes it’s like we’re mercenaries. We’ll work on software projects for other organizations who either don’t have an in-house IT/developer staff, or who need a temporary boost to support a special project. From my perspective as a contractor, there is no way that I can give a full end-to-end budgetary estimate or timeline unless the contracting company comes to the table with a really solid idea of the scope of the software system they want. 

In The Software Engineering Lifecycle for Outsourced Projects, Part 2, I lay out the model that I believe any company looking to outsource a software project should follow.

Jim Schweitzer is the Director of Commercial Technology Services at Vision Point Systems, inc.

The series:
The Software Engineering Life Cycle for Outsourced Projects, Part 1
The Software Engineering Life Cycle for Outsourced Projects, Part 2

For further reading:
Software Development on Handshake 2.0

From Jim Schweitzer, Operations Manager at Vision Point Systems:

At Vision Point Systems, we consider ourselves "language or platform agnostic."  We're software engineers who use the right tool for the job. We are not, for example, a Microsoft Partner Network company, but we hold a Microsoft Developer Network (MSDN) Professional Subscription.  This allows us to set up a lab in our office to test out the various pieces of software we write in a wide sample of target environments.

The best example of our lab in practice was for a piece of software we wrote back in 2003. Our requirements were that the desktop application run on every version of Windows from 3.11 to XP and Mac from 8.6 to 10.3. Oh, and it had to be self-contained on a floppy disk. We got it done, but it wouldn't have been without our lab of various environments in which to test. One lesson learned: Not everything that runs on a clean Windows XP install will run on a clean Windows 98 install.

Times have changed since then. We've had the opportunity, because of MSDN, to get out in front on Windows 7 a bit, having beta and release candidate versions available to us on the day they were released without any hassle. We also employ virtualization in our lab these days. We can keep pristine virtual copies of all our lab machines to load up any time we need to have a clean environment.

Here's more about what we do at Vision Point Systems:

***

Vision Point Systems is an engineering and technology consulting firm with offices in Fairfax, Virginia and the Virginia Tech Corporate Research Center in Blacksburg, Virginia.  Vision Point Systems serves clients ranging from local high-tech and non-profits, to the DOD and multi-national pharmaceutical companies. Vision Point Systems helps transform clients' tough projects into reality through thoughtful and inventive software and systems engineering.

***

This edition of the Tech Showcase on Handshake 2.0 is sponsored by Coldwell Banker Townside, REALTORS (R), a full service real estate agency specializing in Blacksburg, Christiansburg, Roanoke, and Salem, Virginia real estate and homes.  A client of Handshake 2.0, Coldwell Banker Townside, REALTORS (R) strives to be the best online source for real estate listings in Blacksburg, Christiansburg, Roanoke, Salem and all of the  Roanoke Valley and New River Valley.   Experienced agents are available to provide expert real estate advice and quality customer service. 

You're invited to view this week's featured properties, read the Keepin' It Real blog, and become a fan of Coldwell Banker Townside, REALTORS (R) on Facebook.

 From Jim Schweitzer:

Imagine this scenario: You call up your buddy on your favorite video chat software. When he picks up, you notice he's standing in front of a big painting that's filling up the background of the entire screen. Upon asking where he is, he tells you he's at a coffee shop at the mall where he is buying new artwork for the office. After a few minutes of chatting, he says he has to go and asks you to call him back in 15 minutes. Anxious to finish the discussion, you call him back and pick up the conversation where you left off. As soon as you're done, you hang up and walk down the hall to grab some coffee. Suddenly you notice your buddy sitting in his office hanging his new painting. What the heck just happened here?

This is The Cloud in action. Let's dissect the scenario.

When you clicked your buddy's name in the buddy list, your goal was to see and speak to him. This was a name-based transaction. The data, in this case, was the video and audio that made up both calls, and as far as you knew, the first call was just as valid as the second call. The Cloud is at work here - location becomes irrelevant because the reference queues (your buddy and the background view) are identical in all scenarios. In the typical Software-as-a-Service, SaaS scenario, the items held constant are the databases being accessed and the presentation of the web user interfaces, etc.

Location irrelevance is one of the foundations of the World Wide Web. Domain Name System, or DNS, exists to provide human users with name-based routing to avoid the need to access computing resources by specific addresses. In this regard, The Cloud is nothing new. The added concept is only that some businesses are deciding to take advantage of the Internet available outside their office walls for the housing of critical services that typically have been maintained in a specific location.

When is it appropriate to externalize critical IT services? Under what scenarios is it preferable to keep full control of a system in-house? These questions don't have universal answers. Businesses should conduct a risk analysis on aspects such as security, data sensitivity, performance, infrastructure, cost, intellectual property and training to determine their ideal mix The Cloud versus in-house solutions.

***

Jim Schweitzer is the Operations Manager at Vision Point Systems, an engineering and technology consulting firm with offices in Fairfax, Virginia and the Virginia Tech Corporate Research Center in Blacksburg, Virginia.

Meet Chris Burgoyne, Project Manager, Vision Point Systems:

Vision Point Systems, VPS, is a creative software development company with a proven record of delivering smart solutions that exceed the expectations of our clients.  We specialize in computer-telephony integration and custom web applications.

I've been in the New River Valley for 10 years. I came to Virginia Tech and stayed.  I am a bluegrass musician. 

The terrific thing about bluegrass jams is that I can get together with people from all sorts of really divergent backgrounds and immediately make music.  The music is something we all share and enjoy, and becomes the basis for broader friendships.

Having then broken the ice with a few tunes, I've built a great community of friends and pals, and that is what has made southwest Virginia my home, as opposed to just being the place where I now live.