You are back from a year in industry with a laptop full of code you cannot fully explain to a marker, an NDA you are not sure how much of it covers, and a final-year project deadline that assumes you are starting from a blank page. If your computer science programme offers a practice-based route, your placement work does not have to be set aside — it can become the dissertation itself, written up properly rather than described in three vague paragraphs of your CV.
What is the practice report route, and is it available on your course?
Not every UK computer science programme offers this option, and where it exists it is usually a named alternative track (sometimes called a practice-based project, industrial project report, or placement dissertation) that your department has to formally approve — check your handbook or ask your placement/personal tutor before assuming it applies to you. Where it is available, the core idea is the same: instead of designing and building a new system from scratch as your final-year project, you write a structured, critical account of a substantial piece of work you did during your placement, evaluated and reflected on to the same academic standard as a standard dissertation. This is one of several distinct dissertation shapes UK programmes accept — see undergraduate dissertation structure by subject for how practice-based projects compare with the empirical, literature-based and design-and-build shapes other students use.
The trade a practice report makes is worth being honest with yourself about before you commit to it: you gain a real, already-built technical achievement and a year of genuine professional context to write about, but you lose the freedom to choose your own topic, timeline and technology stack. If your placement project was genuinely thin — small, poorly scoped, or something you had very little real involvement in — a from-scratch final-year project may actually be the stronger route, even with the extra work of starting from nothing.
How is this different from the standard build-and-evaluate dissertation?
A standard CS dissertation (see how to structure a computer science dissertation for the full model) is a project you design, scope and evaluate yourself from the start. A practice report inherits a project scope you did not fully control — your employer set the requirements, the timeline, and often the technology choices — so the academic work is different: less about defending your own design decisions from a blank slate, more about critically analysing decisions that were partly made for you, and demonstrating the professional and technical learning that came out of working within real organisational constraints.
What structure does a practice report typically take?
- Placement and project context: the organisation (anonymised or named per your NDA and your department’s confidentiality guidance), your role, and the business problem the work addressed.
- Technical background: the same job as a standard dissertation’s literature review — the technologies, methods or prior approaches relevant to what you built, critically discussed rather than just listed.
- The work itself: what you specifically built, contributed to, or led — scoped honestly to your own contribution if it was a team project, not the whole team’s output presented as yours.
- Critical evaluation: the same rigour a standard dissertation’s evaluation chapter needs — what worked, what did not, measured against criteria, not just “the client was happy.”
- Professional reflection: what the placement taught you about working as a developer/engineer in a real organisation — software engineering practice, team processes, technical skills gaps you closed — usually structured against a named reflective model (Gibbs’ reflective cycle is common) rather than written as a diary.
- Conclusion: what you would do differently, and how the experience shapes your next technical or career step.
Word allocation across these sections looks different from a standard dissertation too — expect the technical background and critical evaluation sections to carry proportionally less weight than in a from-scratch project, and the professional reflection section to carry genuinely more, since demonstrating structured, honest self-assessment is a core assessed skill in this route, not a soft add-on at the end.
How do you handle confidentiality and your employer’s IP?
This is the single biggest practical difference from a standard dissertation, and it needs sorting before you start writing, not after. Three things to check with both your employer and your department: whether you can name the organisation at all, or must anonymise it; whether specific code, architecture diagrams or business data can appear in the dissertation body versus needing to be described rather than shown; and whether your university requires an employer sign-off or confidentiality agreement covering the submitted document. Most UK CS placement schemes have a standard process for this — ask your placement office early, since getting employer sign-off can take longer than students expect, especially over summer when the relevant manager may be on leave.
A practical workaround many students use when code cannot be shown directly: describe algorithms and architecture in generic, abstracted terms (“a caching layer using a least-recently-used eviction policy” rather than the literal production code), and use anonymised or synthetic data in any worked examples or screenshots. This satisfies most confidentiality agreements while still letting you demonstrate genuine technical understanding — check the specific wording of your NDA, since some are stricter than others about even abstracted descriptions.
How do you demonstrate technical depth when the scope was not yours to set?
Markers assessing a practice report specifically look for evidence that you understood and could critically engage with the technical decisions, even ones made before you joined or above your pay grade — not just that you implemented a ticket. A strong practice report explicitly separates what you decided from what you inherited, and critically evaluates both: “the team had already chosen X framework before I joined; here is what that choice cost us and what I would have suggested differently, with reasons.” This kind of explicit, honest boundary-drawing between your own contribution and the wider project is exactly the depth a from-scratch dissertation gets from designing everything yourself, and a practice report has to build it deliberately rather than getting it for free.
How does professional skills mapping fit in?
Some UK computer science placement and practice-report assessments ask you to map your technical and professional development against a named skills framework — SFIA (the Skills Framework for the Information Age) is a widely used option in UK IT and computing, giving named, levelled skills (such as programming/software development, functional testing, or stakeholder relationship management) you can honestly self-assess against rather than writing vague claims like “I improved a lot.” Check whether your own department specifies SFIA or an alternative framework, and use its actual named categories rather than inventing your own.
How is this different from a business placement dissertation?
This route shares its origin (a placement year) with writing your dissertation on your placement company, but the academic content is genuinely different. That business-placement route is framed around access, ethics and researching a company as a case study using business/management methods; a CS practice report is framed around a technical deliverable and professional/technical reflection, closer to a portfolio-with-critical-analysis than a piece of independent research into an organisation. If your placement was primarily technical (you built or maintained software) rather than research-style, the CS practice report route is almost always the better fit.
What mistakes do CS practice reports most often make?
Three recur. First, writing the technical section as a changelog (“added feature X, fixed bug Y”) rather than a critically evaluated account of decisions and trade-offs — a marker wants to see judgement, not a commit log in prose. Second, writing the reflection section generically, in a way that could describe almost any placement at almost any company, rather than tied to specific, named incidents from your own year. Third, claiming credit for a whole team’s output without clearly scoping what was genuinely your own contribution — markers who suspect this will probe hard at the viva, and an honest, precisely scoped account of a smaller genuine contribution marks better than an inflated claim over a larger one.
How do you choose which piece of placement work to write about?
If your year covered several projects, pick the one where you can say the most, honestly, about your own decisions — not necessarily the most technically impressive-sounding one on paper. A smaller feature you owned end to end, with real design trade-offs you can defend, usually makes a stronger practice report than a headline project where you were one of twelve contributors and can only speak confidently to a narrow slice of it. If two candidates seem evenly matched, favour the one with fewer confidentiality complications, since a report you can write about openly is easier to make detailed and convincing than one constantly working around what cannot be shown.
How does Tesify help you write this up?
Turning a year of placement notes, standup summaries and half-remembered technical decisions into a structured, critically reflective document is genuinely hard to start — most of the material exists in your head and old Slack messages, not in a form a marker can read. Tesify can help you turn placement notes and a rough account of what you built into a structured practice report, matched to the six-section shape above, without inventing technical detail or results you did not actually produce — every claim stays traceable to what you tell it happened.
Frequently asked questions
Does every UK computer science degree offer the practice report route?
No — it depends on your specific programme and whether it includes a formally assessed placement/sandwich year with this option built in. Check your department’s final-year project handbook or ask your placement tutor directly; do not assume it applies without confirming.
Can I use this route if my placement work was mostly maintenance, not a new build?
Yes — maintenance, bug-fixing at scale, or improving an existing system can make a strong practice report if you can demonstrate genuine technical engagement and critical reflection, not just that you closed tickets. The depth of your analysis matters more than whether the work was greenfield.
What if my employer will not let me discuss the project at all?
Talk to your placement office as early as possible — most departments have handled this before and can help negotiate what level of anonymisation or abstraction satisfies both your employer and your assessment requirements. In the rare case nothing can be shared, ask about switching to a standard dissertation track instead.
Is a practice report marked to the same standard as a standard dissertation?
Yes — the word count, rigour and critical-analysis expectations are typically equivalent, even though the content and structure differ. It is not a shortcut or an easier option; it is a different, equally demanding route.
Can I combine placement work with some additional independent research?
Some departments allow a hybrid, where the placement forms the empirical basis and you add an independent extension or deeper technical investigation beyond what the employer required. Check whether your programme supports this before assuming it is available.
How do I reference internal company documents I cannot make public?
Describe and cite them as confidential internal sources within the text (e.g., “internal architecture documentation, [Company], 2026, not publicly available”) rather than including them as appendices, and confirm your department’s exact convention for this, since it varies by institution.
Do I need my employer’s permission before I start writing, or only before I submit?
Start the conversation as early as possible, ideally before you begin drafting — discovering late that a section you have already written cannot be included wastes real time, and most employers are far easier to negotiate with early than against a submission deadline.
What if I did two different placements at two different companies?
Most practice reports focus on one substantial piece of work rather than trying to cover both placements shallowly; check whether your department allows a comparative report across two placements as an alternative, but treat this as the exception rather than the default structure.