Why IT and security projects stall – five problems that are rarely technical

Published 5 October 2026

Summary: IT and security projects rarely fail because the project team cannot add more activities to the plan. The problems usually start earlier: an unclear mandate, a vague target state, weak business ownership, dependencies that are never managed, and a project that never transitions into working operations. This is particularly true of security and compliance projects, where IT, management, legal, risk, procurement and the business all need to work together.

A project can have a project plan, a steering committee, its own collaboration space, a risk log and hundreds of activities. And still barely move.

The status report says the project is 72 per cent complete. But nobody can really answer what has actually improved in the business.

This is a problem we find particularly common in complex IT, information security and regulatory projects. The technology is usually solvable. The hard part is the organisation around it.

ISO 21502:2020 provides guidance on project management and is deliberately method-neutral. It sets out the concepts, practices and responsibilities for initiating, planning, directing, controlling and closing a project regardless of size, industry or delivery approach, and can be applied alongside traditional, agile and hybrid ways of working. But no method removes the need for working governance.

Here are five problems that often create considerably more friction than the technical solution.

1. The project has no real owner

There is a name under the heading “sponsor”. But when the project manager needs a decision, the sponsor is never available. Or there is a steering committee of eight people where nobody really has the mandate to decide.

That leads to waiting, escalation, more meetings and rework. A project needs someone who can prioritise, decide, resolve conflicts and secure resources.

ISO 21505:2017 on the governance of projects, programmes and portfolios is explicitly intended for governing bodies and executive and senior management who influence or make decisions about governance, and it also provides guidance to those who direct projects, such as sponsors, steering committees, portfolio owners and the project management office.

So this is not only the project manager’s problem. The project needs governance from above. A 2014 PMI study pointed the same way: actively engaged sponsors were described as the single most important driver of project and programme success, while fewer than two-thirds of projects had an assigned sponsor. The figure is not new, but the point still holds: the project needs a decision-maker with a mandate and a real ability to act.

A simple test question

Ask the sponsor: which three decisions can only you make in this project? If the answer is unclear, the mandate needs clarifying.

2. Nobody agrees on what “done” means

The project starts with: we are going to align the organisation with the Swedish Cybersecurity Act. What does that mean in practice? That all policies are finished? That all identified risks are addressed? That management is trained? That the incident process is established? That suppliers are assessed? That the organisation is ready for supervision? Or simply that a gap analysis has been carried out?

The same problem exists in IT projects. Migrate to Microsoft 365. Is the project done when the licences are bought? When the mailboxes are moved? When Conditional Access is in place? When users are trained? When the old environment is decommissioned?

A vague target state almost always creates scope discussions later. The project therefore needs to define early:

• What is going to change?
• How do we see that the change works?
• What is not included?

That is more useful than a long activity register.

3. The business does not have time to take part

This is perhaps the most common practical problem. The plan says workshop with the system owner in week 3. The system owner says it is year-end closing. The project needs HR, who have another system project. The project needs procurement, who have tenders running.

Everyone thinks the project is important. But nobody has set aside the time.

Security and regulatory projects in particular often need people who do not work on the project full time: IT, legal, data protection, risk, procurement, system owners, HR, the business and management.

The resource requirement therefore needs to be made concrete. Not “the business needs to participate”, but “the system owner needs to set aside two hours for an interview, three hours for a workshop, and approve the result by Friday”. That makes the resource conflict visible before it stops the project.

4. Dependencies are discovered too late

A project almost never consists only of its own activities.

• The Microsoft 365 project depends on the network.
• The Cybersecurity Act project depends on the supplier inventory.
• The ISO 27001 project depends on information classification.
• The DORA project depends on contracts.
• The backup project depends on storage and network capacity.
• The incident project depends on HR, legal and communications.

The problem is that the activity list often focuses on what we are going to do, and too little on what has to be true for us to be able to do it.

For each main activity, ask:

• What are we waiting for?
• Who are we waiting for?
• What happens if this is two months late?
• Can we do something in parallel?

Dependencies need to be part of project governance, not a surprise.

5. The project delivers, but nobody takes over

This is the most frustrating outcome. The project is carried out. The final report is written. The steering committee thanks the project team. The project closes.

Six months later nobody updates the risk register. Nobody follows up the suppliers. Nobody owns the process. The control that was implemented is no longer used. The documentation is out of date.

So the project delivered. But the change did not survive the project.

Operations therefore need planning long before closure. For each new capability the organisation needs to know:

• Who owns it after the project?
• How often should it be performed?
• What budget exists?
• How is it followed up?
• Which KPIs or controls are used?
• Which forum makes future decisions?

Only then does the project’s result become part of the business.

Security projects are often transformation projects

A project around the Swedish Cybersecurity Act can look like a compliance project. But in practice the organisation may need to change risk processes, supplier management, incident handling, backup, management reporting and technical controls. That is business change.

An ISO 27001 project is not just writing management system documents. The organisation needs to establish a management system that keeps working. We have written about the difference between the various forms of review in our insight on gap analysis, internal audit and pre-audit.

In the same way, a Microsoft 365 project is not just a migration if it simultaneously changes identities, devices, collaboration, information sharing and the security model.

The project manager therefore needs to understand more than the timeline. The project manager needs to understand which business capability the project is trying to create.

Project governance needs to be proportionate

More governance is not automatically better. A three-week project does not need five steering committee meetings, three status reports and an eighty-page project brief. But a complex transformation programme needs more than a Friday meeting.

ISO 21502 is method-neutral and can be used with different approaches. We think that is a good principle: the method should suit the project, not the other way round.

What does the steering committee actually need to know?

A good status report should not just say green, amber or red. The steering committee needs to be able to understand:

• What has been delivered?
• Which decisions are needed?
• Which risks threaten the goal?
• Which dependencies are behind?
• Are more resources needed?
• Has the scope changed?
• Is the expected benefit still realistic?

The steering committee’s job is not to listen to the project manager read out the status report. It is to steer the project.

Measure effect, not just activity

A project can report 14 workshops held, 22 policies written and 160 users migrated. That is relevant. But it does not always say whether the project succeeded.

A security project can, for example, also track:

• Have the identified high-risk gaps been closed?
• Do the process owners know what they are responsible for?
• Can the incident organisation use the new process?
• Have critical suppliers been assessed?
• Does the technical control work?

That shifts the focus from what the project produced to what the project changed.

Five questions before the project starts

1. Who owns the result? Not the project plan, the result.
2. What does “done” mean? Define it concretely.
3. Which business resources are needed? And has the time actually been set aside?
4. What are our most important dependencies? Internal and external.
5. Who takes over when the project closes? If that question has no answer, the project has a future problem before it even starts.

How Kristensson i Skåne can help

Kristensson i Skåne works with project management across IT, information security, cybersecurity, data protection, ISO 27001, the Swedish Cybersecurity Act, DORA, technical implementations and regulatory programmes.

Support can include:

• project initiation and scoping
• project and programme management
• steering committee support
• risk and dependency management
• roadmap
• supplier management
• workstreams
• management reporting
• implementation
• handover into operations

Our starting point is that a project is not successful because the plan turned green. It is successful when the business can use what the project was meant to create.

For larger regulatory programmes with several workstreams we have a dedicated offering in project management for regulatory programmes.

Frequently asked questions

Do you have a project that is not moving forward? Read more about our project management for IT, security and compliance or contact us for an informal conversation.

Sources: ISO 21502:2020, Project, programme and portfolio management – Guidance on project management (the current edition; a new edition is in development); ISO 21505:2017, Guidance on governance; Project Management Institute (PMI), Pulse of the Profession on executive sponsor engagement as the top driver of success (2014). Verified 9 September 2026; PMI and ISO 21502 rechecked 3 October 2026.

This text is general information. The right project governance always depends on the project’s size, risk and complexity.