Critical path analysis is one of the most common techniques that IT project managers use. By using procurement software to create a work breakdown structure (WBS) of all the tasks required, the project manager is able to work out the total time it will take to deliver the client's requirements, accounting for all the dependencies and constraints that exist between tasks. Critical path analysis is an essential part of the project workflow planning process, and a lot of IT projects fail because of fundamental errors in this process. Learn from the mistakes of your peers, and find out more about four critical path errors that threaten timely project delivery.

Overlooking or ignoring constraints

Every critical path faces constraints. Some constraints mean that it's not always possible to start work on a task, even if the necessary resources are available. For example, if you calculated the critical path for a project to paint a fence, you would consider the time it takes to do the work, but you would also need to consider constraints. You may need paint that takes three months to order from a factory, or you may have to work within certain working hours because the paint doesn't respond well to bright sunlight.

IT project managers need to understand and account for these constraints to accurately account for the critical path. Ignoring or missing these constraints can place considerable strain on the project, and you may even need to stop work. Common constraints that affects IT projects include:

• Access to skilled business resources (for requirements planning or testing)
• Time zone differences when using outsourced developers
• Order lead times on hardware and infrastructure

It's important to spend time at each stage of the project reviewing the critical path, and spotting any new constraints. Consult the relevant subject matter experts to make sure you don't miss crucial limitations.

Working to a fixed end date

In many cases, companies set fixed end dates for IT projects. For example, if a change in regulation means that you need to update your systems by a particular date, project managers will need to develop a plan that helps the business meet this requirement. The challenge is that the true critical path might make it impossible to meet this date.

When analysing the critical path, project managers must accurately consider every task, dependency and constraint. Project managers must also make accurate estimates of the time it will take to complete the work. In some cases, IT project managers simply shoe horn tasks into unrealistic durations because their clients need them to meet a date.

In fact, project managers must first assess the true critical path. If this means the work cannot (at face value) reach completion before the target date, project managers can then talk to the client about opportunities to change the approach. For example, an increase in budget could release more developers, which could halve the task duration at key stages. Nonetheless, the starting point must always reference the true critical path, or the project manager is setting the project up to fail.

Managing tasks by percentage completion

Project management software often allows project managers to update the plan to show the percentage of work completed by task. This is a useful visual representation, but this method is not a good way to manage progress. A developer may have completed 90 percent of a task, but if the remaining 10 percent is complex, he or she may still not deliver on time.

To manage project progress, IT project managers should continue to understand if the task owner will complete the work on deadline. RAG status reporting is generally an effective way to do this, as the process allows project managers to focus on the at-risk (red) tasks.

Assigning tasks that are too long

It's vital to include accurate estimates of the time it will take to complete a task in your plan, but it's also important to work with manageable durations. If you expect a task to take a week, it's easy to quickly check if the work is on schedule because the duration is short. Lengthier tasks are more risky. For example, it's often more difficult for a developer to decide if he or she is on track with a task that you expect to take three months.

In these cases, it's often worth breaking long tasks down into smaller chunks. For example, if a developer needs to write code for a new website, you could split the work into logical phases, which last one or two weeks. In this way, you can more easily and accurately work out if you are going to meet the critical path. You can also respond to delays sooner, which gives you a better chance of getting the critical path back on track.

For any IT project, it's almost impossible to accurately plan and measure progress without critical path analysis, but it's important to use the technique in the right way. In some ways, an inaccurate or incomplete critical path is no better than working without any critical path analysis.