Leadership

Visualization is key to IT project success

Jay Rollins discusses the importance of knowing exactly what is needed for an IT project to succeed and being prepared to fight for it.

Many an IT career has been built on a portfolio of projects. Some CIOs focus on big, tactical projects like network refits; others concentrate on the transaction and making the core business run more effectively; while others tackle the big, game-changing projects that help steer the business in new directions. Although I recommend a good mix of all of these project types, the base criteria for success, regardless of the project type, is hitting the measures spot on.

The trick is to understand exactly what you need to succeed and stick to it, no matter what. I'm not talking about a little budget cushion here and an extra resource there; you must have a clear picture of what is needed to succeed.

During a project, all kinds of forces come to bear to derail your project; the Universe sometimes seems to be out to destroy it. But at the beginning of the project, there was a vision that started the ball rolling. Many times, that vision is a bit more than the requirements that are captured on paper. The bottom line is, when the project is done, there are expectations as to what new capabilities should be available to the organization. We always hear about managing expectations, but all the expectation management in the world cannot change expectations. We can say that this scope change will result in this lower level of functionality, or this schedule change will eliminate this important feature. But how key are these functions and features to achieving the vision and meeting expectations?

I've known several project business owners who thought the organization would see them as more of a hero if they delivered a project well under budget or way ahead of schedule instead of delivering a product that met the original vision and expectations. The term "good enough" will start creeping in to project status meetings. Beware of these business owners because you truly do reap what you sow. They may be the project stakeholder, but we have all seen or read about enough money-pit software projects to know better. And doing the "I told you so" dance after the fact is just not an option. This approach does nothing to fix the situation. Remember, if the project fails, you are still associated with it.

Here are a couple of steps to try and get the project back on track to achieving the original vision and meeting or exceeding expectations:

Be the grown up.

Confront the business owner and bring every example of failed projects due to budget saving or schedule acceleration you can think of to the table. Make sure she understands you are not talking out of your hat. You also need to demonstrate that you are not afraid of a little challenge, but reality is reality.

Hold regular project status meetings or IT project portfolio steering committee meetings and voice your opinion.

Tell the business owner ahead of time what your opinion is so she is not surprised; also, make sure upper management understands your position. Articulate the risks in terms such as, "Without this feature, the business case cannot be met," or "Without this feature, the ability to achieve this portion of the vision will not be present." Keep to the high road, but make your opinion known. Do not use this opportunity as a Pearl Harbor file or future disclaimer. Management needs to see if these are actual concerns, or you just don't have the intestinal fortitude to persevere.

If all else fails, do what you can legally, non-politically, and ethically to kill the project. If the project continues in this direction, you can foresee the outcome -- nightmare support scenarios, screaming mad users, and the Universe generally being mad at you. Not to mention the gigantic sucking sound coming from the company coffers.

If the business owner decides to continue with the project, attempt to use a "Get out of jail free card" and get far away from the project. But you must be certain that the project will fail; if it succeeds, you'll look terrible.

If you choose to stick with the project, be sure you're prepared for IT heroics -- working late nights, visiting the family one weekend a month, and sleeping under your desk will be requirements. Make sure upper management sees these heroics at every turn (without bragging) or else you'll come out looking like a doomsayer and become marginalized later on when voicing similar concerns.

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!
1 comments
Anita Y. Mathis
Anita Y. Mathis

Great article. "But at the beginning of the project, there was a vision that started the ball rolling. Many times, that vision is a bit more than the requirements that are captured on paper. The bottom line is, when the project is done, there are expectations as to what new capabilities should be available to the organization." It seems very easy to gather only the functional requirements and not have the vision associated with the project. In textbooks, they speak about the brainstorming sessions and kickoffs and such where basically everyone is involved. I don't know how often this happens in real life.

Editor's Picks