Why Hybrid Projects Use Agile and Traditional Artefacts Together

A project manager joining a hybrid programme for the first time usually notices the same thing within a fortnight. There is a product backlog that gets reordered every two weeks. There is a risk register that gets a formal review once a month. There is a milestone plan going to the steering group, and there is a wall of cards the delivery team actually works from. Sooner or later the question forms, and it is normally asked quietly: which of these is the real one?

It is a fair question, and the answer disappoints anyone hoping for a rule. Both are real. On a genuine hybrid project a backlog and a risk register are not competing versions of the same thing, and neither is a leftover from an approach the organisation has not finished abandoning. They exist together because they answer different questions, for different people, on different timescales. Understanding that distinction is what separates a project manager who tailors deliberately from one who inherits a pile of documents and maintains all of them out of caution.

Artefacts answer questions, not approaches

The most useful shift is to stop treating artefacts as evidence of a methodology and start treating them as answers to questions somebody genuinely has.

A product backlog answers a delivery question: given what we now know, what should this team work on next, and in what order? It is ordered rather than fixed, and it is expected to change as understanding improves. A risk register answers a different question entirely: what could stop this project achieving what it was funded to achieve, who is accountable for doing something about it, and has anything changed since we last looked? The delivery team does not ask that every fortnight. Sponsors, assurance functions, suppliers and sometimes regulators ask it, at a rhythm governance sets.

Once the questions are separated, the coexistence stops looking odd. This is consistent with Section 4.2.3 of The Standard for Project Management, which describes hybrid approaches as combining predictive and adaptive elements where different parts of the work benefit from being run differently. If different parts of the work are genuinely being run differently, it follows that the information those parts produce will look different too. A hybrid project that produced only adaptive artefacts would not be hybrid. It would be an adaptive project with a governance gap.

Two rhythms of commitment in one project

The deeper reason both artefact families survive is that a hybrid project usually carries two kinds of commitment, and they move at different speeds.

Some commitments are internal and revisable. What the team builds this iteration, how a feature is shaped, which defect is worth fixing now: these can be reconsidered every couple of weeks without anyone outside the team needing to be consulted. Adaptive artefacts are built for exactly this. They are designed to be reordered.

Other commitments are external and expensive to move. A regulatory reporting deadline, a contracted supplier milestone, a funding release tied to a board cycle, a data centre exit date, a cutover weekend that requires the operations team to stand down normal service. None of these becomes flexible because the software is being built iteratively. They are the same kind of commitment they have always been, and the artefacts that traditionally manage them, the milestone plan, the risk register, the dependency schedule, the change record, remain the right instruments for the job.

This is worth stating plainly, because a good deal of hybrid commentary implies that predictive artefacts are tolerated concessions to a slow organisation. That is rarely accurate. A project manager who can hold a fixed regulatory date and an evolving backlog in the same head, without pretending either is negotiable when it is not, is doing something more difficult than either approach demands on its own.

The gap between the two artefact sets

Experienced project managers do not normally struggle with having two sets of artefacts. They struggle with the seam between them.

Consider a mid-sized financial services firm replacing its client reporting platform. The delivery team works in two-week iterations from an ordered backlog. The programme maintains a milestone plan, a risk register and a monthly steering pack, largely because a regulatory reporting date sits at the end and the firm's assurance function requires visible control. Both artefact sets are maintained properly. Neither is theatre.

Two months in, the steering pack shows the data migration milestone as at risk, while the team's board shows every migration item complete. The project manager's first instinct is that someone has reported badly. Nobody has. The team finished building the migration tooling, which is what the backlog described. The milestone, however, also required a data-quality sign-off from the operations team, and that sign-off had never appeared on the backlog, because operations were not represented in backlog refinement. It had never appeared as a risk either, because it was not uncertain. It was simply nobody's item.

That is the characteristic hybrid failure. The two artefact sets did not contradict each other; they described adjacent territory and left a strip of ground uncovered between them. Reconciling the numbers would not have found it. Only asking what each artefact covers, and where its edge falls, would have.

Deciding which artefacts earn their place

The practical work, then, is boundary work rather than tool selection. Four questions do most of it.

Start with who asks the question, and how often. If nobody has asked for the output in three months, the artefact is being maintained out of habit. If two different audiences ask on different cycles, two artefacts may be legitimate.

Then establish what decision the answer feeds. An artefact that informs no decision is a document. An artefact that feeds a funding release, a prioritisation call or an escalation is a management instrument.

Next, find where the fact already lives and which copy is the source. When the same commitment appears in the backlog and the milestone plan, resolve which one is authoritative and have the other reference it. Two independently maintained copies of one date will diverge, and they will diverge quietly.

Last, and most often skipped, ask what falls between them. Walk the boundary deliberately: sign-offs, external dependencies, operational readiness, contractual obligations and anything owned by a group not present at either forum.

For a PMP candidate, the useful distinction is that a scenario naming a backlog and a risk register in the same sentence is not a trick and is not describing a project in disarray. It is describing a tailored environment, and the question is normally about what the project manager should understand before acting. Common preparation advice sometimes leaves candidates with the impression that mixed artefacts signal something has gone wrong. Read for the question being asked instead of the artefact being named. Boundary judgement of that kind is what the PMP® Exam Preparation course works through across the wider syllabus, in the same instructor-led format.

On a live project the payoff is quieter but larger. A project manager who can explain, in one sentence per artefact, why it exists and who reads it, can retire the ones that do not earn their place without anyone feeling their oversight has been removed. That conversation is much easier to have when the reasoning is about purpose rather than about which approach the organisation believes in.

Andre Malowney

Interested in going further?

Deciding which artefacts a hybrid project genuinely needs, and spotting the work that falls between them, is judgement that develops faster with structured practice and worked situations than with reading alone.

For the underlying treatment of predictive, adaptive and hybrid development approaches, the PMBOK® Guide Eighth Edition is the source guide behind this article.

Ad · Amazon affiliate link.

References

A059: Hybrid Project Management Explained for Traditional Project Managers
A157: Do Agile and Hybrid Projects Still Use Risk Registers?
A056: Predictive vs Agile vs Hybrid Project Management: How to Choose
A057: How to Recognise Predictive, Agile and Hybrid PMP Scenarios
A191: Product Backlog vs Sprint Backlog

PMP and PMBOK are registered marks of the Project Management Institute, Inc.