November 15, 2002

Managing the Strategic IT Project

Sometimes, the customary big bang approach can do more harm than good

by Sanjay Murthi

Creating and deploying strategic business applications is a challenge, whether the applications involved are custom-built for your organization or based on packaged software that needs some level of customization.

In many organizations, IT is seen more as a cost center than a profit center. Therefore, the focus is on reducing costs as much as possible. In such situations, doing custom development work means a lot of money spent up front on a handcrafted solution that will hopefully work. But buying an off-the-shelf package isn't a sure way to succeed either. Those products usually require a lot of customizing and tweaking to fit the organization's needs. Sometimes, off-the-shelf packages end up being a poor fit and create a mess of an organization's operations.

The flip side is that such strategic applications are very important to the organization. When working well, they can save organizations millions in reduced operational costs as well as provide faster and efficient service to ever demanding customers.

What's the harried IT manager to do to make such strategic applications successful? In many cases, projects are undone by unexpected events and situations — for example, the application may not meet requirements, the requirements may change due to business needs, initial requirements may be unclear, or the operational changes required to use the application are unrealistic.

What managers need is a flexible, adaptable project process that can help them respond to these situations and events. So how do you build flexibility and adaptability into strategic application project management?

One Step At A Time

The golden rule is divide and conquer. Any large, multiyear or multimonth project should be broken into smaller projects of a few weeks or months in duration. Each smaller project should produce deliverables that are actually used by the organization. Traditionally, many organizations have tried to use "big bang" style approaches to deliver solutions, where the complete solution is finished on a particular date. Even if an incremental development approach is used, the intermediate deliverables aren't put into actual use.

In contrast, incrementally enhancing and producing deliverables that are actually used by customers or end users has crucial advantages. For example, on one major project that my team broke up into a set of smaller projects, we quickly found that the installation was too complex and that updates were a problem. Early detection of problems gave us the opportunity to fix them at the outset. Detecting these issues very early is one of the major justifications for producing deliverables within the iteration that are actually used by end users.

Each smaller project is still a project, however. Project management tools can be useful for planning and reporting. Keep in mind that you are trying to complete projects that are small in scope and size, so project planning activities need to shrink accordingly.

Furthermore, because you need to support requirements flexibility, you should ensure that work breakdown structures don't get too detailed. Otherwise, any changes in scope will have ripple effects that will have you spending more time fixing your project plan than working on the project. In situations where requirement changes have high probability — such as creating a new product or solution — it makes more sense to use goal-directed, time-based milestones rather than those based on a detailed work breakdown structure.

Another advantage to breaking a solution down into a series of smaller projects is that you can work with a smaller, more flexible project team. Because each smaller project in the iteration has a narrower scope, you may need fewer resources to complete it — but of course, the time available has also been reduced. This reduction in team size reduces your up-front costs, especially when people are learning to work with the tools used to build the application.

Picking Teams

Most projects go through four phases:

• Definition: Project needs, goals, and budgets are identified.
• Implementation: The solution is created.
• Stabilization: Project deliverables are tested and evaluated in real-life situations. Stabilization may also involve doing parallel runs of a new solution against an existing one to identify potential issues and variances.
• Deployment: Project deliverables go live and target end users apply the solution.

Each phase can last a few days to a month or so based on the unique needs of your project and organization. For example, a stabilization phase may just last a few days for a project that's not too complex; it could be more than a month for a complex rollout that needs extensive testing.

You should also break up your team into two groups: one for analysis, customization, and implementation, and the other to provide ongoing deployment and support. This approach helps you proceed with the next cycle of implementation while the deliverables from the previous project are being deployed.

• Privacy
• Your California Privacy Rights
• Copyright © 2008 United Business Media LLC