One of the most important functions of an organization's IT department is its 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, and projects are increasingly becoming how they are judged on their success or failure.
IT projects can be a massive undertaking, with multimillion dollar budgets and an army of project staff and consultants that rivals a small company. With so much riding on the outcome of these projects, it's imperative that you stack the decks in favor of success.
To that effect I offer these five tips, garnered from my experiences working with companies around the world.
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, not only are you more likely to meet the stated objective of the project, but the initiative will be more palatable to the non-IT staff that are affected.
To tie all levels of the project back to the business objectives, see one of my previous articles, Is Your Project MAD?
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 in order 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 of the other is a recipe for disaster.
Decide already!
Nothing saps energy from a project like a drawn out decision-making process. When fifteen layers of management must be consulted, countless meetings held and a bevy of naysayers brought in whose only function is to quip 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.
Bring your ruler
Similar to keeping business objectives in mind at all times, 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 is 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.
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 that 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 to hiring an external entity to help vet potential implementation partners and the modicum of time and expense is obviously preferable to a costly switch down the road.
Patrick Gray is the founder and president of Prevoyance Group, and author of "Breakthrough IT: Supercharging Organizational Value through Technology". Prevoyance Group provides strategic IT consulting services to Fortune 500 and 1000 companies. Patrick can be reached at patrick.gray@prevoyancegroup.com.