Time, Scope, and Resources

Over the past few weeks, the number of new infrastructure project requests has peaked to unprecedented levels. The usual triage mechanisms described in my previous blog entry work well for applications, but infrastructure is different. Adding a new network port, a new telephone, or a new desktop is viewed a service business that can be ordered on demand, making it very challenging to say 'no'.

The sudden surge in requests re-emphasized to me the basic law of all IT projects - timeline, scope and resources are inter-related. If scope increases, timeline or resources must increase. If timeline is shortened, scope must be decreased or resources increased. Increasing scope, shortening timeline while leaving resources constant is not possible.

Of course, we can all work harder. There are 168 hours in a week, vacations can be postponed and nights/weekends filled. This works in the short term, but is not sustainable. "Lean" and "mean" organizations pushed too hard become "bony" and "angry" organizations.

New FTEs are not typically the short term answer. Getting new positions raises expectations of delivery capacity but hiring and training new staff take resources from existing capacity, so paradoxically getting new positions actually reduces capacity for a few months.

This means there is only one short term answer for unplanned, unbudgeted, unscheduled infrastructure requests - the scope of these requests needs to be reduced/phased or the time to do them increased.

For my requests this week, I've done the following
a. Assigned my staff to develop a standard worksheet which outlines the major time limiting steps (i.e. network connections take 90 days to provision) and thus specifies the minimum lead time for building IS support for a new location
b. Negotiated a change in scope with phasing - the initial request for a high bandwidth connection and new telephone system was morphed into a low bandwidth connection and use of the existing telephone system for now.
c. Reordered priorities - previous request were placed on hold in order to service the new 'once in a lifetime' opportunities
d. Asked for new staff - with the caveat that they will not add to capacity/throughput for 6 months
e. Requested governance changes - to ensure a central committee triages and communicates infrastructure requests for new offsite locations

There is one other strategy that I could employ if this surge in requests becomes chronic. In the past, I've staffed to average work load, not peak workload. This means that staff can put in extra hours for short term urgent increases in demand. However, I may have to staff to peak so that excess capacity is always available for the continuous infrastructure tyranny of the urgent I'm a frugal guy, doing a great deal on a limited budget , so I've never built in excess capacity.

As I work through these issues, I'll keep you updated on my progress.