Management: Portfolio, programme and project¶
Project management¶
Rules found in this domain: P67, P65, P75, P20, Master.
Illustrative, not evidence.
Scenario. A company moves its office to a new building. The project plan lists tasks and their dependencies. Network installation is on the longest chain. Furniture delivery has slack. Before the project starts, the team writes down the evidence that would stop the move, such as a failed fire inspection, and the gate dates. A steering board, not the sponsor, decides at each gate. Staff move floor by floor, and each floor is checked before the next one moves. The weekly status report lists only items outside tolerance. The plan is lighter than the one the company used for its data-centre move, where a failure would have cost far more.
- P67: The plan marks the critical path. Network installation is critical, so it is protected first. Furniture has slack and can move.
- P65: The move is done floor by floor. Each step is checked before the next, and the steering board decides at each gate whether to continue.
- P75: The weekly status shows only items outside tolerance, so every item in it calls for action.
- P20: Before the project starts, the team writes the evidence and the gate dates at which it stops. The gate decision is made by someone other than the sponsor.
- Master: The office move gets a lighter plan than the data-centre move, which had a higher consequence of failure. The method is adapted to the size, risk and context of the work (tailoring).
Portfolio management¶
Rules found in this domain: P20, P22.
Illustrative, not evidence.
Scenario. A company holds twelve proposed projects and funds five. Before funding, the board imagines that the portfolio has failed and lists why. It finds that two of the five need the same data team in the same quarter, and moves one of them. Every funded project has written stop criteria. A review board that did not start the projects checks them at each gate.
- P20: Each project has written stop criteria and gate dates. The review board decides to continue or stop, not the sponsor.
- P22: Before funding, the board assumes the portfolio has failed and lists the reasons. It also lists how parallel projects can interfere, here two projects that need the same team in the same quarter.
Forecasting of large projects¶
Rules found in this domain: P12.
Illustrative, not evidence.
Scenario. A city plans a large transit line. The planners compare the cost estimate with the outcomes of similar past projects, not only with their own plan. The past projects overran their budgets on average, so the planners raise the estimate and the contingency before the business case is approved.
- P12: The business case is checked against a reference class of similar past projects. Those projects overran on average, so the own estimate is raised instead of trusted.
Agile and Scrum¶
Rules found in this domain: P66, P81, P23, P28.
Illustrative, not evidence.
Scenario. A product team runs two-week sprints. New requests wait for the next sprint, and only the Product Owner may cancel a sprint. The team keeps one ranked backlog and removes items nobody needs. A retrospective ends every sprint, and its actions are tracked until they are done. Each month the team reviews its overtime and technical debt.
- P66: While the team works on the sprint goal, it is protected from unplanned changes. Only the Product Owner may cancel the sprint.
- P81: A retrospective runs at the end of every sprint. Its actions are tracked until they are completed.
- P23: There is one team backlog with one ranked list, not three parallel priority lists. Work that is not needed stops.
- P28: The team reviews overtime and technical debt each month. Slow build-up is limited before it hurts.
Software delivery management¶
Rules found in this domain: P65.
Illustrative, not evidence.
Scenario. A delivery team ships changes in small batches several times a week. Each batch is checked before the next one goes out.
- P65: The team delivers in small steps and checks each result before the next. A small step is easy to check and to undo.
Software project staffing¶
Rules found in this domain: P53.
Illustrative, not evidence.
Scenario. A software project is three weeks behind. A manager is asked to add six engineers. She first cuts scope, and she records the expected training and coordination cost before anyone joins. She adds two engineers, only to a reporting module that can be split off from the rest of the work.
- P53: The work is late and needs coordination. The manager does not expect added people to recover the schedule soon. She cuts scope first, records the cost of adding people, and adds them only where the work can be split.