Project Deviations Must Be Identified Before They Put Deadlines at Risk

In complex ICT projects, an emerging problem often appears as a trend of deviations from the plan rather than a missed deadline. Shifts in key activities, higher person-day expenditure, unavailable resources and unmet prerequisites may signal the need to adjust the schedule. When several projects require the same specialists at the same time, project managers, technical leads and the relevant organisational managers work together to align priorities. New client requirements must also be evaluated before being accepted, as even a minor change can require additional effort or shift related activities.

The impact on the technical solution, scope, costs, deadlines and quality is then considered, with the decision confirmed by the project sponsor. Completed implementation confirms that contractual project obligations have been fulfilled, but does not in itself reveal the benefit the solution has brought the customer. The business impact can be assessed after a period of use, through process efficiency, system availability or service quality. Veronika Petrović, Project Manager in Combis's Project Management Office, discusses early identification of deviations, resource coordination and tracking value after implementation with ICTbusiness Media – ICTbusiness.info.

What are the most important early indicators that a project is moving beyond its agreed financial, time or technical parameters, and what mechanisms are used to identify and resolve problems before they develop into a serious crisis?

The most important early indicator that a project is moving outside its planned parameters is not simply a delay, but a trend of deviation from the plan. This might be the continual postponement of key activities, greater use of person-days than planned, the unavailability of key resources, unmet prerequisites or technical challenges beginning to affect subsequent activities. That is why regular monitoring of the plan, resources, risks and open issues, together with timely communication among the project team, the client and other stakeholders, is crucial.

In practice, we have had cases where certain prerequisites were not fulfilled according to the planned schedule. We did not wait for the problem to turn into a delay for the entire project. Instead, we immediately examined which activities it affected, adjusted priorities or their sequence, and agreed with the project team what we could do to keep the project on track. Good project management does not mean there are no deviations; it means identifying them early enough to still have room to act.

How are conflicting priorities resolved when several major projects require the same specialists at the same time, while customers expect agreed deadlines, functionality and quality to be maintained?

When several major projects need the same specialists at the same time, the most important thing is to recognise the conflict early and agree openly on priorities. We consider which deadlines are critical, which activities specifically depend on that specialist, and how moving them would affect other projects.

We resolve such situations through joint coordination among project managers, technical leads and the heads of the relevant organisational units. We examine whether we can change the sequence of activities, engage another specialist or carry out some of the work in parallel. For example, if the same specialist is needed during a critical phase of two projects, we first see whether the activities can be separated in time or whether another team member can take over part of the work.

If the available capacity is still insufficient, the issue is escalated to the project sponsor so that priorities can be aligned at a level beyond the individual project. It is important that everyone clearly understands what a particular decision means for deadlines, scope and quality, and that we involve the client promptly if it affects our commitments. We cannot always avoid conflicts over resources, but we can identify them early enough and decide together where those resources are most needed at that moment.

How do changes in customer requirements affect project costs, deadlines and profitability, who makes the final decision on accepting them, and how are the consequences communicated to the customer?

Changes in customer requirements are a normal part of a project, but before accepting them we need to understand clearly what they entail. Even a request that appears to be a minor change can require additional specialist time, shift dependent activities or increase costs, thereby affecting the delivery date and the project's profitability.

When a new or amended customer requirement arises, we first assess its impact with the project team. The technical lead examines what it changes in the technical solution, while the project manager evaluates the implications for scope, the effort required, and deadlines. We then obtain confirmation from the project sponsor and clearly explain to the customer what the change means for implementation in practice — for example, which deadlines will be extended or which activities will need to be reordered.

Changes are an integral part of a project. The key is to accept them only once everyone clearly understands their implications for time, cost and quality.

How does Combis monitor project success after implementation, verify the achievement of initially defined business objectives, and distinguish formally successful delivery from the actual value realised by the customer?

Successfully completed implementation and the actual value delivered to the customer are not necessarily the same thing. We can formally consider a project successful when the solution has been delivered to the agreed scope and quality, testing and acceptance have been completed, and handover has taken place. This confirms that we have fulfilled our project obligations.

Business value can often only be assessed realistically after the solution has been in use for some time. At that point, it is no longer enough to ask whether we delivered what was agreed. We need to establish whether the solution gives the customer what the project was launched to achieve, such as more efficient processes, improved system availability, or a better service.

A project ends with delivery, but its true value is only confirmed by the results the customer achieves through using the solution.