In simple terms
A friendly intro before the formal notes — no formulas yet.
Upgrading the School Canteen
Introducing a new IT system is like renovating a school canteen to use a new payment system instead of cash. Careful planning is needed to avoid chaos and ensure everyone can still get their lunch.
Imagine your school canteen decides to stop accepting cash and wants everyone to pay using a new pre-paid card. Before they just throw out the cash registers, they need a plan. They have to choose the right card system, transfer everyone's lunch money balances to the new cards, teach students and staff how to use the new machines, and have a backup plan in case the card reader breaks. This whole process, from the initial idea to everyone happily using their new cards, is what planning and change management is all about for any new system.
- 1
First, the school analyses why the cash system is a problem (long queues, security risks) and researches different card systems to find one that is affordable and reliable.
- 2
Next, they select a vendor, customise the software to link with school records, and install the new card readers and top-up machines.
- 3
Then, they implement the system. They might run it alongside cash for a week (parallel running) and hold sessions to teach everyone how to add money and pay with their new card.
- 4
Finally, after the new system is fully operational, they gather feedback to see if the queues are shorter and fix any bugs, like a card not scanning properly.
Explore the concept
Use the live diagram and synced steps — play it or tap a step card to walk through.
Full topic notes
Formal explanation with the rigour you need for the exam.
1. Planning and Feasibility
Before any code is written or hardware is purchased, a thorough planning phase is essential. This begins with identifying a problem or opportunity and defining the scope of the proposed new system. A key part of this is the feasibility study, which assesses the project's potential for success. A common framework for this is TELOS.
The output of this phase is a detailed requirements specification and a project plan, often visualised using tools like a Gantt chart to map out tasks, timelines, and dependencies.
Technical Feasibility: Does the technology exist? Do we have the technical expertise to implement it?
Economic Feasibility: Is the project cost-effective? Will the benefits outweigh the costs (Cost-Benefit Analysis)?
Legal Feasibility: Does the proposed system comply with all relevant laws and regulations (e.g., GDPR, data protection acts)?
Operational Feasibility: Will the system be used? Does it fit with existing business practices? Can we manage the change?
Schedule Feasibility: Can the project be completed in an acceptable timeframe?
2. Change Management Strategies
Changeover, or 'go-live', is the moment of truth. It's the process of switching from the old system to the new one. The chosen method depends on the complexity of the system, the level of risk the organization can tolerate, and the available budget. There are four main strategies.
Direct Changeover: The old system is switched off and the new one is switched on. Pros: Fast, cheapest option. Cons: Extremely high risk; if the new system fails, there is no backup.
Parallel Running: Both old and new systems run simultaneously for a set period. Pros: Very low risk; the old system acts as a backup. Cons: Very expensive in terms of cost and staff effort (double data entry).
Phased Implementation: The new system is introduced in stages, one module or part at a time. Pros: Allows users to adapt gradually; failure is contained to one part. Cons: Can take a long time; may cause compatibility issues between new and old modules.
Pilot Running: The new system is fully deployed in a single, isolated part of the organization (e.g., one office or branch). Pros: Real-world testing in a controlled environment; failure has limited impact. Cons: The pilot site may not be representative of the whole organization.
3. Compatibility and Data Migration
A new system rarely exists in a vacuum. It often needs to interact with other existing systems, and crucial data from the old system must be transferred. This process is a major source of problems. Compatibility issues can arise from different hardware, software platforms, or data formats. Data migration involves extracting data from the source, transforming it into a compatible format, and loading it into the new system (ETL: Extract, Transform, Load). This must be carefully planned and tested to prevent data corruption or loss.
Incompatible File Formats: Data stored in a proprietary format in the legacy system may not be readable by the new system.
Data Structure Differences: Field names, data types (e.g., integer vs. string), and relationships between tables may differ.
Validation Rules: The new system may have stricter validation rules (e.g., requiring an 8-character password) that old data does not meet.
Incomplete or 'Dirty' Data: The old system might contain duplicate records, incomplete entries, or outdated information that needs to be 'cleansed' before migration.
4. The Human Factor: User Training and Support
A perfectly designed system can still fail if users don't know how, or don't want, to use it. User resistance is a significant challenge in change management. Therefore, comprehensive user training and ongoing support are not optional extras; they are fundamental to a project's success. Training should be tailored to different user groups and can be delivered in various ways, such as formal classes, one-to-one coaching, or online tutorials. Good user documentation is also vital for long-term support.
In Paper 1, questions on this topic are often scenario-based. Always refer directly to the details given in the stimulus material. When asked to 'evaluate' or 'justify' a choice (like a changeover method), you must provide both pros and cons in the context of the scenario. For example, don't just say 'Direct changeover is risky'; say 'Direct changeover is too risky for the airline's booking system because a failure could lead to millions in lost revenue and reputational damage.'
Worked examples
See the formulas applied — reveal one step at a time, like the exam.
A national bank with 500 branches is replacing its 20-year-old legacy mainframe system with a modern, networked banking platform. The new system handles all customer transactions. The bank cannot afford any downtime or data loss. Propose and justify the most suitable changeover method.
- 1
Method Choice: Pilot and/or Phased Implementation. [1 mark]
A hospital is migrating patient records from an old system to a new one. In the old system, patient date of birth is stored as a text string, e.g., "23rd March 1984". The new system requires it in a YYYY-MM-DD date format. Describe a problem that will occur and outline the steps to solve it.
- 1
Data Type Incompatibility: The string format "23rd March 1984" from the old system cannot be directly inserted into the new system's YYYY-MM-DD date field. This will cause an error during the data loading process, and the records will be rejected. [1 mark]
How it all connects
The big idea sits in the middle — tap a linked idea to explore the link.
Tap a linked idea to see how it connects back to the main topic — that connection is what examiners reward.
Glossary
Try to recall each definition before you reveal it.
Quick check
Answer in your head first — then tap to check. No pressure.
Revision flashcards
Flip the card. Test yourself before the exam.
Legacy System
An old method, technology, computer system, or application program that may or may not be supported/available for purchase anymore. It is still in use because it serves a critical function.
Key takeaways
Review these before you close the topic — retrieval beats re-reading.
- ✓
Technical Feasibility: Does the technology exist? Do we have the technical expertise to implement it?
- ✓
Economic Feasibility: Is the project cost-effective? Will the benefits outweigh the costs (Cost-Benefit Analysis)?
- ✓
Legal Feasibility: Does the proposed system comply with all relevant laws and regulations (e.g., GDPR, data protection acts)?
- ✓
Operational Feasibility: Will the system be used? Does it fit with existing business practices? Can we manage the change?
- ✓
Schedule Feasibility: Can the project be completed in an acceptable timeframe?
Practice — then mark it
The whole point: a real Cambridge question, marked mark-by-mark.
Test Your Knowledge
Test Your Knowledge
Extra simulations & links
PhET, GeoGebra and other curated tools — open in a new tab.
Frequently asked
Checkpoint
One marked question is worth ten re-reads — close the loop before you move on.
Reading it isn’t knowing it — prove it.
Before you move on: do Test Your Knowledge on paper, snap a photo, and get examiner-style feedback on exactly where you win and lose marks.