|Lawrence Oliva, PMP|
Emergency IT project strategy requires fast and highly reactive responses, often with high expenses and substantial risk of failure. A scheduled IT project strategy follows a different path, with a formal methodology, detailed budget estimates and schedules and a lower risk of failure.
The typical IT project management strategy has five core elements:
5) Return on investment (ROI)
Core elements of emergency IT projects
Mission: To very quickly devise and implement solutions to secure the health and safety of people, protect public infrastructure or equipment, or remove serious product defects.
Strategy: To strip out and exclude all nonessential work activities in favor of a narrow set of actions or deliverables that resolve the most critical problem.
Resources: Should utilize the most aggressive technical approaches available, combined with the assignment of highly skilled and experienced technical resources.
Time: Activities are planned to run in parallel to reduce the overall completion time. All tasks are scheduled around a 24/7 timeframe.
ROI: Calculated on the value of the cost reductions, property protected or life-saving results obtained from the emergency actions.
Core elements of scheduled IT projects
Mission: To build, test, deliver and support a product that saves time, reduces cost or otherwise adds value for its users.
Strategy: To obtain requirements from intended users of the product and purchase or build tools that support the largest number of requirements within the approved budget and schedule.
Resources: Should utilize a diverse set of technical talent, balanced with different cost points and schedules as needed to achieve client expectations for scope, budget and schedule.
Time: Work is planned to minimize overtime cost while achieving completion on schedule. In general, work is not scheduled during weekends or holidays.
ROI: Calculated on the financial value received from the implementation of the products.
Actual experience indicates that in the IT business, true emergencies are a very small percentage of the overall number of projects started and funded. Thus it is surprising that emergency response strategies are applied so often, due to incorrect or incomplete assumptions about available time, project scope, required resources or the expected deliverables. Project managers and technical managers -- personally stressed due to staff downsizing and often leading multiple projects -- often rush from "fire to fire" without stopping to get enough information to understand what the new problem really is, leading to a surge of emergency projects.
Diverting technical resources which were originally assigned for a scheduled project to an emergency project often results in the failure of both projects. The scheduled project suddenly has insufficient resources, and the emergency project does not have resources trained with the appropriate (fast and reactive) response methodology. All technical resources are not equal in value for every situation. They must be matched with the methodology, speed and intensity of each assignment.
Relying on gut instinct to develop a project plan may make sense when the extra resource costs are small, or the situation is a true emergency, but it is almost always better and cheaper to apply planning processes when the costs are high. It is typical for a medium-sized (50-person) scheduled IT project to spend $30,000 to $40,000 per workday on salaries, facilities and equipment expenses. Emergency projects, as you might expect, can cost two or three times that amount per day.
Given the cost and impact of making the wrong -- or at least very expensive -- decision, taking a few extra hours to understand the problem can make a big difference in deciding which strategy to apply to a specific situation. And while cost management is a critical element of IT project success, management and clients are really focused on getting the project completed. After all, if the project is being funded, the organization does expect to receive the planned benefits or costs savings.
After reviewing the situation, follow this recommendation: Blend elements of each strategy (emergency and scheduled) together to give you the best of both IT project response strategy types.
For example, when asked to accelerate the project completion date, narrow the project scope and reduce the deliverables to just one or two instead of five or ten. The end result will profit from the intense mission focus used by emergency project teams, with the added benefits of a reasonable budget, a lower failure risk and a planned schedule.
Consider using a project scheduling package like MS Project or Primavera to plan activities in parallel (rather than sequentially) to save time. Software verification activities that take many clock hours can be scheduled across weekend or holiday times, using underutilized computer capacity and irreplaceable schedule time.
When asked to manage a project bloated by cost and schedule overruns, sort the deliverables into several versions, including one that can be delivered quickly (consider it an "emergency"). Delivering a polished and finished product that lacks some features on schedule at an attractive price point opens the way for a follow-on version.
Version 2.0 can have new requirements defined, features expanded and performance levels improved. Marketplace success with version 1.0 also enables external revenue to be generated, or costs to be saved -- which can fund the next version. Being able to attain cash through self-generating sources is a huge advantage over a development team that has a two-year development cycle funded through a fixed budget from the "corporate" offices.
Organizations that survive today's economic downturns will show flexibility in using the technical resources, budgets and processes they have to develop the desired -- or required -- price points and products for their customers. In these difficult times, agility and adaptability quickly overtake historical reasons and traditional processes. Creating and implementing a focused IT project strategy can make the difference between success and failure.