Use An MRD To Control Your Outsourcing

Is your software development process as unpredictable as the weather? Is your software casting a shadow causing six more weeks of programming? Are you using a marketing requirements document (MRD) or magic to predict your software release schedule?

Early in my career, I worked in a lab for a company that sold microwave devices. I was responsible for the HP computer system that ran the software used to design the circuits. One day a tech support guy from HP came by. He asked what we did in the lab. When I told him "designing microwave circuits", he said, "Oh, I hear they use a lot of FM".

I paused and tried to remember if Frequency Modulation was really used in these circuits. Before I could respond, the guy from HP continued, "Yeah, it takes a lot of F-----g Magic to make those circuits work!"

He was right. A major issue with microwave circuits in those days was creating them with a high-yield manufacturing process. Too often there was much tuning and tweaking of individual devices with toothpicks and tweezers to make shipment dates.

Since then I have worked on a few software projects where some amount of "FM" was required to get the software released.

How about your software projects? Do they drift along never seeming to finish? Do they require the heroic efforts of a few individuals to make your shipment dates?

Outsourcing can solve the issues of delayed software releases by imposing more process on your software development - more process than is typically used in an organization where everyone is working in close proximity.

Outsourcing vendors need to have a well-defined process and excellent communication to be successful. Software development is all that they do. Outsourcing not only gives you the benefit of having your software developed for less cost, but also a process that provides improved predictability, results and success.

But many remain fearful of outsourcing. The number one concern is losing control of the software development process.

One client expressed it this way. "I can't just tell the programmers what to do on a day-to-day basis. It would be like hiring a contractor to build a house and telling him to put a window over there and a door over here. You have to understand what impact that will have on the plumbing and electrical and the building of the rest of the house."

He is right. You need to have some idea of the architecture and the plan for construction. Working together with a few programmers in the same room can sometimes let you make some shortcuts and share the plan by informal word of mouth.