To clarify, I'm not talking about IT infrastructure projects - these should continue. Hardware ages and should be replaced, security can always be tightened, and much can be gained from virtualization. But other projects - to buy or build new applications, upgrade packaged ones, and retire legacy systems should be stopped, or, better yet, never started. Let me explain...

There's a long-standing tradition of budgeting for IT projects through some prioritization process. But whether this process is simple and informal, or analytical and complex, if it ends up funding "IT projects", it's intrinsically flawed.

The flaw of this approach is that projects are focused on specific IT solutions (typically a system), which are nothing but a means to some business objective. And while this business objective might get defined in a project's business case, it remains obscured by the project's focus to "deploy system ABC". A better way to define an initiative is by identifying a business process it is set to improve. For example, if you launch an IT project to "Implement Call Center Software", its focus will be on configuring that application to requirements gathered from various business stakeholders. The resulting solution will likely closely match the existing process, while solving some of its pain points and gaps in process automation. But if, instead, you scope an initiative for "Optimization of customer support", the project will first analyze the current as-is process, followed by a design of an improved future to-be process. This to-be process will almost always require some improvements in automation, which will form the scope of IT delivery. However it will also contain other elements focused on process and organizational change management that have no relationship to IT, and that need to be tackled before IT changes are considered. Such business-focused process improvements are often more effective and valuable than the gains delivered by IT automation, yet such improvement opportunities are usually overlooked when enterprise evolves through "IT projects".

This alternate approach to corporate projects reaches far beyond their re-labeling. It requires a change in methodology, where focus shifts from requirements gathering and system specifications to process analysis and optimization. This change doesn't mean, however, that IT has a lesser role to play in projects. Sitting in the middle of all cross-functional intersections of the business, IT teams are most suited to act as unbiased facilitators and mediators between various functional departments. Moreover, IT is frequently the only team that has a staff of analysts and project managers dedicated to running corporate initiatives and skilled at problem solving and uncovering dysfunctions of the status quo. However, this approach requires a change in the mentality and authority of IT staff, where it's made accountable for facilitating and driving optimization of the business process, including improvements that don't require IT automation. At the same time, companies that employ Six Sigma and Lean teams dedicated to process improvement, are well advised to consider their formal or matrix integration with the IT's project factory. Just like IT goes wrong by focusing on delivering systems and ignoring process improvement, the dedicated process improvement teams tend to tweak low-level processes, while ignoring automation possibilities and broader interdepartmental process dysfunctions.

Next time you're getting ready to launch a system implementation project, consider packaging it as a process optimization initiative. Task your project team with specific process performance metrics they must improve - no matter if the means for doing so involve automation or not - and empower them to make both business process and system changes. If you find that this process-focused approach works in your environment, you won't ever launch another "IT project" again.

Dennis Korevitski is a Director of Information Technology for SonoSite, the world leader and specialist in hand-carried and mounted ultrasound, headquartered in Seattle, Washington.