If you dig into almost any organisation's project portfolio, you'll find a surprising pattern: a large proportion of projects are variations of projects they've already done before. Same structure, same phases, same types of tasks — adjusted slightly for client, product, or scope. This isn't a flaw. It's a massive, mostly untapped opportunity.
The problem, as Henning Christiansen argues in Project Management: The Red Pill, is that most organisations fail to capitalise on this pattern. Instead of building reusable project management templates, teams rebuild from scratch every time — repeating the same manual processes, rediscovering the same risks, and wasting time that should be spent on the work that actually creates value.
Project Management - The Red Pill — Henning Christiansen
A no-nonsense guide to the human and organisational realities of project delivery. Chapter 14 on templates and Chapter 7 on project models form the backbone of this article.
What Is a Project Management Template?
A project management template is a reusable framework that captures the structure, phases, tasks, time estimates, dependencies, and skill requirements of a recurring project type. It's not a document — it's a working model of how a particular kind of project gets done.
Good templates encode your organisation's accumulated knowledge about how projects run: what order tasks go in, which tasks depend on others, which skills are needed at which stage, how long things typically take, and where things usually go wrong. Every time a new project of that type starts, the template gives the team a tested, structured foundation to build from — rather than a blank page.
A checklist tells you what to do. A project management template tells you what to do, in what order, who should do it, how long it should take, and how it connects to everything else in the project. The difference is the difference between a shopping list and a recipe.
Why Organisations Resist Templates — and Why That's Costly
Christiansen identifies a revealing organisational dynamic: in environments where the same projects repeat regularly, two forces conspire to prevent standardisation.
First, the people who benefit most from inefficiency — the Chameleons and Roosters who use project complexity to create visibility and protect their turf — actively resist processes that would make their contribution less central. If a template makes a project straightforward, there are fewer opportunities to be the hero who solves the problem that only they understand.
Second, ordinary workers are simply comfortable with familiar patterns. They know the shortcuts, the unwritten rules, and how to avoid friction in the current system. Changing that requires effort they don't see the point of.
"If you dig into an organisation's project portfolio, you will often discover a surprising number of similarities between projects. This is not a flaw, it is an opportunity. It reveals huge potential for standardisation, reuse, and error-proofing."
— Henning Christiansen, Project Management: The Red PillThe result is organisations where teams continue rebuilding similar plans from scratch, project after project, at enormous cumulative cost — while telling themselves that each project is too unique to standardise. In most cases, that's simply not true.
The Anatomy of a Good Project Template
Christiansen's project model framework — the foundation for any Proglar template — is built around three fundamental elements. Every model, and therefore every template, is defined by these components:
This structure is what separates a genuine project management template from a simple task list. A task list tells you what to do. A model-based template tells you why each task exists, what it needs, what it produces, how long it takes, and what breaks if it's delayed or changed.
What a Project Template Looks Like in Proglar
In Proglar, a project template is a saved project model that can be launched as the basis for any new project of that type. Here's a simplified view of what a software development project template might look like:
When a new software project starts, the project manager launches this template and immediately has a complete structure: every phase, every task, skill requirements, time estimates, and phase assignments — all ready to adjust for the specific project context. What used to take days of planning takes minutes.
How to Build a Project Management Template
The best templates are distilled from real projects — not invented from scratch. Here's the process that works:
The Key Distinction: Production Projects vs. Innovation Projects
One of Christiansen's most useful ideas is the distinction between production projects and innovation projects. This distinction determines whether a project is a candidate for templating — and prevents the most common objection to standardisation.
- Solving genuinely new problems with no established solution
- High uncertainty about approach and outcome
- Require creativity, experimentation, and iteration
- Cannot be fully templated — need flexibility
- Examples: new product development, R&D, strategic pivots
- Repeating a known process with minor variations
- Path to completion is understood from previous experience
- Require discipline, consistency, and efficiency
- Strong candidates for full templating
- Examples: client onboarding, feature releases, reporting cycles, regulatory submissions
Treating every project as if it were an innovation project — and therefore "too unique to template" — when most are actually production projects in disguise. This keeps teams rebuilding from scratch indefinitely. Distinguishing honestly between the two is the prerequisite for any templating effort.
The true purpose of templates, as Christiansen puts it, is not to eliminate innovation — it's to identify which projects don't require innovation, so those can be made efficient, freeing up creative energy and budget for the work that genuinely requires it.
Templates as a Defence Against Scope Creep
One of the less obvious but highly valuable uses of a project template is as a structural defence against scope creep — the gradual expansion of project requirements that derails more projects than almost anything else.
When every task in a template is explicitly linked to a stated goal, it becomes straightforward to evaluate any proposed addition: does this new task support an agreed objective? If not, it doesn't belong in the project without a formal change request that goes through proper review.
Without a template, the project manager has to argue against additions. With a template, anyone proposing an addition has to justify why it belongs — against an explicit map of what the project is for. Christiansen calls this "armed with facts instead of guesswork." It changes the entire dynamic of scope conversations.
Templates and Change Management
Another powerful benefit of a model-based template is what Christiansen calls traceability: the ability to understand the full consequences of a change before it's made.
He uses a vivid example: in a car design project, changing the position of a seat seems minor — until you realise it requires changing the door position, which cascades into changes to the exterior design, which affects structural elements. A seemingly small change turns into a major rework, discovered only after the fact.
When a project is mapped in a template with explicit dependencies between models, the project manager can see this cascade before committing to the change. Every change request can be evaluated not just on its own merits, but on its ripple effects through the entire project structure. This is what makes the template a decision-making tool, not just a planning document.
How model-based templates handle change
When a change request arrives, a well-structured project template lets the project manager immediately answer:
- Which tasks need to be updated as a result of this change?
- Which tasks become irrelevant and should be removed?
- Which new tasks must be added to implement the change correctly?
- Which stakeholders are affected and need to be informed?
- What is the realistic time and cost impact?
Without this structure, these questions are answered by guesswork. With it, they're answered by the model itself.
The Six Benefits of Project Management Templates
Project Templates in Proglar
Proglar's project model system is designed around exactly the principles Christiansen describes. Every project in Proglar is built from models and sub-models that can be saved as templates — reusable starting points for future projects of the same type.
When a project launches from a template, it inherits the full structure: all tasks and phases, skill requirements per task, time estimates from previous projects, dependency relationships between models, and links from tasks to project goals. The project manager adapts rather than creates — adjusting the template for the specific context rather than building from scratch.
As team members log time on each task, that data feeds back into the template's estimates — so the template gets more accurate with every project that uses it. Over time, your templates become a compounding asset: each project makes the next one faster, more predictable, and better estimated.
Templates also integrate directly with Proglar's skills matrix. Because each task in a template specifies required skills, the system can automatically suggest which team members are the best fit for each task when a new project is launched — cross-referencing task requirements against the current skills data.
Start building your first project template
Proglar's project model system makes it easy to build, save, and reuse templates across your team. Try it free for 30 days — no credit card required.
Frequently Asked Questions
What should a project management template include?
A good project management template should include all project phases, individual tasks broken into sub-models, dependencies between tasks, required skills per task, time estimates based on historical data, and links from each task to a specific project goal. It should also specify who is responsible for each phase and what the expected deliverables are.
How is a project template different from a project plan?
A project plan is specific to one project — it has real dates, assigned team members, and a defined scope. A project template is a reusable blueprint that captures the structure of a recurring project type, without specific dates or assignments. A new project plan is created by launching a template and adapting it to the specific context.
How often should project templates be updated?
Templates should be reviewed and updated after every project that uses them — not just before annual audits. Each project reveals whether estimates were accurate, whether tasks were missing, and whether dependencies were correctly mapped. Continuous improvement of templates is what makes them increasingly valuable over time.
Can project templates handle scope changes?
Yes — a model-based template with explicit dependency mapping is one of the most effective tools for managing scope changes. Because every task is linked to a goal and connected to other tasks through dependencies, the project manager can immediately see the full impact of any proposed change before agreeing to it.
What is the difference between a project template and a project model?
A project model is the structured representation of a specific project — capturing its components, their properties, actions, and dependencies. A project template is a saved, reusable version of a project model that can be launched for any new project of the same type. The template is the model made reusable.