For any project, the first step towards success is recognizing that it needs to be planned out. The goal of this early phase is to ensure that all parties have a common set of expectations for the project and that the appropriate resources have been allocated. It’s very tempting to jump straight into implementation once a new technology has been identified that could benefit the company, but the risk of some failure during execution is high in this case. It’s completely appropriate to run a brief trial or pilot phase to test out assumptions, but it should be very clear from the outset that this does not represent the final rollout.

The first priority is to get an agreement between the affected business departments and IT on the goals of the project, and to set expectations on what can realistically be achieved. This is challenging in two dimensions. First, it’s common for the IT department to have trouble communicating in a way where the business really understands IT’s intentions. Technical jargon frequently gets in the way. Second, it’s easy to underestimate how much effort is required if a business process will change as a result of an IT project, especially if the process touches external customers. It’s a common assumption that implementing a particular software package will automatically result in some kind of best practice, but this typically isn’t the case.

The second priority is to hammer out the scope of the project in detail. It’s easy to miss this step in the rush to get into design decisions, but this is where cost control starts. Many cost overruns result from scope creep, small additions to the project made without explicit authorization until the project ends up being much bigger than originally budgeted.

The third priority is to build an implementation plan. At a task level, IT projects are notoriously difficult to model because tasks typically don’t have concrete dependencies the way that, say, construction projects do.  In IT projects, typically tasks have a finish-finish type dependency (i.e. one task can’t complete before another task has completed), rather than a start-finish dependency. The happiest medium is to at least try to define tasks so that each task is approximately two person-weeks of labor. Much more than this and tasks become hard to track. The resource plan is arguably the most important part of the plan. The timeline will be meaningless unless internal resource requirements are understood.

One final thought on project setup and planning: It should be part of a company’s culture that it is okay to cut or postpone a project at this stage. If the planning shows that the risk is too high or the resource requirements too burdensome, this is the cheapest time to cut the project. If projects are regularly cut during implementation it is a symptom of incomplete project planning.

Next step: See our post about ensuring a successful project implementation through the right processes, tools, and organization.