Before going on a long journey, most of us like to plan the route, identify potential obstacles, and decide how to deal with them. Arriving at the right destination all in one piece is determined in large part by knowing where you’re going and how you plan to get there. Planning security for a new technology project is not very different.

Not too long ago, Pete, Acme Health Care’s security manager, was involved in a “pilot” project which included deploying tablet PCs to a large number of mobile users. When the project started, Pete thought he understood where the project manager and the project sponsor were leading the team. It quickly became evident he was mistaken.

Each week the functional requirements changed. The functional requirements changed because the final destination (i.e., business objectives) moved from one set of goals to another. As the goals and requirements changed, so did the infrastructure and security design requirements.

One week the tablets were to be single-purpose systems. The next week the business users claimed Web browsing and wireless access was critical, no matter where the tablet found itself. The requirements and business objectives shifted so much over the first several weeks of the project Pete needed motion sickness meds just to stay in his chair.

Finally, senior IS management called a meeting to clearly define the pilot’s destination. In fact, the pilot turned out not to be a pilot at all. It was a proof-of-concept to see if tablet deployment would reduce care delivery costs. Once the destination was clearly defined, functional requirement definition followed quickly. Security and infrastructure design completed the work necessary to begin building the solution. The destination remained constant thereafter, and so did Pete’s designed-in security controls.

Unfortunately, this isn’t an unusual occurrence across business environments. In addition to driving infrastructure solution designers nuts, not understanding the what’s and why’s of a solution often causes security controls to be thrown at the final design as it passes by on its way to the project’s build phase.

If you ever find yourself in a series of meetings like those Pete experienced, ask whether an actual set of business objectives exists. If it doesn’t, if the journey’s destination is not defined, strongly recommend pausing requirements definition while the team goes back to step one in the project lifecycle.

Now where was I…? Oh yeah, you guys start coding while I go find out what the customer wants…