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.
Tuesday, December 4, 2007
Subscribe to:
Post Comments (Atom)
1 comment:
The reports I run for our facility are used to answer the "do we need more staff" question for each department. We base a lot on benchmarks and budget. I never get to hear the side of how long a new employee takes to get productive.
Our IT department recently had a mass exodus of employees. With a staff of 25 or so, I think they lost 8-10 in a year period. I'm not judging, but it had a lot to do with leadership and a quagmire of personal issues between staff.
So we are currently building, adding 2 more floors, an extension to our 1st floor, extension to an outer building, add ons to our outpatient pavilion. Just bought a new building next door, (was a funeral home, I get a kick outta that).
Combine that with a new head of our IT / Telecomm services, we have an interesting situation. Luckily, of the staff lost from that department it was some project managers and software support people, the more infrastructure people like network techs and system analysts we have are really die hard good people that know their jobs.
I never really thought about it till I read your post about how you deal with your situation. I'll be interested to see how you handle it, and will now take new interest in what our IT department is doing.
Post a Comment