One of the most important functions of an IT department is the ability to successfully implement projects: fixed duration activities with a specific result. Most IT leaders have realized that the commodity functions of IT, like keeping the network up and the servers humming, are now a baseline expectation. Projects are increasingly becoming how they are judged on their success or failure. Here are some tips to help you stack the deck in favor of success.
Note: These tips are based on an entry in our IT Leadership blog.
1: Remember that IT projects don’t exist in a vacuum
From the technical nuances of the software and hardware involved to complex interactions between affected business units, most IT projects are awash in details. It’s easy to become mired in these nuances and forget that at the end of the day, every IT project is tied to a business objective. That objective might be straightforward, like implementing server consolidation to cut costs, or it may be more cerebral, like implementing a business warehouse to provide detailed market analytics and help your company enter a new market.
Whatever the objective, if you keep the business goals at the forefront of every discussion and frame any technical or project discussion within them, you’re more likely to meet the stated objective of the project, and the initiative will be more palatable to the non-IT staff who are affected. To tie all levels of the project back to the business objectives, see Is your project MAD?
2: Implement processes, not software
Most business software applications assume a corresponding process. From a complex ERP system that dictates a recommended approach to everything from issuing invoices to running payroll to online publishing tools that expect a defined series of steps to be followed, you often buy into the process associated with the software just as much as the software itself. If you’re cognizant of this fact, you will expect and plan for process changes as you implement the software rather than applying layers of metaphorical duct tape and bailing wire to a package to support a “my way or the highway” approach that has killed many a project. During the software sales cycle, the process and “way of doing things” that the software assumes are just as important as the pretty screens and fancy features. Thinking you can drastically modify one or the other is a recipe for disaster.
3: Decide already!
Nothing saps energy from a project like a drawn-out decision-making process. When 15 layers of management must be consulted, countless meetings held, and a bevy of naysayers brought in whose only function is to tell you why”That will never work,” you are destined to failure. Before starting a project, define how critical decisions will be resolved, who has decision-making authority, and what the timeframe is for critical decisions. It is better to make an imperfect decision that moves the project forward today than to spend months vacillating and pontificating while time and money fly out the door.
4: Bring your ruler
In the beginning stages of the project, determine what objectives are critical for each phase of the project. Some objectives are more important than others, just as some scope items may be absolute requirements while others are nice-to-haves. By making these decisions early, it’s clear when the project moves from one phase to another or is at risk of failure, since the criteria are known in advance and not subject to frequent revision in later phases of the project. Defining exit criteria for each phase also avoids the tendency to rush initial phases of a project and roll work into a future phase — an attempt at paying tomorrow for what you can’t afford today.
The earlier you can define your “ruler,” the more likely you are to make calm and reasoned decisions that can be relied upon during the heat of battle later in the project. This also provides a benchmark of how closely a project adheres to the original objectives, avoiding the risk of changing scope and compromising requirements to the point that you successfully implement something that does not meet the right objectives.
5: Partner wisely
Implementation partners are a critical piece of any IT project — perhaps even more so than the software and hardware at hand. Choose a partner that has a good organizational fit with your company, experienced people, and high-quality references. Ignore endless trumpeting of a particular “proprietary” methodology (they’re all pretty much the same), resumes of people who might soon become “unavailable,” and glossy proposals that spend hundreds of pages talking about how great the implementation partner is rather than detailing how they will help solve your problems. If you have any doubt, there is no shame in hiring an external entity to help vet potential implementation partners. The modicum of time and expense involved is obviously preferable to a costly switch down the road.