10/30/2000 -- We've all been there. Having to explain why it's going to take weeks longer than expected; trying to justify more resources; begging for more cash. Of course, I'm talking about that strange animal we like to call the IT Project. In my experiences as a computer consultant, corporate IT guy and business owner, I've seen a lot of IT projects. Many of them fell victim to missed schedules, cost overruns, or unmet objectives.

It took me years to figure out and perfect the recipe for a successful IT project. But fear not. Follow the suggestions presented here, and you will find yourself on the fast track to commanding successful projects.

Ingredient #1: Project Sponsor
First, get a project sponsor on board. No, I didn't say project manager; I'm talking about the project sponsor. This is the person who ensures there is funding for the project, has the authority to make decisions regarding the project, and, most importantly, has a vested interest in its success. Without the involvement of a true project sponsor success is highly unlikely.

So where do you find this project sponsor? Start by identifying all the individuals who are pushing for the project. Hopefully, this will include at least one senior management-type person. Then, beginning with the highest-ranking person, go through the list until someone agrees to be the sponsor. If you end up with the second shift tech support analyst as your project sponsor, you probably don't have a viable project on your hands.

Ingredient #2: Group Input
Another key ingredient for success is what I like to call the project governance committee: A group of representatives from every business unit that the project even remotely impacts. The purpose for this group is to provide input and approval regarding various project items. Note that the people on this committee are not the resources that will actually be performing the project tasks. Rather, they are the ones who will help you identify requirements, prioritize tasks and garner support from the rest of the organization.

We're two-thirds through the IT Project recipe and we haven't even started to talk about anything technical yet. I know you're itching to impress everyone with your technical acumen, and you're probably thinking that this sponsor and governance stuff is all just a waste of time. Trust me on this. You'll have a lot more fun enjoying the technical stuff (and seeing a successful project develop) if you take the time to do the administrative things first.

Ingredient #3: Project Plan
OK, so you have your sponsor and governance committee together. Now you can start deploying resources and configuring servers, right? Not quite. You need a thorough project plan. This plan will articulate the three main aspects of any project: the scope, schedule and resources.

The project scope describes the work that needs to be accomplished to meet specific objectives, defined by tangible deliverables. Many IT professionals run into trouble at this point because they try to define project objectives from a technical context, when they should be coming from a business process perspective instead. Don't define an objective as, "Implement a Fibre Channel Storage Area Network" -- instead, try, "Provide Users With Increased Storage Capacity Without Degrading Network Performance." Save the technical stuff for the deliverables. It may just be that the way you will deliver increased storage capacity without degrading network performance is by implementing a fibre channel SAN.

The schedule is the time frame for the project, broken down into distinct tasks and measurable milestones. Don't make your tasks any more granular than necessary; the more detailed you get, the harder they are to manage. As for the milestones, they should be related to deliverables-if you find yourself adding milestones without corresponding deliverables, you're probably getting too detailed.

Another thing you need to include in the project schedule are constraints. Neither tasks nor milestones, constraints are those items beyond the scope of the project that nonetheless affect its schedule. For instance, allowing time in the project plan for an all-staff meeting.

The third aspect of the project deals with resources. Who will perform the various tasks, what tools will be used, and how much money can be spent? Don't forget that even for IT projects, non-IT resources will be required for tasks like purchasing equipment, preparing facilities, arranging bank financing, whatever. The governance committee can be a tremendous help in this area, not so much to do the tasks themselves (although that may happen), but to help you identify others within their departments who can.

Recipe in Action
A recent project I managed illustrates the value of this approach to project management. I was hired to take over the management of a company-wide migration from Banyan Vines to Windows NT Server that was miserably behind schedule and over budget. According to the project team members, there were two main reasons for this: the lack of support and cooperation they were getting from workers in various departments; and an ever-changing project plan (that infamous "Scope Creep").

So the first thing I did was to gather the project team together and ask them who had ultimate signing authority. No one could give a straight answer. I went to the IT Director and told him that I couldn't address any problems or work on any tasks until a project sponsor was identified. As it turned out, the vice president of technology was one of the folks who were behind the migration. We approached him and got his commitment to sponsor the project.

Next, I had my newly appointed project sponsor send out an e-mail to every department head asking for governance committee representatives. The committee was formed, and we got together to nail down a list of objectives, constraints and available resources, from which I was able to create a high-level project plan-with every committee member's signature of approval.

After that, I met with the project team and we fleshed out a more detailed plan, incorporating the constraints identified by the governance committee. We had a realistic schedule, a good handle on the costs, and we knew who would be available to assist us from other departments. As we moved forward with the plan, we encountered some of the same issues as before. Only now we had the full support of a project sponsor and governance committee and a clearly defined project plan. It wasn't an "us vs. them" scenario anymore.

Do all these project management best practices preclude the necessity for solid technical skills? Of course not. You still need to know how to build that fibre channel SAN. But building that SAN should be your biggest challenge, not convincing accounting to pay for it!

I would love to hear about your IT project adventures, good and bad. Drop me a line at .

What do you think of Kevin's tips? What do you do to keep things on track? Post your thoughts below.