Lessons · Project management · change control, in steps
Change control: the change is welcome, the surprise is not
A change to a baseline is written down, its impact on scope, time, cost and risk is assessed, the right person approves or rejects it, and only then are the baselines and the work updated.
Hone is a place to practise a career, one idea a day. This is one of its lessons, written out in full and free to read without an account.
What it is for
A developer adds a feature a user asked for in the corridor. It takes three days, it is not tested, and it moves a date nobody re-planned. The feature may be a good idea; the way it arrived is what cost the three days twice.
How to think about it
Every change follows the same six steps, however small. Log it. Assess the impact on all four dimensions before anyone says yes. Take it to whoever owns the baseline. Update the baseline. Tell everyone. Then do the work.
Worked example
1. Log: CR-014, add an export-to-spreadsheet button, raised by the finance leadWritten, numbered, dated. Nothing happens to an unwritten change.
2. Assess: 3 days of development, $1,800, pushes the test start by 3 days, low riskScope, time, cost, risk. All four, before any decision.
3. Decide: the change control board approves, on the condition that the date movesThe person who owns the baseline decides, with the impact in front of them.
4. Update: the schedule baseline moves 3 days, the cost baseline rises $1,800The yardstick changes, so the next measurement is against the truth.
5. Communicate: team, sponsor and finance lead told the same dayEveryone measures against the same new baseline.
6. Do the workLast, not first.
Your turn
Write the step that must come before the decision.
Assess the on scope, time, cost and risk.
Solve one, graded on the server
The trap
Assessing after approving. Once a sponsor has said yes, the impact assessment becomes an argument about a promise. The order is the whole protection.