Step by step from A to Z

The whole project as a checklist, from the first idea to handover and operations. Check off what you have done.

Checklist

All the project steps in the order they come. Your browser remembers the items you check off, and each one links to the chapter with details.

0 of 39 done

The decision

Check whether off-the-shelf software already exists for your problem, and build custom only the part that sets you apart (chapter 2).
Set rules for applications your colleagues build with AI, and treat their prototypes as a brief, not as a production system (chapter 3).
Calculate the costs over 5 years in three envelopes: operations and support, maintenance, further development (chapter 4).
Ask for an estimate as a range, compare it with similar projects, and have the contingency approved separately (chapter 1).
Write a business case with three options, including the “do-nothing” option, and 3–5 metrics with a baseline value (chapter 5).
Agree on stop criteria in advance, and separate the person who runs the project from the person who assesses its status (chapter 5).

Development

Do the analysis with the vendor: user stories with acceptance criteria, non-functional requirements in numbers, and an out-of-scope list (chapter 14).
Try out a clickable prototype with the people who do the day-to-day work before programming starts (chapter 14).
Insist on a widely used technology with a known end-of-life date, a simple modular architecture, and security and accessibility according to standards (chapter 15).
Write your cooperation into the contract (roles, hours, response times), and have the vendor keep a record of what they are waiting for from you (chapter 16).
From day one, have access to the repository, the backlog, and the test environment (chapter 17).
Every two weeks, ask for a demo of running software in your test environment, and a monthly steering committee with numbers (chapter 17).
Handle every change in writing: a price estimate, a decision by someone with a mandate, and a change order, following the rule “something in, something out” (chapter 18).
Respond to a red signal within 2 weeks: stop expanding the scope, commission an independent audit, and decide whether to continue (chapter 19).

Acceptance and launch

Run user acceptance testing with key users on real scenarios and anonymized real data (chapter 20).
Have an independent penetration test and a performance test done, and the findings fixed before acceptance (chapter 20).
Do not accept the work without a handover package: code with build instructions, licenses, SBOM, documentation, and access in your name (chapter 20).
Do 2–3 trial data migrations with reconciled record counts, and test the rollback (chapter 20).
Make the go/no-go decision based on criteria set in advance, and launch gradually, starting with a pilot (chapter 20).
Train users shortly before launch, and arrange hypercare for the first 4–12 weeks (chapter 20).

Operations and further development

Agree on an SLA with three time limits for each priority, a definition of availability, penalties, and a monthly report (chapter 21).
Have RPO, RTO, and a restore-from-backup test at least once a year written into the contract (chapter 21).
Budget for operations and maintenance every year, and plan further development based on a 12–24 month roadmap (chapter 22).
Update in small steps, and keep track of the end-of-life dates of all components based on the SBOM (chapter 22).
Pay down technical debt continuously with dedicated capacity, and track how much comparable changes cost over time (chapter 23).
Once a year, have an independent party test the exit package: can the system be built, deployed, and changed from the materials handed over? (chapter 24)
Ask regularly about risks, ranges, and warnings, and make sure true information and bad news reach you (chapter 25).

Only this browser remembers what you tick (it is stored locally, like cookies). If you clear cookies and site data, use a private window, or switch devices, you start over.

May we use cookies?