Project model: choose the right model for your project

In this guide, you will get an understandable overview of what a project model actually is (and what it is not), how different project model types differ in practice, and how to choose a working method based on risk, uncertainty, and dependencies.

You also get a concrete plan for how to build a project model that lasts in everyday life – plus a checklist to take with you to the next project start. The point is not to “choose a buzzword”, but to choose a way of working that makes it easier to deliver value with less friction, fewer rework and clearer priorities.

In addition to choosing the right working method, it is important to know and understand both the project and what is to be achieved, as well as how the operation works and how those who will work in the project (the project team) should work to both succeed with the project and choose the right project model.

What is a project model?

A project model (project management model) is a common game plan for how you run projects: how you start, plan, deliver, make decisions and monitor impact. It describes not only what to do – but how you work when reality changes.

It's easy to confuse project models with templates. Templates can be part of that, but the reason to be careful when choosing a project model is that the project model makes it easy to answer questions like:

• What are we trying to achieve – and how do we know we are succeeding?
• Who decides when there is a conflict between time, cost and content?
• How do we handle change without losing control or momentum?

To work in everyday life, a project model typically needs to capture five building blocks. These are not “paper products” but your actual agreements about how projects should be run:

1. Phases and decision points: When do you move on, and what criteria must be met?
2. Roles and responsibilities: Who owns goals, prioritization, budget, risk and delivery?
3. Working methods: How do you plan, follow up and synchronize between teams and stakeholders?
4. Deliverables and documentation: What should be available when (for example, target image, backlog, test and training plan)?
5. Management and follow-up: How do you measure progress and impact – not just activities?

Projects are difficult and the project model is not everything

Many projects “deliver” but still leave a frustrating feeling: the benefits are less than expected, or it takes too long for the business to notice a difference. This is also why serious players have shifted their focus from “on time and within budget” to delivered value.

PMI shows in the Maximizing Project Success report that when respondents assess whether the project delivered value that was worth the effort, 48% end up in “successful”, 40% in “mixed result” and 12% in “failure”. The report also emphasizes that success is not binary but lies on a scale.

A more nuanced picture comes from McKinsey , which describes that transformation efforts have long been around 30% in success rate. BCG shows in its study on digital transformation that 70% fall short of their goals. This may indicate that the more elements of “digital change management”, the more difficult it becomes, but today most projects contain a large portion of this.

An important nuance is that projects rarely derail because of a single methodological detail. Often it is the collaboration and decision-making that determines how much friction and rework you get. PMI points out the same thing in Pulse of the Profession : organizations that prioritize “power skills”, such as communication and collaborative leadership, tend to have less budget waste in projects. In other words, a smaller portion of the project investment is lost due to poor project performance when you are strong in collaboration, communication and leadership.

This doesn’t mean you should “process everything to pieces.” It means that a good project model helps you address three common risks early on: Unclear benefits, unclear decisions, and late feedback.

9 common project models (and when they're appropriate)

In practice, you rarely choose “one model” and run 100%. You often build a combination. But it helps to know the most common types – and above all, what problems they are good at solving.

1. Phase-based project model (Waterfall model)

The phase-based model (sometimes called “waterfall”) is based on the project being run in clear phases where each step should be sufficiently clear before you move on. A common approach is pre-study, requirements, design, build, test and implementation. The strength is that it is clear what should be ready when, which can provide good control when there are many dependencies or high quality requirements. The disadvantage is that you risk getting late feedback from users if you wait too long to show working parts.

Suitable when:

• The requirements are relatively stable.
• You have clear external dependencies or regulatory requirements.
• The cost of errors is high (operation, security and compliance).

Consider:

• If users only see the solution towards the end, rework will be expensive.

2. PRINCE2

PRINCE2 is an established methodology with a focus on governance, responsibility and control in stages. It is known for principles such as working in "stages" and managing deviations via "exceptions".

Suitable when:

• You need clear governance and want to standardize how projects are managed.
• You want to be able to scale governance across many projects with common concepts.

Consider:

• PRINCE2 needs to be tailored to avoid becoming cumbersome. Use the principles and simplify the rest.

3. Agile project model - Scrum

Scrum is a framework for developing and managing complex products, with clear roles and sprints that deliver increments of value.

Suitable when:

• Uncertainty is high and you need to learn quickly.
• You want frequent feedback from users and businesses.
• Priorities change and you want to be able to adjust without losing momentum.

Consider:

• Scrum requires a prioritization mandate. Without real prioritization, it's easy to have a lot of activity and little impact.

4. Flow-based model – Kanban

Kanban is a strategy for optimizing the flow of value through a process of visualization and pull principles (meaning you only take on new work when you have capacity, instead of constantly adding more tasks). You need a common “Definition of Workflow” to be able to optimize the flows.

Suitable when:

• You have continuous work (management, improvements and teams).
• You want to increase delivery capacity without making a major reorganization.

Consider:

• The board is not the point. The point is to actually work on bottlenecks, WIP, and improvements.

5. Scaled Agility – SAFe

SAFe is a framework for scaling agile working methods across many teams, teams-of-teams, and sometimes entire organizations.

Suitable when:

• You have many teams with dependencies that need to be synchronized towards common goals.
• You need structure for planning and delivery on a larger scale.

Consider:

• Scaling reinforces both good and bad behaviors. Without clear prioritization and strategy, it risks becoming “more process.”

6. Disciplined Agile

Disciplined Agile (DA) is a “toolbox” that helps teams choose and develop a way of working that suits the context – a “Way of Working”.

Suitable when:

• You want to be pragmatic and combine methods as needed.
• You have mixed types of work (project, product, management) and want to find a sustainable whole.

Consider:

• DA requires you to make active choices. Otherwise, it's just "anything is possible" without direction.

7. The V model

The V-model connects development phases to test levels and shows how tests can be planned from the start, with a clear relationship between requirements and verification/validation.

Suitable when:

• Traceability and quality are central (for example, critical systems).
• You want to reduce late test surprises.

Consider:

• It requires discipline in requirements work and test design, but often provides better control over quality.

8. The Spiral Model

The spiral model (Boehm) is iterative and risk-driven: you work in loops where risk analysis is a central part of how you plan the next step.

Suitable when:

• The project is complex and the risks are numerous or difficult to assess.
• You need to prototype and reduce risk incrementally.

Consider:

• If you don't actively work with risk, it will just be iteration without direction.

9. Critical Chain

Critical Chain Project Management (CCPM) focuses on resource dependencies and buffers to protect project delivery dates against variation and multitasking.

Suitable when:

• Resource conflicts are your biggest obstacle (many projects and few key people).
• You want to reduce multitasking and achieve a more stable delivery rate.

Consider:

• CCPM requires clear priorities between projects. Otherwise, you are just moving the problem.

How to choose the right project model

Instead of starting with “waterfall or agile,” start by understanding your situation. These questions will often quickly clarify the choice or show you need a hybrid model:

1. How stable is the demand picture?
   If requirements are likely to change when the business sees the first version, you need iteration.
2. How much uncertainty is there in the “how”?
   When the goal is clear but the path to get there is unclear, an incremental approach is often safer.
3. How many dependencies do you have?
   Many integrations, suppliers or parts of the business increase the need for clear decision points.
4. How big is the consequence of errors?
   The higher the risk, the more you need to design in quality, testing and control – regardless of the method.
5. Do you have a mandate to prioritize quickly?
   Agile requires that someone can actually say “this is more important than that” and stand by it.
6. How will you measure success?
   If you only measure time and budget, you risk missing value. PMI's view of success as a scale linked to value is a good compass.
7. What does your ability to collaborate look like?
   If communication is weak or responsibilities unclear, build clear forums, roles and decisions into the project model.

How to build a project model that lasts in everyday life

Here's a pragmatic principle: The project model should reduce friction, not create it. You do this by being clear where needed and simple where possible.

Make governance clear – on three levels

Many problems arise when you try to control everything in the same way. A better approach is to differentiate between levels:

• Portfolio level: Prioritize the right initiatives and ensure you are doing the “right things”.
• Program/product level: Manage dependencies, roadmap, and capacity over time.
• Project level: Drive delivery, resolve obstacles and follow up on results week by week.

Create decision points that actually matter

Decision points should reduce risk and secure value. Good questions to link to your decision points are:

• Are the goals and expected benefits still relevant?
• Do we have sufficient clarity for the next step (without overanalyzing)?
• Are security, operations and integration ready for the next level of workload?
• Is the organization ready for the change (training, process and responsibility)?

Build collaboration into the model and don't see it as an "extra activity". If you want to reduce rework, you need early and regular contact with reality. It can be a demo, pilot, user test or follow-up of the effect. Make it recurring and linked to decisions.

Follow up on a few things often

It is better to measure a little and use it, than to measure a lot and ignore it. A stable minimum is usually:

• Delivery status: What was completed, what was not completed, and why?
• Risk and obstacles: What can stop the project, who owns it, when is it resolved?
• Scope changes: What has changed, and what does this mean in terms of time/cost/benefit?
• Impact indicators: What needs to be improved in the business, and how do you see it early on?

Checklist

When you want to quality assure the structure and project model before starting, make sure you can answer yes to this:

• We have defined what success is, linked to value:
  We agree on what benefit the project should create, not just what should be delivered, and how we will notice early on that we are on the right track, for example through two to three impact goals or indicators that the business cares about.
• Roles and mandates are clear, especially for prioritization:
  It is clear who gets to decide what is most important when everything doesn't get done in time. We know who can say yes or no, who owns the budget and risk, and who makes decisions when time, cost, and content clash.
• We know how scope changes are handled and what consequences they have:
  We have a simple routine for changes, how they are captured, who decides and how we assess the impact. Everyone knows that a change always involves a trade-off between time, cost, quality or benefit, and that the consequences are visible immediately.
• We have a plan for early feedback from real users:
  We show and test early, for example with demos, pilots, user tests or early operations on a small scale, so that we learn before we have time to build errors. Feedback is planned in the calendar and linked to decisions, not something you take later.
• Dependencies, risks and ownership are visible and monitored regularly:
  We have a handle on what can stop us, such as integrations, decisions, suppliers or resource shortages, and which risks are most important right now. Each dependency and risk has a clear owner and is followed up on a regular basis until it is resolved or relieved.
• We measure a few things frequently and use them in decisions:
  We follow up on a small minimum that actually drives behavior, such as delivery status, greatest risk or obstacle, scope changes, and one to two impact indicators. The point is that the follow-up leads to decisions and actions, not just reporting.
• The project model is adapted to the project's uncertainty:
  The more uncertainty and learning required, the more iterative the working method. The more stable the requirements and high risk or high quality requirements, the more phase-based and control-driven the working method.

System implementations as projects

When implementing systems, you often see the same pattern: you need both control and flexibility. Control to ensure operations, security, data and integrations. Flexibility so that user flows, routines and training needs almost always become clearer along the way.

A common working hybrid setup is:

• Clear goals and benefits map: What needs to be improved, and how do you measure it?
• Stable governance for risk and dependencies: Architecture, integration, operations and security.
• Iterative delivery of process-related functionality: Demo, feedback and adjustment early.
• Planned implementation and change management: Training, communication and superusers.
• Management rhythm from the start: So that improvements don't become "the next project".

When implementing Softadmin®, the project is typically run in three clear stages: requirements specification , implementation and further development . This means that you first get a solid foundation in needs and requirements, then a structured path to deployment, and then a solution that can continue to evolve as your business changes.

In the implementation, you want to combine clear governance with early business contact. You start by reviewing and anchoring the project plan, so that roles, decisions and priorities are clear. Then you get to see and test parts of the solution early, so that feedback from the business can guide adjustments while they are still quick, efficient and inexpensive to make.

After deployment, there is support for a period of fine-tuning, and a gradual transition to a more long-term management and development approach. Some approaches may also include operations and end-user support, which affects how you should think about responsibility, follow-up, and which decision points need to be extra clear in your project model.