The 'define, design, build' approach

One of the most important and complex things an IT professional is called on to do is implement new systems. This runs the gamut from rolling out packaged applications to creating custom systems.

In any systems project, there are technology issues (over which I have a lot of control) and a host of other issues that fall into the categories of people (meaning politics) and process (meaning getting people to do things in new ways). I have no control there. All I can do is exert constructive influence.

I use a basic three-step approach that works for any system implementation project. In the first step, called "define", I deal with the people and political issues. I get the executive sponsors to state clearly what they want and what the performance requirements are that the system must meet. Then we agree on a conceptual or high-level design for a system that meets these requirements. I estimate what it will cost, and if the sponsors decide that the benefits of the system still outweigh the costs, then the project moves on to the next step.

That's "design", when the process issues are worked out. Business people who will use the system work with technical people who will build it. We figure out new workflows and ways to use the technology to meet performance requirements. If business and technical people are still talking to one another and smiling at the end of this step, it means we have produced a good (or good enough) design that will get the job done.

"Build" is the biggest and most expensive step but actually the least risky. Problems will arise, but they will be technical, not political or procedural. Technical problems have technical answers. They are easy compared with political and procedural problems.

Michael Hugos is CIO at Network Services and author of Building the Real-Time Enterprise: An Executive Briefing (John Wiley & Sons, 2004)

Join the newsletter!

Error: Please check your email address.

More about John Wiley & Sons Australia

Show Comments