Management proportionate to a team: the plan, the risk register and the decision log

A five-person team that borrows project management from a textbook borrows a scale it does not have. The defensible minimum is three artefacts: a plan for what will be delivered, a risk register whose every entry has an owner and a date, and a decision log for what was decided. This is the fourth of ten units, and it turns from the client and the participant to the team's own management of the work. The case for that minimum is weaker than practice suggests: its vocabulary comes from a standard built for large organisations (Project Management Institute, 2021), its evidence about optimism from megaprojects (Flyvbjerg et al., 2003), and the agile rejection of the classical apparatus mostly from practitioner reports rather than controlled comparison (Dingsoyr et al., 2012).

The plan: a standard written for a different scale

The PMBOK Guide presents twelve principles and eight performance domains, uncertainty among them, and instructs teams to tailor their approach and processes to the environment and the work at hand (Project Management Institute, 2021). Those counts are the 2021 seventh edition's; the eighth edition, in November 2025, reduces them to six principles and seven performance domains (Project Management Institute, 2025). Tailoring lets a student team use the standard without being governed by it. A written statement travels: what will be delivered, what is excluded, who accepts the result. The apparatus of baselining, cost forecasting and formal change control does not.

The evidence behind the case for formal planning comes from a scale no student team shares. Flyvbjerg, Bruzelius and Rothengatter (2003) examine several hundred projects in twenty nations and find a formula for approval. Promoters underestimate costs, overestimate revenues, undervalue environmental impacts and overvalue economic benefits. They misinform parliaments and the public to get a project built, so the pattern is not bad luck. The failure a plan must catch is optimism.

The risk register: a counter-practice, not a description of practice

Boehm (1991) set out the discipline the register implements. Risk assessment covers identification, analysis and prioritisation. Risk control covers planning, resolution and monitoring, and closes the loop with a prioritised list at each review. The aim is to remove risk items before they become threats or rework. A team member may leave is not an entry: it has no owner, no wording of the event, no mitigation and no date. The second developer starts a placement in January, so deployment moves to December or is documented for a replacement. That is an entry, because it ends in a decision somebody can act on. An access need is an entry of the same kind: a teammate who uses a screen reader is a constraint with an owner and a date.

Boehm describes what a register should be; the empirical literature describes something else. Kutsch and Hall (2005) studied how project managers responsible for risk in information technology projects actually behaved. Their typology names the conditions under which managers deny, avoid, ignore and delay risk, split between the environment and the decision maker. The register is a counter-practice rather than a description of professional behaviour.

The consequence was self-defeating: those managers rated their own risk management less effective and their projects worse. What the case does not show is that a register prevents this, since it describes behaviour no artefact blocks. It shows what the register has to overcome: the first entry is the one the team would rather not write down.

The decision log: a retrospective that ends in a decision

Kerth (2001) gives the review its method and its precondition. A retrospective is a facilitated review of how a project went, and it has to be safe. Kerth's task is defeating the fear of retribution that stops people speaking. Its lesson is blunt: a review that produces no decision is a meeting.

Scrum places the same idea inside a delivery cadence, making the retrospective a formal event and the definition of done the test an increment must pass (Schwaber and Sutherland, 2020). Andriyani, Hoda and Amor (2017) then test what a retrospective produces, in a case study of four agile teams using interviews of sixteen practitioners and observation of their meetings. They model three levels of reflection, from reporting and responding, through relating and reasoning, to reconstructing, and find that teams may not reach all three levels simply by holding the retrospective. The log is the corrective: an entry recording what was decided, on what information, and what was rejected can be tested where a discussion cannot.

What the agile literature rejects, and what its evidence can carry

Dingsoyr, Nerur, Balijepally and Moe (2012) analyse publications and citations in the ten years after the manifesto and delineate the conceptual structure of the field.

Most of these ideas have spawned a number of practices that are claimed to be efficacious, but empirical validation of such assertions is lacking.

That sentence comes from reviewers sympathetic to agile rather than from its critics. It is the second half of this unit's thesis: the lighter alternative to a plan is not better evidenced, and both are argued from experience.

Kalenda, Hyna and Rossi (2018) combine a focused literature review with action research in a large software company rolling agile out. They find culture, prior agile experience, management support and value unification the key success factors. Resistance to change and integration with non-agile processes are the critical challenges. Adzgauskaite, Tam and Martins (2025) model the facilitators of success in agile remote teams, from a survey of 198 information technology professionals. Job performance and team satisfaction are significant: conditions of the team, not artefacts it produces.

Group development: a model trusted more than it has been tested

Teams reach for a stage model to explain their own conflict. Tuckman (1965) reviewed fifty articles on group development and proposed four general stages, reporting a good fit with the observed evidence. Twelve years later, Tuckman and Jensen (1977) reviewed twenty-two further studies and found only one that tested it directly. Its observers had been given descriptions drawn from the model itself. They added adjourning as a fifth stage. Wheelan, Davidson and Tilin (2003) offer the strongest positive evidence, from the verbal behaviour of 180 members of 26 work groups and the perceptions of 639 people in 88 work groups. Groups meeting longer made fewer dependency and fight statements and more work statements. The account has support; its mechanism stays open.

Contested question: is this the minimum, or is the minimum smaller?

The first position holds that the three artefacts are the minimum, because they convert intention into something another person can act on. Boehm (1991) requires identification, prioritisation, ownership and closed-loop monitoring. The PMBOK Guide makes uncertainty a performance domain and expects tailoring (Project Management Institute, 2021). Kerth (2001) and Schwaber and Sutherland (2020) make the review a formal event rather than an optional conversation. On this view a team without a register spends its scarcest resource, its members' time, rediscovering decisions it has already made.

The second position holds that what makes a team succeed is the people and their conditions, and that the artefacts can become theatre. DeMarco and Lister (1987) argue from studies of software teams that the major problems of the work are sociological rather than technological. Kutsch and Hall (2005) find managers denying, avoiding and delaying risk rather than managing it through a register. Andriyani, Hoda and Amor (2017) find that holding a retrospective does not guarantee reflection. Kalenda, Hyna and Rossi (2018) find culture and management support decisive, not the scheme. On this view a register nobody reads costs time and buys the appearance of control.

What would settle it is a study that varies only the artefacts, holding team, task and deadline constant. It would score outcomes against criteria set in advance by an outsider. Nobody runs it. The evidence comes from megaprojects (Flyvbjerg et al., 2003), one large company (Kalenda et al., 2018), a survey of practitioners (Adzgauskaite et al., 2025) and single-company case studies (Kutsch and Hall, 2005; Andriyani et al., 2017). None of those isolates the artefacts. The claim the unit can defend is narrower than the practice implies. A plan, a register and a log are the minimum because they are cheap, they make decisions visible, and no study has shown a smaller set to do the same work.

Both sides are weak in the same way. The case for the three artefacts is an argument from their design, not from a trial (Boehm, 1991; Project Management Institute, 2021). The evidence against them comes from single-company studies, one survey and a megaproject literature (Kutsch and Hall, 2005; Kalenda et al., 2018; Flyvbjerg et al., 2003). While the dispute is open, size each artefact to the decision it must carry: one owner, one date, one wording of the event, and a log entry that ends in a decision. The strongest objection is that the minimum survives on the cost of its absence, not on a measured benefit, so a sceptical reader would keep the log and ask the other two to prove themselves.

Where the argument is heading

The direction of travel is away from the artefact and towards instruments that can be scored. Andriyani, Hoda and Amor (2017) propose a framework that embeds three levels of reflection in the steps of a standard retrospective, so the quality of a review can be judged. Dingsoyr and colleagues (2012) ask for theory-based research in place of advocacy. Kalenda, Hyna and Rossi (2018) conclude that scaling can be tailored while core values are kept. For a student team the reading is stable. Keep the three artefacts, and expect to be judged on whether a log changed a decision, not on whether the paperwork was complete.

The sources this unit rests on

• Project Management Institute (2025). A Guide to the Project Management Body of Knowledge (PMBOK Guide), eighth edition. Project Management Institute. https://www.pmi.org/standards/pmbok Sets out six principles and seven performance domains and instructs teams to tailor the approach to context. It supplies the vocabulary and permits resizing it. The counts are the eighth edition's, published in November 2025 and reduced from the seventh edition's twelve principles and eight domains, so an older citation of the twelve and the eight is dated rather than wrong.
• Boehm, B. W. (1991). Software risk management: principles and practices. IEEE Software, 8(1), 32-41. doi:10.1109/52.62930 Defines risk management as assessment and control covering identification, analysis, prioritisation, planning, resolution and monitoring. It is the origin of the owner, mitigation and date an entry must carry.
• Flyvbjerg, B., Bruzelius, N. and Rothengatter, W. (2003). Megaprojects and Risk: An Anatomy of Ambition. Cambridge University Press. doi:10.1017/CBO9781107050891 Examines several hundred projects in twenty nations and finds underestimated costs and overestimated revenues, produced by promoters who misinform to get approval. It shows that optimism drives overrun.
• Kutsch, E. and Hall, M. (2005). Intervening conditions on the management of project risk. International Journal of Project Management, 23(8), 591-599. doi:10.1016/j.ijproman.2005.06.009 Interviews information technology project managers and derives a typology of conditions under which they deny, avoid, ignore and delay risk. Practice departs from the register the textbook prescribes.
• Kerth, N. L. (2001). Project Retrospectives: A Handbook for Team Reviews. Dorset House. https://www.dorsethouse.com/books/pr.html Presents the retrospective as a facilitated review of a project's history, with safety from retribution as the condition for honesty. It is the ancestor of the decision log.
• Schwaber, K. and Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org/scrum-guide.html Defines Scrum's roles, events and artefacts, including the retrospective as a formal event and the definition of done as the test an increment must pass. It is the canonical statement of the cadence the review practice is set against.
• Andriyani, Y., Hoda, R. and Amor, R. (2017). Reflection in Agile Retrospectives. XP 2017, Lecture Notes in Business Information Processing 283, 3-19. doi:10.1007/978-3-319-57633-6_1 Case study of four agile teams, with interviews of sixteen practitioners and observation of meetings, identifying three levels of reflection. Teams may not reach all levels by holding a retrospective alone.
• Dingsoyr, T., Nerur, S., Balijepally, V. and Moe, N. B. (2012). A decade of agile methodologies. Journal of Systems and Software, 85(6), 1213-1221. doi:10.1016/j.jss.2012.02.033 Analyses publications and citations in the ten years after the agile manifesto and maps the conceptual structure of the field. It records that agile practices are claimed efficacious while empirical validation is lacking.
• Kalenda, M., Hyna, P. and Rossi, B. (2018). Scaling agile in large organisations: practices, challenges, and success factors. Journal of Software: Evolution and Process, 30(10), e1954. doi:10.1002/smr.1954 Combines a focused literature review with action research in one large software company. Culture, prior agile experience, management support and value unification were the key success factors, and scaling could be tailored while core values were kept.
• Adzgauskaite, M., Tam, C. and Martins, R. (2025). What helps Agile remote teams to be successful in developing software? Empirical evidence. Information and Software Technology, 177, 107593. doi:10.1016/j.infsof.2024.107593 Models the facilitators of agile project success from survey data from 198 information technology professionals. Job performance and team satisfaction were significant, locating success in team conditions rather than in artefacts.
• Tuckman, B. W. (1965). Developmental sequence in small groups. Psychological Bulletin, 63(6), 384-399. doi:10.1037/h0022100 Reviews fifty articles on stages of group development and proposes four general stages, reporting a good fit with the evidence. It is the origin of the stage model teams use to explain conflict.
• Tuckman, B. W. and Jensen, M. A. C. (1977). Stages of small-group development revisited. Group Organ. Stud., 2(4), 419-427. doi:10.1177/105960117700200404 Reviews twenty-two further studies, finds only one that tested the stage hypothesis directly with observers given descriptions from the model itself, and adds adjourning. It is the authors' own qualification of a model treated as settled.
• Wheelan, S. A., Davidson, B. and Tilin, F. (2003). Group development across time: reality or illusion? Small Group Research. doi:10.1177/1046496403251608 Examines the verbal behaviour of 180 members of 26 work groups and the perceptions of 639 people in 88 work groups. Longer-meeting groups made fewer dependency and fight statements and more work statements, supporting a developmental account.
• DeMarco, T. and Lister, T. (1987). Peopleware: Productive Projects and Teams. Dorset House. https://archive.org/details/peoplewareproduc0000dema Argues from studies of software teams that the major problems of the work are sociological rather than technological, with productivity clustering by workplace. It is the strongest counter-argument to a minimum built from artefacts.