Saturday, June 21, 2008

Real world example of scope creep

Scope creep is defined as the tendency of a project to grow in scale and complexity as more individuals get involved. It also occurs as the details of the project are presented to the project owners who requested it, usually management, who then say, "Can you also make it do this or that?" Let me give you an example that happened to me just the other day.

I am the IT Manager for a private jet charter management company. Several years ago we added Boeing Business Jets to our fleet. These are larger than the Gulfstream aircraft which comprise the majority of our aircraft. A BBJ is a 737 that is tweaked out with tens of millions of dollars worth of custom mods that make it into a flying luxury yacht for the very wealthy.

Of course a bigger aircraft requires a bigger hangar. So we built one. No, it's not a simple project. It requires a lot of environmental approvals and just the right touch with the airport authorities. An older and smaller hangar was purchased and demolished and the new one has been rising in its place over the past year. It will house the BBJ and two smaller G550 aircraft.

Getting the details defined

From day one I offered management my assistance in defining the network and communications requirements. "No thanks", I was told. "The building contractor has that all taken care of." I sensed trouble and kept following up with occasional emails over the past year asking specific questions like how they would like our sites connected and what the phone system would be.

I confess I played CYA with these emails, documenting each offer of assistance with specifics of what would be needed to make it all work - switches, routers, VPNs, PRIs, VoIP phones, wireless access points and a domain controller for local authentication and file replication. I suspect that the verbiage about wiring closets and cross connects just went over their heads.

This week I received a call from one of the subcontractors wanting to know how many network drops were needed and where exactly they would be going. Did I freak? You bet I did, but I managed it in a very professional way. It was obvious that the contractor had failed in planning properly for all the electronics involved in the new building. Has this ever happened to you?

Managing an out of control project

I told the wiring contractor I would get back to him. I fired off an email to the site project manager, an employee of our company, notifying him of the situation. He assured me that they had provided all the necessary details to the general contractor and it was all included in the plans. Somehow copies of plans don't always make it down to subcontractors, do they?

Next the phone contractor calls and asks, "Where is the MPOE?" There is no physical wiring from the phone company in the building yet. "Let me get right back to you on that," I respond. Is it panic time yet? The building is supposed to be occupied in sixty days and they haven't yet arranged for voice and data to the outside world. Oh, and no phone system has been chosen.

That's it. I call for a general meeting with the contractor, the project managers from all sides and the subcontractors. It turns out the project manager from our company simply had no clue about networks and phones. He thought the contractor had it all handled. I shake my head in amazement. How can you build an expensive hangar and not plan for the damn network?

Here's where the scope creep occurs

During the general meeting to resolve the network and phone issues, the various kinds of phone systems are discussed. I notice out of the corner of my eye that the VP who's baby this is begins to look uncomfortable when we get close to finalizing on a stand-alone VoIP PBX. "What's the matter?" I asked. "Can I pick up the phone and call an extension back at the main office?"

Our existing phone system in the main hangar is twelve years old. It does not even support a PRI (T1). It also does not support remote locations. A single building wiring project just turned into a multi-building job. New phone system for both buildings and new wiring in the old to support VoIP. I was looking for a good reason to upgrade. Its funny how things work out.

Now I have to sell it to the CEO. "What! You want to spend $60,000 on a phone system for this building? We only have a few employees in the new hangar. Why do we have to replace the phone system here?" Ah, the joys of being an IT Manager. If only someone had listened to me from the beginning, this could have all been planned for and budgeted. Now it's a shock to all.

Summary and conclusion

You can draw all kinds of conclusions about how poorly this project was managed. I'll point out one right away - poor communications. But, I've got to tell you after thirty years in this business that this is not all unusual. I've just never seen it happen on this large a scale before. CEOs and VPs are busy with their day to day tasks. Delegating everything without follow-up doesn't work.

In addition to poor communications, the details were undefined in advance. Nobody knew what kind of phone system was wanted or needed. Nobody knew or asked how we would connect our two networks. Wireless access was not even considered. The subcontractors are now overjoyed because they get to sell us a whole lot more equipment than they thought when they were hired.

It all works out in the end. It's only money, right? Unfortunately, it's all too typical of how some large successful companies run projects - everyone likes to delegate but some decisions will always need to be made near the top. That's called leadership but it's hard work because it means dealing with uncomfortable details. After all, that's what IT Managers are paid to do, right?

Monday, June 2, 2008

Tech Republic posts for May 08

Blogging at Tech Republic was a little light this past month. I have gotten myself deeply involved in a disaster recovery planning project that is taking a lot of my time and energy. The project will in all likelihood exceed $100,000. The hardware is looking to be about $60K or $70K. I'm looking at several outside companies to provide the DR planning expertise.

We are looking at implementing Virtual Server technology at either the remote site or back in the main office and then grandfathering the old servers to the remote location. We are experiencing scope creep and considering upgrading our Exchange Server to 2007 in the process. This is quickly becoming a very complex project but I'm enjoying managing it.

Num

Date Posted

Title

1

2008-05-09

Fire suppression for the server room

2

2008-05-10

Setting up a remote hot site

3

2008-05-30

I only read the stories for the comments

4

2008-05-30

New user guide to TechRepublic


I'll confess here that perhaps the real reason blogging on tech Republic has been light is because of the "attack and castigate" mentality of some people who read and comment on blogs. I wrote about it on post number three on the list above. It seems to be so prevalent on many forums and blogs today. It's as if a reader feels that they must challenge whatever the writer presented.

It takes all the fun out of blogging. It has made me seriously think about bringing my blogs back from Tech Republic to my own blog. Here I can write in a bit more relaxed manner, simply sharing some of the things I learn and discover about disaster recovery or any other project I am working on. If it's not interesting, you don't have to read it, but it helps me to write about it.