Welcome to On a Back of an Envelope – an alternative view on Project Management. Here you will find a mix of humour, commentary and project management information that will both inform and entertain.
The Highlight Report is our section of commentaries on current project management practice and projects in the news.
Hall of Fame is where we honour individuals both real and fictional who have added to our understanding of Project Management or have offered an insight into the way the project world works.
Humour contains the lighter side of project management.
OBOE – On a Back Of an Envelope our glossary of project management terms.
If you would like to get in touch with us please use the Contact Us form here.
How Agile teams use short, focused investigations to reduce uncertainty and improve delivery confidence.
In Agile project management, a ‘spike’ is a short, time-boxed piece of work designed to investigate, research, or test something that’s not yet well understood. It’s a learning activity — not about delivering product features, but about gaining clarity and removing unknowns that could derail later development.
What Is a Spike?
A spike is essentially a mini-experiment that helps a team understand a problem area, validate an assumption, or evaluate potential solutions. The outcome is knowledge: a decision, a recommendation, or data that allows the team to proceed confidently.
Why Spikes matter
Projects often encounter uncertainty — around technology, integration, or business logic. Instead of guessing or delaying decisions, Agile teams use spikes to learn just enough to make informed choices. This prevents wasted effort and aligns teams on a shared understanding of the problem.
Common reasons to run a spike include:
Evaluating a new technology or library.
Exploring how to integrate with an unfamiliar system.
Testing performance or scalability options.
Clarifying ambiguous requirements or workflows.
How to Plan and Run a Spike
Spikes are deliberately lightweight but structured. They should have a clear goal, a fixed duration (typically one or two sprints), and a defined deliverable such as a short report, demo, or technical decision.
A simple planning checklist
Define the question — What uncertainty are you trying to resolve?
Limit the scope — Only explore what’s necessary to answer that question.
Time-box the effort — Prevent open-ended research.
Document findings — Summarise outcomes for the wider team.
When to Use a Spike
Spikes are most valuable when uncertainty blocks progress or threatens sprint predictability. They are also used at the start of new initiatives or when facing complex integrations. In hybrid or traditional environments, spikes serve the same role as feasibility studies — but faster, cheaper, and more focused.
Spike vs Proof of Concept
Spikes and Proofs of Concept both explore uncertainty but differ in scope and intent. A spike is usually smaller, time-boxed, and team-driven — its goal is understanding. A PoC, on the other hand, is a more formal validation effort, often involving stakeholders or sponsors, proving that a concept or technology can work. Many successful PoCs begin as spikes that uncover the key unknowns.
When a Spike becomes a PoC
Sometimes, what starts as a spike evolves into a full Proof of Concept when early findings reveal potential but need wider validation. Teams should formalise this transition by defining success criteria, documenting lessons learned, and ensuring sponsor alignment before scaling.
Summary
Spiking is a disciplined way to manage uncertainty. By running short, focused investigations, teams replace assumptions with evidence and make better decisions. It’s one of the quiet strengths of Agile project management — fast learning that keeps projects on course.
How evidence-driven experimentation improves outcomes and reduces delivery risk.
Modern project management increasingly borrows from the scientific method. Instead of assuming what will work, teams run structured experiments to test hypotheses and learn from measurable outcomes. This approach — known as experimentation — underpins Agile, Lean, and DevOps practices, encouraging teams to make evidence-based decisions.
What are experiments in project delivery?
An experiment in project delivery is a deliberate test of a hypothesis related to process, design, or technology. Each experiment seeks to answer a specific question: ‘If we try X, will it improve Y?’ Results are used to confirm, reject, or refine assumptions.
Why experimentation matters
Projects often face high uncertainty and fast-changing conditions. Experimentation provides a safe, structured way to explore alternatives without committing full resources. It reduces risk through learning and encourages innovation through evidence.
Key benefits include:
Faster learning and adaptation.
Measurable decision-making.
Encouragement of creativity and curiosity.
Reduced risk of large-scale failure.
Safe-to-Fail Testing
The concept of ‘safe-to-fail’ means designing experiments small enough that failure is acceptable and low-cost. Teams can run several in parallel, discarding unproductive approaches quickly while scaling those that succeed.
Designing a good experiment
Good experiments are small, measurable, and safe to fail. They start with a clear hypothesis (‘We believe that doing X will cause Y’), followed by controlled testing and observation. The goal isn’t to be right — it’s to learn quickly and cheaply.
Experiments differ from spikes and PoCs in purpose and formality. Spikes explore technical or requirement uncertainty. PoCs validate feasibility. Experiments, meanwhile, test cause-and-effect relationships to improve delivery practices or outcomes. They are about discovery through data.
Summary
Experiments in project delivery encourage a learning culture where decisions are informed by evidence, not assumption. By testing ideas safely and iteratively, teams build resilience, adaptability, and confidence in their outcomes.
How early validation reduces technical risk and builds stakeholder confidence.
A Proof of Concept (PoC) is a powerful mechanism to test feasibility before committing to full-scale development. It transforms uncertainty into actionable insight by answering one fundamental question: Can this be done? A well-defined PoC provides technical validation, reduces risk, and builds sponsor confidence — serving as a bridge between theory and implementation.
What Is a Proof of Concept?
A Proof of Concept is a small, controlled experiment designed to confirm whether a concept, technology, or approach will work in practice. It doesn’t aim to deliver a finished product but rather to demonstrate feasibility. Unlike prototypes or MVPs, PoCs focus on proving that something can be built — not how it looks or how users interact with it.
Why PoCs Matter
Projects fail most often not because of poor execution, but because of flawed assumptions. A PoC challenges these assumptions early by creating evidence instead of opinions. The benefits include:
• Risk reduction through early technical validation.
• Greater stakeholder confidence and support.
• Clearer decision-making data for go/no-go gates.
• Reduced rework and faster downstream delivery.
PoC vs Prototype vs MVP
While closely related, these artefacts serve distinct purposes. A PoC proves that something can work. A prototype demonstrates how it might work. An MVP delivers a minimal working product to test market or user reactions.
Proof of Concept – Tests feasibility (‘Can it be done?’)
Prototype – Tests form and function (‘What will it look and feel like?’)
MVP – Tests user and market response (‘Will people use or pay for it?’)
Types of PoCs
PoCs can take several forms depending on the problem domain:
Technical PoC – Tests integration, algorithms, or system performance.
Process PoC – Validates operational feasibility or workflow design.
Business PoC – Tests commercial potential, regulatory fit, or demand.
Planning a PoC
A successful PoC is sharply focused and time-boxed. Define one hypothesis to prove or disprove, decide how success will be measured, and use the simplest tools possible to generate credible data. Document assumptions, results, and next steps.
The Spiral Model and experiments
In the Spiral Model, each iteration includes risk analysis, prototyping, and validation. PoCs play a vital role in the ‘risk resolution’ phase — acting as controlled experiments that validate key uncertainties before major commitments are made.
Summary
A Proof of Concept is where ideas meet evidence. It’s an essential project management tool for de-risking innovation and ensuring that investment decisions rest on facts, not assumptions.
Scale model of Sir Christopher Wren’s design for St Paul’s Cathedral, built in the 1670s to visualise form and proportion before construction.
How early models help teams test ideas, reduce risk, and accelerate delivery.
In modern project management, prototyping is no longer a niche engineering activity — it’s a practical discipline used to reduce uncertainty, clarify requirements, and speed up delivery. Whether you’re developing a new app, service, or process, building something tangible early on helps bridge the gap between concept and execution. A prototype provides stakeholders with something to see, touch, and critique, transforming abstract requirements into actionable feedback.
What Is Prototyping in Project Management?
A prototype is an early, simplified version of a product or system that demonstrates key features or functions. In project management, prototypes serve as communication tools between teams and stakeholders. They can validate assumptions, expose design flaws, and encourage collaboration long before full-scale production begins. Prototyping supports iterative development by allowing feedback loops within each project phase. It’s widely used in software development, manufacturing, engineering, and service design. Depending on the project’s scope and complexity, prototypes can be physical (models or mock-ups) or digital (simulations or wireframes).
Why Prototyping Matters
Projects often fail because of unclear requirements, communication gaps, or late discovery of technical problems. Prototyping mitigates these risks by moving from theory to practice early. It encourages experimentation, supports design thinking, and makes invisible issues visible before they become expensive mistakes. A prototype helps teams answer key questions: Does the concept solve the user’s problem? Can the system be built with available technology? Are we aligned with stakeholder expectations? By testing, refining, and retesting ideas, teams can reach confidence faster and more efficiently.
Skunk Works
SOURCE: Lockheed Martin – Skunk Works Logo
The term ‘Skunk Works’ originated at Lockheed Martin during World War II, describing small, semi-autonomous teams tasked with developing advanced prototypes under extreme time pressure. The concept has since become shorthand for focused innovation: minimal bureaucracy, empowered teams, rapid iteration, and secrecy. Many modern innovation labs and Agile ‘tiger teams’ borrow from this approach — combining freedom with accountability to produce breakthrough results.
Choosing the Right Prototyping Approach
Selecting a prototyping model depends on what the team needs to learn or prove. If requirements are ambiguous, a throwaway prototype is best for discovery. When uncertainty lies in technology or performance, functional prototyping offers insight. Evolutionary and incremental models suit longer-term development or when a prototype will become the final product.
Types of Prototyping Models
Different types of prototyping serve different purposes. Choosing the right approach depends on the level of requirement clarity, the project’s complexity, and how much of the prototype will be reused in the final product.
Throwaway (Rapid) Prototyping
Used when requirements are unclear or evolving. The goal is to create a quick, low-cost model to explore ideas, test user reactions, and clarify needs — then discard it. This approach is common in UX design and early software concept validation. The focus is on learning, not building a production-ready artefact.
Evolutionary Prototyping
Here, the prototype evolves into the final product. Instead of discarding early versions, teams refine and expand them iteratively. This is often used in Agile environments or innovation projects where learning continues throughout the lifecycle. Each iteration builds functionality, guided by continuous stakeholder feedback.
Incremental Prototyping
In large or complex systems, it’s impractical to build everything at once. Incremental prototyping divides the system into modules that are developed, tested, and integrated progressively. It enables parallel workstreams and early demonstration of partial capabilities, reducing integration risk later.
Functional Prototyping
Functional prototypes are built to test performance, durability, or feasibility — often in engineering or hardware projects. Unlike visual mock-ups, they demonstrate real-world behaviour. They are essential when technical validation is the primary goal.
Scale or Physical Modelling
Used when the physical form, layout, or aesthetic impression of a design must be assessed before full production. Common in architecture and industrial design, scale models help stakeholders visualise spatial relationships and design intent. Christopher Wren’s wooden model of St Paul’s Cathedral remains an early and famous example of architectural prototyping.
The Spiral Model Connection
The Spiral Model formalises this iterative, risk-based approach by combining elements of prototyping with structured risk management. Each spiral cycle involves planning, prototyping, evaluation, and refinement. It’s particularly useful for large, complex, or high-risk projects where learning must be continuous and risk reduction is central. In modern practice, prototypes within the Spiral Model often take the form of experiments — structured tests designed to validate assumptions or reduce key uncertainties. Each cycle converts risks into evidence, ensuring progress is grounded in real learning rather than theory.
Proof of Concept (PoC) vs Prototype vs MVP
While related, these terms have distinct meanings. A proof of concept validates technical feasibility — can it be done? A prototype explores form, usability, or interaction — what will it look or feel like? An MVP (Minimum Viable Product) delivers a working version with just enough functionality to collect user feedback and test market response. Together, they form a continuum from idea to product.
Summary
Prototyping has evolved from a specialist engineering technique into a core project management practice. It provides a structured yet flexible way to test assumptions, engage stakeholders, and drive better design outcomes. Whether you’re creating software, hardware, or services, a good prototype helps bridge imagination and implementation — and brings clarity where uncertainty once ruled.
Project management succeeds not just through plans and processes, but through the practical tools and techniques that help teams make better decisions. This section explores proven methods used to test ideas, reduce risk, and improve delivery — from early-stage validation tools like prototyping and proofs of concept, to structured techniques such as the Spiral Model and Minimum Viable Product (MVP). Each article provides context, practical guidance, and examples of when and how to apply these approaches. Whether you’re managing a digital transformation, engineering project or service design initiative, you’ll find clear, applied explanations to support real-world projects.
