Personal Blogs

One of the most useful features of Microsoft Word is its flexible style system. Using Word, your words can be written any number of fonts and font sizes. If you decided you need to change the style or size of what you have written, you have a choice: you can either change the words themselves (by selecting them and picking another font or font size), or you can change the font of the style that is used with your all your words. Knowing about Word styles can help you to work more efficiently.

When you begin writing a document, you typically write words with the ‘Normal’ style. Word also provides a set of heading styles. These heading styles are linked to a number of other bits of Word functionality. Most notably:

• The Word document navigation view, and
• The Word table of contents creation tool.

Whenever you create a heading for a section, apply a Word heading to that session. If you then open up the document navigation view (which you can find in the view menu), you will see a clickable summary of your document.

When you have edited your document, and you need a table of contents, click on the references menu, and then on the table of contents button. This button will give you a couple of options to choose from. This references menu hints at some of the more advanced features in Word, including the ability to provide cross references between sections (which avoids you from having continually figure out what the correct page number should be if you add or remove a bit of text), and a way to define entries for an index.

Further guidance

The following pages from Microsoft offer some further guidance:

• Use the Navigation pane in Word
• Insert a table of contents

A further resource that looks to be useful is this useful summary sheet from the University of Aberdeen: Working with long documents.

If you are a TM470 student, you might find the following blog article helpful: TM470 TMA and EMA template.

TM470 is different to other computing and IT modules. The most significant differences is that the aim of the project module is to show off your skills and abilities, and build on what you have studied in earlier modules.

The module team have introduced some changes at the start of the February 2025 presentation. One of their really welcome changes is that they have now introduced a recommended ‘draft structure’ for each of the assignments. Interestingly, this template can also be applied to everyone’s EMA submissions too. 

A notable difference between TM470 and other modules is that all assignments assess all the learning outcomes from the module, but at a different level of intensity.

What follows is my own version of the module team’s TM470 TMA and EMA template, and continues from an earlier blog post entitled TM470 Project report structure. Some of the sections outlines here will, of course, be more appropriate in some TMAs rather than others. In the early TMAs, some of the sections will not have very much in them. All project reports should have a similar structure, but they will differ substantially in terms of content. Every project will have a different ‘project work’ section, which will have a structure that will reflect the tasks identified in your project plan.

I do ask everyone to number each top level section, other than the opening table of contents and the closing summary of references. The reason for this is that numbering makes it easy to provide cross references between each of the sections without having to write too many words.

Before summarising the suggested structure, I have three tips for students:

1. Ensure that your report is as readable as possible (but do make sure it remains a formal report). The project marker may be unfamiliar with the subject that you are writing about. Take time to set the scene and explain concepts that may be unfamiliar to a reader.

2. Do have a look through the OU Skills for Study resources (OU website). In particular, I’m a fan of The Good Study Guide which you can find through the OU study booklets page (OU website). The Good Study Guide offers some really helpful advice about researching and writing.

3. Think of the project report as a ‘technical narrative’, or a ‘technical story’. It is also a story that can contain other narratives. There is a story about your planning, a story about your reading, a story about what has been done, and what has been learnt. Make your technical story as interesting as you can.

Onto my suggested structure (which has been developed from official guidance from the module team). Within the structure, I also highlight how each section relates to each of the module learning outcomes:

Project Title

Begin with a title page where you give your project a short and descriptive title. A good rule is: no more than 10 words, but ideally around 6. Present the title in the Word Title Heading style. Underneath the title, do leave your name and your student number.

This first page links to the following learning outcome:

LO2 (Project Goals) Identify and refine the goals and content of your project which should be within the area of your chosen specialist route, if applicable.

Contents

The next page should share a table of contents. Don’t spent the time creating one by hand; get Word to create one for you. You can do this by using the Word in built header styles to indicate the start of every section and subsection. You can then create a table of contents by pressing on the table of contents button that is located within the references menu. (The exact location of this feature may vary depending on the version of Word that you’re using). In addition to being able to create a table of contents page, using the Word in built headings also enables you to use the document navigation tool, which can be really useful when your project gets larger and more complicated.

A well structured table of contents relates to the following learning outcome:

LO7 (Communication) Communicate information, ideas, problems and solutions clearly.

1. Introduction

In this first opening section of your report, write a really short introduction to the whole of your project. Try to summarise it in a couple of sentences. Then, provide the reader with a pointer towards what they can expect to see in the next sections. This will ‘prime’ them for what is coming up in the next section. You might also want to allude to what you have achieved, but don’t tell them everything; this is presented in the next sections. 

Although this section is the first section the examiner will read, this will be perhaps one of the last sections you will write. When you’ve finished writing your project, it is a good idea to loop back to make sure it continues to reflect the aims and objectives of your project.

This section speaks to the following learning outcome:

LO2 (Project Goals) Identify and refine the goals and content of your project which should be within the area of your chosen specialist route, if applicable.

2. Problem description

In this section, go into a bit more detail about what your project. You might want to explain a bit more about the project context or setting. Background information will help the EMA examiner to understand what your project is all about. In some ways, think of the opening sections of the report as a ‘spiral’, where you gradually lead the examiner towards the detail of what you’ve done. In some way, you’re teaching the reader about your project.

LO2 (Project Goals) Identify and refine the goals and content of your project which should be within the area of your chosen specialist route, if applicable.

3. Planning and resources

The module team section call this section Resources and Planning. I personally feel that it reads better if it is the other way round. My motivation for this is that before you use something (your resource), you need to know what you’re going to be doing with it (your plan). Admittedly, this heading does break my implicit rule of including an ‘and’ into heading titles, which I really hate (an ‘and’ almost suggests that there needs to be more than one heading), but it does relates to two learning outcomes, which are:

LO3 (Determining resources, skills and activities needed) Identify, list and justify the resources, skills and activities needed to carry out the project successfully. Identify and address any associated risks.

LO9 (Planning and organising work) Plan and organise your project work appropriately, and keep systematic records of plans, progress and outcomes.

In the previous section, you’ve told the examiner what you’re going to do. This section is all about how you’re going to do it. Since sharing detail about your project plan is important, it is a good idea to split this section into a number of subheadings.

3.1 Project Model

A suggestion is to begin by telling the examiner about the project model you’ve chosen. Do have a look at the module materials about this, and what this means. In other words, you could use this section to summarise the project planning approach that you have chosen. A good approach is to present a table to show that you have thought about the various advantages and disadvantages of each of the different approaches, concluding with a decision about which module you have chosen, and why it has been chosen.

3.X Resources, skills, activities, risks, plan…

What might follow is a series of subsections about resources that you need, skills, potential risks to the project, and also something about this high level plans. Do say something about what you’re going to be doing, and also what tools you might have used to decide on what you’re going to be doing and when.

What I always like to see is a list of resources that are needed or will be used, a very high level list of activities (perhaps presented in the form of a table), another table that considers the risks to your project, and then a detailed Gantt chart. The structure of your Gantt chart should reflect your project model. If you use an iterative approach, this should be visible within the structure of your plan.

4. LSEPI and EDI

Legal Social Ethical and Professional Issues (LSEPI) and Equality Diversity and Inclusion are important in TM470. As future Computing and IT professionals, it is important to be mindful about the impact of a project or development on wider society, and any implications it might have. Also, if a project involves working with people to uncover requirements, it is important that you treat everyone in an ethical way. The module team offers a bit of guidance about this topic, but for further inspiration it might be a good idea to have a quick look through the British Computer Society Code of Conduct  (BCS website). The Association of Computing Machinery code of ethics also offers some helpful principles.

EDI is intrinsically connected to LSEPI. If you’re developing an app or a software system, you need to consider its users. This might mean making it as accessible as possible for users of assistive technologies, for example. There is a link here to UK legislation, such as the equality act.

I’ve historically recommended that LSEPI and EDI sections are presented early on in the project report. I’ve even been recommending that it should occur before the literature review section (which follows), but I accept this might well be a moot point. My argument is: if significant LSEPI and EDI issues that relate to your project, you need to read about them properly, which means adding to your literature review. Adding them on the end does make it feel as if they are a bit of an afterthought, but I know that certainly isn’t the intention.

Here's the learning outcome for this section:

LO10 (LSEPI & EDI) Identify and address the legal, social, ethical and professional issues (LSEPIs) and the equality, diversity and inclusion (EDI) concerns that may arise during the development and use of computing and IT systems. Include project approval form as Appendix 1.

5. Literature Review

The project team call this section ‘Account of Related Literature’. I prefer the simpler ‘literature review’.

This section is all about showing the examiner what you have read or studied, and how this has influenced the project work that have done. There are different ways to structure a literature review. Two ways are: by theme, or by time. In other words, by the subjects that you have read about, or the order in which you have read things. I always prefer thematic literature reviews since they enable the writer to adopt a more critical approach. This means you can more directly and easily compare and contrast different opinions from different sources.

In this section, do try to reference as widely as possible. Do take the time to reference other modules you have studied (including textbooks and module blocks), any technical textbooks you might be using in the next section, and also do a bit of digging into the OU library (which all students have access to).

Fellow tutors have offered the following guidance: “show you understand the importance of a source; show you recognize the limitations of your sources; show how the literature has influenced the direction of the project and informed your thinking, and show how the literature has justified decisions”.

Here are the learning outcomes that are demonstrated in this section:

LO4 (Gathering, analysing and evaluating information) Gather, analyse and evaluate relevant information to complete the project successfully.

LO6 (Making effective use of information) Make effective use of a variety of information sources including the internet, demonstrating awareness of the credibility of the source.

6. Project Work

I used to call this section ‘account of project work’, but I think a heading with two words is better.

This is one of the most important sections of the report. It shows the examiner what you have done during the course of your project. It should ideally be a series of case studies that presents a narrative (story) of what you have done, and should relate back to the plan that you have described. To structure everything, it is a good idea to separate everything out into a series of subheadings; one for each mini case study.

Drawing on comments from fellow TM470 tutors, the examiner needs to get a feel for the project as a whole, the solution you created, and whether you solved the problem. Importantly, this section should demonstrate your technical and presentation skills, and should be concise.

If you have a project where you have generated a lot of materials, such as interview scripts, survey results, source code, or diagrams, you need to make a choice about what goes in this section, and what you choose to put in an appendix. One way to answer this question is to ask yourself: is this an example of my best work? If so, put something in this section.

Again, here are the learning outcomes:

LO1 (Understanding Technical Concepts) Demonstrate and apply a systematic understanding of the fundamental technical concepts and principles relevant to your project.

LO11 (Analysing and solving a practical problem) Analyse a practical problem and devise and implement a solution which should be within the area of your chosen specialist route, if applicable, building on, and extending, the knowledge and skills developed throughout your earlier OU studies and experience.

7. Review and Reflection

I think the module team call this heading ‘personal development’ which feels a bit general for what it is. 

By the time you get to this section, you would have prepared a plan, have done some research, and have carried out some project work. This section is all about telling the examiner what you have learnt from the experience of running your project. 

To help you to begin to answer this question, think of those “WH” questions: what, how, when, and why? Ask yourself the following questions: Did you follow your plan? Did you learn the right thing, and the right time, to solve the right problem? How did what you learn help or hinder your project? Also, how did you expand on your level 3 studies?

The more thoughtful your review and reflection section appears, and the more that you appear to have learnt by completing the project, the more evidence there will be that you have obtained some of the TM470 learning outcomes.

LO5 (Critically reviewing approach so far) Critically review how you have tackled the project.

LO8 (Learning Independently) Learn independently and reflect on what has been done, with a view to improving skills and knowledge.

8. Summary

I’ve received a query from a student who was asking what was supposed to go in the epilogue. Rather than an epilogue, I recommend that students to write a short summary. A suggestion is: offer a reminder about what the project was all about, what project model was chosen, summarise what has achieved, and then to share three things that have been learnt by completing the project. Your final summary should mirror the introduction section.

This short final section speaks to the project goal learning outcome, the outcomes which relate to technical work, and the review and independent learning outcomes.

References

In academic reports, there is always a references section, but sometimes there can also be a bibliography. I understand that a bibliography is ‘stuff that has been read that have more generally informed the project’. Being vaguer isn’t necessarily helpful when it comes to good academic practice. My recommendation is to ditch a bibliography section, and only have a references section. A references section should present what resources you use.

Clear referencing is really important. One of the aims of this section is to enable the examiner to find an original source, report, textbook, or anything else that has helped you with your project. A useful principle that I’ve heard is ‘anything in the world can be referenced one way or other’. If you’ve used a tip that you’ve found on a website, a bit of software, or an idea from a module, you should reference it.

Make sure that you present everything in alphabetical order, and mention dates of publication. If you’re unsure how to format any resource, book, paper, technical report, or bit of software, do refer to the CiteThemRight website.

Appendix 1 - Project Ethics Checklist

Every project should have an appendix 1 section, which is a copy of an email sent to your tutor that gives ethical approval for your project. A recommendation is to copy/paste the email into this section. The simplest approach to sharing it is probably the best.

If the aim of your project changes, part way through your project, you should always submit a new ethics form. You should include the latest approval email you have received, but you might also want to share earlier versions if it is appropriate to do so. This relates to LO10, which is all about LSEPI and EDI.

Appendix 2 - Project Log

When working on your project, I recommend that all students create a project log. This could take different forms. It could be notes saved in a Word document, notes in an actual paper based notebook, or it could be an email summary sent to your tutor every couple of weeks; these emails could be combined together to form a log of all the work that you have been carrying out. Providing this appendix gives further evidence to support your achievement of LO5. Plus, you can refer to your log in your reflection section.

Appendix 3 - Original Gantt chart

As you make progress on your project, a recommendation is to regularly review your project Gantt chart. It is likely it will change; some of the risks that you have previously written about may (or may not) have materialised, and you may have to adjust your schedule. To help with your reflections, a strong recommendation is to keep a copy of your original Gantt, which you can share as an appendix in your final report. Sharing two Gantt charts will give you something to talk about in your reflection and summary sections. Providing this appendix provides further evidence to support LO5 and LO9. 

Further Appendices

A project report can have any number of appendices in addition to the three that are suggested. You can use an appendix to share supplementary materials to help the examiner to get a feel for what you’ve done during the course of your project. 

There are no hard and fast rules about how many appendices you should have since every project is different. You might use them to show excerpts of source code, diagrams, consent forms, and data that you might have collected during the course of your project. Whatever works best for you. You should, however, always reference each appendix from within the body of the report, just to make the examiner aware that this may be an important part of your report.

Although you must try to limit your project report to 10k words, there is no limit to how many additional words you can provide within the appendices (but the module team does encourage everyone to be reasonable).

Give your appendices a letter, as well as a title. The letter is for cross referencing. The title is, of course, for the reader.

Final points

All these sections of your project report address a really important learning outcome, which is:

LO7 (Communication) Communicate information, ideas, problems and solutions clearly.

When it comes to writing your project report, a really important tip is: make it an interesting read. Whilst this will not, on its own, lead to a higher EMA score, an interesting and readable EMA will help the examiner to relate all the learning outcomes to your submission. 

Acknowledgements

You can include an acknowledgement section in your project report, along with a glossary if you feel it is appropriate to do so. In this post, I would also like to acknowledge Alexis Lansbury, TM470 module team chair, and fellow TM470 tutors for their help and advice.

On Wednesday 30 October 24, the TM470 module team facilitated a module briefing event. On the day, I was only able to attend for a few minutes, so afterwards I went to the recording of the session. What follows are some notes of what I took were the key takeaway points from the session, written from the tutor’s perspective.

Generative AI

The university has devised a simple framework which has been shared to module teams: students muse use, may use, or shouldn’t use generative AI (Gen AI). The TM470 module team position is that students may use Gen AI, but students must use it critically, and clearly (and unambiguously) reference its use. 

This point of clarification led to an interesting discussion. A project might use Gen AI to create resources (such as program code) which may then be critically evaluated and discussed within a project report. A project may evaluate the use of generative AI, but generative AI should not be used to write parts of a report; doing so would be a breach of academic conduct. Students must be clear about what was, and what was not produced by Gen AI.

The module team will share some guidance on the tutor’s forum.

Ethics approvals

The university now has a requirement that all student projects need go through an ethical review process. This now applies to TM470 projects.

Here is a summary of how I currently understand the process that has been set up:

1. A tutor will have a conversation with a student to enable them to understand more about the broad aims of their project.
2. Students complete an online form which aims to collect a summary of their project idea. 
3. The tutor will determine whether the student’s project will meet the criteria for an appropriate project; they either approve a project, or they refer a proposal to the module team.
4. If a project is approved, then students receive a confirmation email which contains some further information and guidance.

To facilitate this process, there is a new TM470 Project Ethics approval portal, which has three views: a student view, a tutor view, and an assessment panel view.

Students submit their form through the student view, where they give a title, and a brief description of their project, and answer set of simple questions. These questions ask whether the project will involve people, may involve animals and/or plants, and how data protection will be dealt with.

From the tutor’s perspective, the portal will share a summary of all the students in your group. When reviewing the student’s ethics form, there will be a space for tutors to respond to the information that a student has shared. You may, for example, offer further guidance, or say that a further conversation is necessary. 

All these records are saved in a simple database which facilitates to the Faculty Board of Studies, showing how everyone has engaged with a process.

Early conversations with tutors is essential, so tutors can potentially steer students away from projects that might be difficult from an ethical perspective.

If there are changes to the aims and intent of a project, there could be either a new form, or additional information could be recorded that a change has taken place.

Changes in module assessment

There have been some important changes to assessment strategy for the forthcoming module presentation.

There will be a greater weighting to the important Computing and IT elements to ensure that the module meets both current and future accreditation standards. There will also be more emphasis that students must demonstrate how they have extended their study of their level 3 modules.

As with earlier presentations, there will remain 5 groups which cover each of the 11 learning outcomes. An important difference is that these learning outcomes will now be more explicit in terms of where to award marks, and what for.

The module team will be sharing a very basic TMA template for students, but tutors are free to suggest their own versions and alternatives. A recommendation is that students adopt whatever template they choose for TMA 1, and then use it for forthcoming TMAs.

TMA 1 will now become more of a proposal: what they aim to do, and how they how to do it. TMA 2 and 3 will be now known as interim reports; TMA 3 will no longer be known as the draft TMA. Students should, of course, write enough to evidence each of the learning outcomes. In other words, students can write more than the 10k word limit, but some practical advice is: don’t go too far over, since if you do, this might influence the ‘communication’ learning outcome.

Reflections

I welcome the introduction of the ethics processes for the simple reason that the processes will help to facilitate conversations between students and tutors. It is also right and appropriate that ideas that relate to projects are scrutinised and considered.

I also welcome the tightening of the criteria that relates to learning outcomes. This can only help with clarity for students, and consistency in marking.

Acknowledgements

Many thanks are extended to Alexis Lansbury and Chris Gardner. A number of TM470 tutors were involved in proofreading the updated guidance.

When planning your project, an important question to ask is: how can I tell if my project has been a success?

The extent of your evaluation very much depends on what you do during your project. For some projects, you might consider asking your stakeholders the question: “does this solve your problem?” You can ask this question in different ways: you could prepare a short survey (if you have a number of stakeholders), carry out an interview, or carry out a usability study.

If you consider design (rather than coding) to be your strong point, you may choose to carry out an interaction design project, where the output may well be a detailed high level prototype that could be presented using a prototyping tool. Since you may sidestep some of the important software development skills that you might otherwise demonstrate, is really important to ensure that you carry out your interaction design project in a really thorough way to clearly satisfy the requirement that your project is all about computing. If you are confident with software development and enjoy this aspect of your studies, you may well want to combine design with an aspect of software development; it is completely up to you.

Most interaction design projects are iterative. In fact, a practical recommendation is that a solid project that is based on the interaction design module should have three different development iterations, or phases. The thinking behind this is that this gives you the best opportunity to demonstrate your skills. When you get to the end you may want to ask the question: has my project solved the problem I set out to solve?

Consider an example of an app that could to pre-order a coffee from a local café, or to book a slot for your dog in a pet grooming parlour (you can choose another example if you prefer). 

Iteration 1: First initial sketches

Designs can be presented (and detailed) using different levels of fidelity, which (of course) relates to the idea of detail. A low fidelity design (or sketch) might be a rough sketch on paper (which is known as a paper-based prototype). A high fidelity design might be a design that closely resembles the final product. There are other terms that you might want to consider too: the idea of a vertical prototype (a prototype that covers a small bit of functionality in a lot of depth), or a horizontal prototype (a prototype that covers all the functionality of a product, but in a small amount of depth).

You might begin your design by creating some low fidelity designs, perhaps using paper-based prototyping. In other words, writing a bunch of sketches. You might want to combine this with other approaches from interaction design, such as the writing of user profiles and scenarios. It is up to you. Whatever you do needs to link back to the requirements of whatever it is you are designing. Different products will treat requirements in different ways.

When you have completed your first round of sketches (which could be made either using a pen or pencil, or using a tool), you should show them to whoever has the problem that needs to be solved (the café owner, or manager of the pet grooming parlour) to carry out your first round of evaluations.

Iteration 2: Wireframes

When you have received feedback, and have further refined your requirements, it is then a good idea to try to flesh out your design. You might have a second round of sketches, or you might move from pencil and paper to a prototyping tool. Choose whatever tool or product works best for you and your project.

When you have completed you second set of designs, go back to your stakeholders to get some further feedback. Here you should get some useful data (information about what works well, and what needs to be looked at in a bit more detail) to further refine you prototype further.

Iteration 3: Higher Fidelity prototypes

A high fidelity prototype is all about showing what a final (or polished) version of a product or system might look like. With this final iteration (or phase) you might get elements of your designing working. You may well develop software and create databases. 

As well as considering prototypes in terms of low and high fidelity, there is another couple of dimensions that can be considered helpful: horizontal and vertical prototypes. A horizontal prototype is a demonstration of a design across all its key functionality, but to a limited depth. A vertical prototype, on the other hand, means that you implement a small amount of functionality in a lot of depth. With a vertical prototype, you may well ‘go deep’ with the technology; you may have to choose appropriate software components and frameworks, and justify your choice.

When it comes to your project report, you should share your high fidelity prototype by walking your examiner through a series of screenshots.

Depending on the aim of your project, you might stop at this point. You may well have demonstrated a lot of technical skill and knowledge in a lot of detail. If your project is less about practical software development and more about design, it would be a good idea to carry out a final evaluation of your prototype to answer the question: does my design do what it supposed to do?

Using the DECIDE framework

The DECIDE framework can help you to plan (and run) an evaluation. It is featured within the interaction design module and its accompanying set text. Taking a letter at a time, here are the components of the framework: 

Determine the goals (of your evaluation): What are you aiming to get from your evaluation? Remember, this isn’t the goals of your project, it is the goals of your evaluation. What do you need to do to determine whether it is a success.

Explore the questions: What questions are you trying to find answers for? Or, alternatively, what questions do you need to ask to carry out an evaluation?

Choose the evaluation approach or paradigm: How are you going to approach your evaluation? You can choose a number of different approaches. You might wish to carry our a heuristic evaluation (which doesn’t involve users), a predictive evaluation (to predict how efficient your design is, perhaps using a cognitive walkthrough approach), or user testing (which can involve real users).

Identify the practical issues: This point relates to the detail of how you run your evaluation. If you need participants, how will you go about recruiting them? How will you ensure they are representative? How will you collect data? Will you be making notes on a data collection form, or if you’re carrying out an interview, will you be using the voice recorder app on your mobile phone? When you have captured data, where will you be storing your data, and how will you be making sure your data is secured.

Decide about the ethical issues: If you involve anyone in your evaluation, you need to think about ethics. Essentially, you need to gain permission, and you need to make sure that everyone knows what your evaluation is all about. An important point to emphasise is that you’re carrying out an evaluation of the performance of a product or a solution rather than the performance of your participants. Remember that your participants are always more important than the task of completing your evaluation. 

Evaluate: With your evaluation all planned, your data collection approach chosen, and permission gained, it is now time to carry out your evaluation. After you’ve gathered your data, it is time to analyse your data, interpret your data and then share your findings. In terms of your project report, this will mean the need to write a summary or conclusion.

Carrying out your evaluation

The DECIDE framework helps you to understand why you intend to carry out your evaluation, what criteria for success you consider to be important, and how you intend to carry out your evaluation.

If your project has an evaluation section, a recommendation is to show what you did in series of step by steps. In other words, adopt a narrative approach. Use a series of appendices to share the resources you may have created during the course of your evaluation. If participants are involved in your evaluations, consider taking a photograph of the environment in which an evaluation takes place, sharing that photograph within the body of your report.

Reflections

Although I have suggested three phrases or iterations is often appropriate for an interaction design project, there are no ‘right’ number of iterations. Every project is different. Whilst carrying you’re your project you may discover that you need more phases, and more evaluations.

References

Rogers, Y., Sharp, H., Preece, J. (2023) Interaction Design: Beyond Human-Computer Interaction, 6th Edition. Wiley.

A question that I’m regularly asked is: “what do I need to submit?”

The answer is pretty simple: you only need to submit a Word single document. Some obvious follow questions are, of course: “what should my Word document contain?” and “I’ve written some software as a part of my project, should I include this? If so, how?” or “During my project, I’ve done a lot of design work, and I have a load of sketches and some prototypes – how can I submit these?”.

A principle to return to this: TM470 is all about showing off. You can ‘show off’ in a couple of different ways. One of the most important sections of your EMA is the section of your report that summarises the account of the work that you have carried out on your project. In this section, you should make sure that you highlight the best bits of work that you have done. This might include a design, a diagram, or bits of code for important functions that may have been particularly develop. If you have a lot of code, or many different screenshots or sketches, choose the best ones, and put all the others within a series of appendices. An important point to remember is: you can include any number of appendices in your EMA report.

A related question that I’m sometimes asked is: “should I include a weblink to some working software, or an app that can be downloaded?” The answer is: no; you don’t have to do this. Whilst your examiner (the reader of your EMA) may appreciate this, there isn’t an obligation to provide links to a working version of any software you have created. Your project report must, however, be sufficiently detailed to ensure they can evaluate the learning that has taken place over the duration of your project.

If your project relates to a particular setting or context, a further practical suggestion is to provide some photographs of that setting. If you are developing an app that solves a problem, you might want to include a photograph of the setting where your app is used. Give your photograph a figure number, and refer to it in the body of your text.

To summarise, you only need to submit a written report, your EMA. You don’t need to need to provide a working prototype, but you do need to provide sufficient detail to ensure that the examiner is convinced about what you have done. If you haven’t got things working at you had hoped, it is okay to say this too; this makes for an interesting report. It isn’t what you have built that is the focus, it is what you have learnt (and demonstrated) through the building of something, and how you write about it that really matters.

The nature and character of risk can influence your project in a big way. 

To begin, it is perhaps useful to define what risk means. Drawing on the M815 project management module, I have found the following two definitions:

‘The potential of situation or event to impact on the achievement of specific objectives.’ (APM, 2019, p. 215)

‘An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.’ (PMI, 2017, p. 10)

Fundamentally, risk can influence your choice of project model, and directly influence how you gather requirements. If everything is known, and you are not going to be doing anything risky, you might opt for a simplistic project model. If there are elements of your project that you know nothing about, and have never done certain tasks, you might choose an iterative approach.

When you have chosen a project model for your project, you can then start to think about how risk will potentially influence the different phases of your project. To do this well, you need to a number of things:

Write your risks down. By doing this, you will begin to create what is sometimes called a risk register. 

• The next task is to consider how important your risks are.
• You the need to consider how to deal with those risks.
• In some cases you may choose to mitigate against risks. In other words, if these risks were to appear, you need to know how to respond to them.
• After having done this, you then need to make some changes to your plan. You might, for example, choose to add more slack into certain elements of your schedule if you need to use some of your mitigations.

When it comes to TM470 you should be carrying out risk planning from the very start of your project since it can guide what you do. Importantly, LO3 directly relate to how you deal with risk:

L03. Identify, list and justify the resources, skills and activities needed to carry out the project successfully. Identify and address any associated risks

To gain a distinction, you must have

… identified the resources, skills and activities, the timely availability of which is essential. Has judged risks appropriately.

Module materials

There are a number of sections within the TM470 module materials that you should look to.

Section 2.5 Risk in project lifecycles: This section relates to the point that the structure of your project may well be driven by risks.

Section 3.2 Risk Assessment: This section encourages you to consider risk in two different ways: impact, and likelihood. There are three different levels of each. A practical suggestion is offered; you might want to think about creating a risk table (which is a bit like a mini risk register). The decision on how you present and summarise your risks is, of course, up to you. It is, of course, dependent upon your project.

Section 3.3 Risk management: This is about how you deal with the risks that you identify. Do you avoid a risk, find a way through, or accept that something is a risk?

Risk analysis

In the TM470 FAQ a fellow tutor, Karl Wilcox, has written about the notion of risk analysis, which extends what is mentioned in sections 3.2 and 3.3. Karl begins with a simple question: where do risks come from? Karl offers some practical advice:

‘One primary source is the list of resources that you need for your project (which is why we ask you to provide one). Since you have identified a need for each of those resources, the lack of any resource will affect your project plan to a greater or lesser extent. Some might be trivial but you should definitely go through all your resources and ask yourself whether each one should have an entry in your risk register or not.

The other main source of risks is "external events". Obviously, you need to be a bit sensible about this and really just consider events that apply specifically to you, so illness, illness of a family member, unexpected work commitments, etc.

Finally, there is a smaller source (that may not be relevant to your particular project) but is there a possibility that some part of your project turns to be impossible? (Or more likely, prohibitively difficult). Do you need to develop new skills? (Another reason we ask for a list of these…) What if it turns out that something just doesn't "click" and you find that skill too hard? Are there any possibly technical or legal or ethical issues that might arise?’ (Wilcox, 2024)

Karl relates a number of potential risks to the different tables that you have been asked to create. For each skill or resource, is there an accompanying risk?

How do we deal with, or mitigate our risks? Karl offers some practical advice, which I abridge for brevity:

‘These [mitigations] can take many forms, from exploring alternatives, adding in contingency time, or sometimes carrying out activities specifically to minimise risk, or at least to bring forward a better understanding of them. … Active steps include things like taking backups of all your work to mitigate the risk of hardware failure, or replacing a laptop that you know to be a bit flaky. If you need input from other people, can you at least get some time in their diaries now, rather than leaving it until later to find out they are not available?

In reality, especially with the limited timescale (and limited personnel resources!) of a TM470 project the most likely response to a risk actually arising is "do fewer things", but again you can prepare for this. Are there parts of your project that you can consider as "stretch" goals, to be achieved if everything goes well but that can be set aside if things go ill? Can you perhaps arrange your plan so that a crude "prototype" of your final deliverable can be developed early, so at least you will have something working if things fall apart at a later stage?’ (Wilcox, 2024).

Karl’s comments about ‘stretch goals’ is both interesting and useful. Another way to think of this is in terms of what a ‘minimum viable product’ might look like. Here we can see an implicit link between the project model and risk. For example, if things do go ‘ill’, we may well wish to curtail a final iteration (if we adopt an iterative lifecycle, of course).

It is worth noting that Karl takes all this pretty seriously: 

‘So I don't see the "Risk Analysis" part of TM470 as simply being a "paper" exercise, in which the construction of a risk register listing risks, likelihood, impact and mitigation for a dozen or so factors is presented in TMA01 and then ignored. That may well gain you some of the marks but it can actually be a genuinely useful exercise that will affect what you do and how you do it and give you a much better chance to complete the project to your own satisfaction and gain better marks all around!’ (Wilcox, 2024).

The Risk Register

Following on from Karl’s FAQ, fellow tutor Trevor Forsythe shared a forum post with his TM470 students, outlining what types of information that you might hold in a risk register. His post had been based the PRINCE2 approach to managing risk (PRINCE2, 2024).

Trevor began by writing: ‘this is one of those learning outcomes that is regularly reviewed, and we are looking to see how students assess and manage risk. A quick search of the Internet will identify a number of risk templates either in word or Excel formats. There is no mandated template to use so you will have to identify one that you think works for your project. As an example, a risk register could contain the following …’

What follows is an abridged and edited version of what Trevor shared (which draws on the PRINCE2 original):

• Risk identifier: Provides a unique reference for every risk entered into the risk register, typically a numeric or alphanumeric value.
• Date registered: The date the risk was identified. This is helpful with knowing whether the current version of the risk is the one that is up to date.
• Risk category: The type of risk in terms of the project’s chosen categories (e.g. schedule, quality, legal, technical, learning, hardware). 
• Risk description: The risk in terms of the cause, event (threat or opportunity) and effect (in words of the impact) e.g. "my hardware could fail and I lose all my software development".
• Probability impact: It is helpful to estimate the inherent values (pre-response action) and residual values (post-response action). These should be recorded in accordance with the project’s chosen scales.
• Proximity:  This would typically state how close to the present time the risk event is anticipated to happen (e.g., imminent, within the management stage, within the project, beyond the project). Proximity should be recorded in accordance with the project’s chosen scales.
• Risk response: Actions to be taken to resolve the risk. These actions should be aligned with the chosen response categories. Note that more than one risk response may apply to a risk. For example "regular backups of software and configurations will be made into a cloud storage system e.g. OneDrive or Dropbox”.

Materials from other modules

Although TM470 is primarily intended to build on your earlier level 3 studies, if you have previously studied TM254 Managing IT: the why, the what and the how, it is worthwhile visiting Block 3, Part 6: Software quality, risk and risk management. In this block, there are three sections which have particular relevance to TM470, which are: Section 3.1 Categories of risk, Section 3.2 Risk assessment, and Section 3.3 Risk management. It is also worth noting that the TM254 module website (which you may still have access to, if you finished studying this module only a few years ago) has an extensive glossary, which defines the terms: risk register, risk mitigation, risk management, risk exposure, risk reduction, and others.

Although risk isn’t explicitly studied in TM353 IT systems: planning for success, it might be useful to review Block 3, Part 3, Part 3 – How to recover from failure: Business Continuity Planning, which includes a Business Continuity Management Toolkit.

Looking forward to the OU postgraduate module, M815 Project Management, sees the link between risk and project planning and management discussed and handled in quite an extensive way. Risk management is, of course, a subject all of its own. 

Summary

Risk can guide not only what is done, but how things are done. In TM470 LO3 indicates that you need to demonstrate your understanding of risk, and how it relates to your project. For the sake of TM470, a practical approach is necessary. It is important to keep things simple (since the project only lasts for a relatively small amount of time), but it is important to make sure that risks are clearly and carefully considered. A practical recommendation: create a risk table, and keep it updated throughout your project. When you get to the end, make sure you reflect on your approach to risk, and what you learnt from it.

References

Association for Project Management (APM) (2019) APM Body of Knowledge. 7th edn. Princes Risborough: Association for Project Management.

Prince 2 (2024) Prince2 wiki: Risk Register. Available at: https://prince2.wiki/management-products/risk-register/  (Accessed 15 April 2024)

Project Management Institute (PMI) (2017) PMI Lexicon of Project Management Terms. Version 3.2. Available at: https://www.pmi.org/pmbok-guide-standards/lexicon (Accessed: 15 April 2024). 

Wilcox, K. (2024) Risk Analysis - what makes a good one?  TM470 FAQ.

Acknowledgements

Many thanks are ended to Karl Wilcox and Trevor Forsythe whose words have directly found their way into this article. Thanks are also extended to the TM470 module team, and the other module teams that are mentioned: TM254 and TM353.

One of the interesting things about the OU Computing and IT (Q62) qualification, and closely related qualifications is that it is accredited by the British Computer Society (BCS).

The TM470 undergraduate project module plays an important role in that accreditation, since it enables students to gain direct experience of running and managing their own project, which is an important graduate skill.

Although I’m not (yet) a member myself, the BCS is what you call a professional association. It supports, develops and campaigns for its members. Gaining an OU Computing and IT degree means that you may be able to apply to become something called a Chartered IT Professional (CITP). If you become a BCS member, and a CITP, you can be accepted into something called a public CITP register, which is a further formal accreditation of your status and standing as an IT professional.

Universities that offer degrees that are accredited by the BCS have to go through a formal accreditation process, which is described in an accreditation guidelines document (BCS, pdf).

For those studying TM470, it is worth having a quick look at section 2.5, which is about major projects which are described as follows: “projects must include the students undertaking practical work of some sort using computing/IT technology. This is most frequently achieved by the creation of an artefact as the focus for covering all or part of an implementation lifecycle.” (p.12).

What follows is an abridged version of a summary of what a final project report should contain, according to the BCS (p.12):

• Elucidation of the problem and the objectives of the project.
• An in-depth investigation of the context and literature, and where appropriate, other similar products.
• Where appropriate, a clear description of the stages of the life cycle undertaken.
• Where appropriate, a description of how verification and validation were applied at these stages.
• Where appropriate, a description of the use of tools to support the development process.
• A critical appraisal of the project, indicating the rationale for any design/implementation decisions, lessons learnt during the course of the project, and evaluation.
• A description of any research hypothesis.
• In the event that the individual work is part of a group enterprise, a clear indication of the part played by the author in achieving the goals of the project and its effectiveness.
• References

Looking at the project from another perspective, undergraduate students must demonstrate:

Their ability to apply practical and analytical skills present in the programme as a whole.

• Innovation and/or creativity.
• Synthesis of information, ideas, and practices to provide a quality solution together with an evaluation of that solution.
• That their project meets a real need in a wider context.
• The ability to self-manage a significant piece of work.
• Critical self-evaluation of the process.

For TM470 students, all these elements are reflected not only in the module materials, the tuition that is offered by tutors, but also the TM470 learning outcomes (blog). There is also an implicit link here to my more practical suggestions about TM470 Project report structure (blog).

There is, of course, no compulsion or requirement to join a professional association like BCS when you have completed TM470. It is completely up to you, but it does give you a further opportunity to formally recognise your skills and abilities.

Acknowledgements

Acknowledgements are duly given to the BCS. The bullet points summarised above can be found in their accreditation guidelines document, which was last accessed 12 March 2024. At the time of writing I have no formal connection or link to the BCS.

At the start of every presentation of TM470 I run a couple of introductory tutorials. During these tutorials, I try to conclude with a set of tips. These are things to do, and things to always bear in mind whilst studying. The tips that follow relate to the different aspects of the module. In this blog I have taken the liberty of adding one more point that relate to the writing of the project report. (On this point, do refer to earlier blogs that relate to writing and TM470, and how to structure your final project report).

Here are my (personal) tips:

Choose a project that allows you to show off your skills (and have fun): The project module is all about showing off. It should be used to show off what you have learnt, what skills you have, and what you can do. It is used to show off your technical skills, project planning skills and writing skills (which is an important graduate skill).

Think about the type of project it is: there are three types of project – research projects (you study something), development projects (you create something), and evaluation projects (you evaluate something). Depending on what you have chosen, your project might have elements of all three. Identify which bit you might be doing, and when you might be doing it.

Choose (and justify) appropriate lifecycle model: different types of project need to be managed and run in different ways. Familiarise yourself with the different lifecycle modules that are presented within the module materials and ask yourself why you need to choose one approach over another.

Spend time creating a project plan (and share a plan in each TMA): demonstrating your planning skills is a really important part of the project module. Not only should you identify a list of key tasks that you may need to complete, but you should also create a Gantt chart. A practical recommendation is: create a Gantt chart when you start the project, and take a copy of it. As you progress throughout your project, make regular updates. When you get to the end, compare your first Gantt chart with your current Gantt chart. Write about what this tells you about either yourself or your project planning. Add these thoughts to the reflection section of your EMA.

Take time to identify risks: what are they? Risk management is important. You need to take account of these within your plan, and consider how you may need to mitigate against them. Different projects will present different risks. Consider both your own role within the project, and the types of resources that you need to complete your project.

Always consider about ethics within the project: consider ethics from different perspectives – the ethics of involving people within your project, and also the ethical implications of how the outcomes of your project might impact on others and wider society.

Start your reading and researching (use the library): make good use of the university library. A part of your student fees always goes towards it, and it is a phenomenal resource. Do use it to find academic articles that help you to answer some of the problems you need to solve during your project. You can also use it to find textbooks to help to solve technical problems.

Create a project log, and send me updates every week: a project log can help you to reflect on what you have done during the course of your project. This can be especially useful when you write everything up. Sending an update email every two weeks to your tutor can also play the role of a log. Any emails that you send can also be saved as an appendix, to show an examiner that you have maintained regular contact with your tutor.

Take time to review the marking grids: in other words, make sure you understand what the TMA and EMA learning outcomes are. Once you understand these and know what they are, you can almost mark yourself. Use these grids to understand what evidence you need to provide in your assessments, and your final project report.

Pay attention to how your project report is written: when projects are assessed, the project is evaluated through what is shared in your project report. This means that your writing is important. Do your best to make your report as interesting as it can be. Make sure that it has a strong (and clear) narrative in terms of what you have done, what you have learnt, and what you have achieved. As well as your outputs and outcomes, make sure you tell the examiner how you have approached your planning. Clear writing will help your examiner identify evidence to show how you have gained the module learning outcomes.

Reflections

Although these are my personal tips, students should always refer to the module materials in the first instance. Other tutors may we have different (although hopefully) similar opinions. If you’re unsure about what you need to do, or how to present evidence within a TMA or your project report, please do seek advice from your tutor, or by making a post to the module forums.

When I was doing my doctorate I was introduced to a reference management tool called EndNote. Essentially, it’s a tool to help with your referencing. 

Refencing is a pain. Different publications require references to be done in different ways. Doing computing research took me to other disciplines, such as psychology. There was a striking difference between how referencing was done in, say, a psychology journal, and how things are done in an IEEE journal. All this can be really frustrating an annoying when you’re writing articles for different publications and conferences.

The idea is that you save records of whatever articles and resources you are using during your research (or writing), and after doing this, you can use a Word plug in to automatically generate a set of references in the format of your choice. This way, you don’t have to endlessly waste time editing and adding commas, numbers, and spaces.

It worked a bit like how the Word table of contents feature works. With table of contents, you indicate what is a heading, and then you can ask Word to generate a table of contents at the start of the document. With referencing tools, if you want to use a reference, you add in a citation. When you come to generate a set of references, it will pick up that you’ve used an article, and it will add it to your references list. It will even sort everything into alphabetical order if your referencing format needs that approach.

As well as referencing, I found it really helped my reading, and the process of figuring out what was going on in my research area. I was able to upload some notes about a paper, recording why I thought an article was important, and even when I had added it. You could add keywords, search for authors, order them (and article titles) alphabetically. When I was doing my research, I actually had these paper-based lever arch files with copies of articles I had photocopied from the university libraries. I would save the volume number and section heading in my reference database.

I recently found a floppy disk (yes, I’m that old) that contained all my EndNote references. I think I could still use the data on the disk, but I kind of stopped using EndNote, since I moved away from doing research. I’ve returned to the point where I feel as if I need to return to starting one of these tools again – not to help with my writing (although I might be doing that at some point), but with my reading.

Since I started to use EndNote, towards the end of the last century, I have discovered there are now a couple of competitors: Zotero and Menderley. The mechanisms for finding an using papers have changed: rather than going to the university library, sitting on the floor, and photocopying articles, we now have easy access to extensive online research article databases (if, of course, we are working or studying within a university). What follows are some (short) rough notes about both of these tools.

Zotero

I began by having a look at Zotero. It wasn’t too long before I found a Wikipedia page that offers a bit more information. 

It’s interesting to note that Zotero is run by an organisation called the Corporation for Digital Scholarship. 

I began by creating an account, and then downloading a bit of software that runs on my laptop. This bit of software enables me to save information about references that I’m working with (such as books, journal articles, or anything else). I also mange to install a browser extension plug in (which is called a Zotero Connector), and a Word plug in.

When I open Word, I can see a new menu, which reminds me of my old EndNote days. I can see the Zotero Connector, when I look at my list of browser extensions. I note that there’s a new keyboard extension: Ctrl + Shift + S.

There’s another thing that is interesting: a way to share resources with fellow researchers by setting up something called a group. More information about this is available through the Zotero groups page. 

One of the grumbles that I have heard is that it might be hard (or harder) to move between different devices (but I don’t yet know how true this is). Whether you need to do this does, of course, depend on how you work. One thing I have seen in Zotero is an extensive set of import and export formats. A long standing format that predates both these tools and EndNote is something called BibTex. With this in mind, and being told that I can move between referencing systems, makes me feel a bit better.

Mendeley

The other tool that is around is Menderley. Unlike Zotero, it is supported by a commercial academic publisher, Elsevier. Like Zotero, you need to install bits of software and some plug ins; there is a bit of software that enables you to save your references. An interesting difference is that to gain access, I needed to formally login to the publishers’ digital ecosystem through the university. It appears to be slick and relatively easy to use. From what I’ve heard, it does provide similar functionality.

Reflections

A key question to ask is: which one am I going to use? I did consider going back to EndNote, since it’s what I’ve used before, but after hearing that two of my colleagues are using Zotero, and seeing how easy it is to install the various bits of software, I’m going to try out Zotero. 

I’m going to give it a go to produce references and citations for my next TMA, which means I’ve got to figure out how to add course texts and online materials into the Zotero software that I’ve installed. I would also like to know where everything will be stored. Backups are important. I will, of course, be having a good look at the CiteThemRight guidance, to make sure that whatever set of references are automatically generated are in keeping with official university guidance.

A final reflection is that reference management tools can be useful for undergraduate students too – especially for those who are working on dissertations, end of module assignments, and substantial projects. Like everything, do expect to make an investment in time to figure it all out, and to create your own reference database. It’s very early days for me with Zotero, but I’m hoping it’ll make some aspects of my writing easier. As suggested, I’m hoping it will help with my reading too.

This blog offers some more practical tips on completing the TM470 literature review section. In some ways, it follows on from an earlier blog on the same subject.

Three points are shared. The first is some techniques about how to think about and consider papers. The second presents some useful resources about academic writing. The third offers some suggestions about how to structure your literature review section.

The literature review section of your project report does a number of things. It shared with the reader something about your reading. In doing this, it helps the reader to understand what your project is all about, and what it relates to. It also primes the reader for some of the topics that will feature within the body of your report. If you use module materials, books, articles, or software, they should be referenced within the literature review section. The reader shouldn’t be surprised, and think: “where did that come from?”

If your project report is all about showing off what you are able to do, the literature review section is all about showing of what you know.

PROMPT

The PROMPT framework that can be useful when preparing a literature review. It is introduced in an online resource called Being Digital.

PROMPT is an abbreviation for: Presentation, Relevance, Objectivity, Method, Provenance, and Timeliness. It offers a structured method that can be used to evaluate any information that you find online. What follows is an edited summary of the key elements of the framework, which have been drawn from a PROMPT Checklist (PDF)

Presentation: Is the information presented and communicated clearly? Consider the language, layout and structure of the resource that you’re evaluating. Does it look ‘academic’?

Relevance: Is the article relevant to the topic you are researching? Look at the introduction, abstract or overview to find out what it is mainly about. When reading an article, to get a quick feel for it, you might also want to have a read of the concluding paragraphs. Do these relate to the aims of your project?

Objectivity: Is the article biased, or motivated by a particular agenda? Is the language emotive? Are there hidden, vested interests? In some articles, there is a section which might highlight any potential conflicts of interest, or how it is funded. This criteria is, of course, link to relevant, and to the thought of ‘does it look right?’

Method: For research articles, ask yourself whether it is clear how the data was collected. Given what you know of both the paper and the topic, were the methods appropriate and can you trust it? When evaluating a method, do have a look out for research questions. Do they match?

Provenance: Is it clear where the information has come from? Can you identify who the authors are, and who they work for? Can they be considered to be trustworthy?

Timeliness: Articles can lose their relevance. Important questions to ask are: how up to date is the material? Is it clear when it was written? Also, does the date of writing meet your requirements, or would it be obsolete? This is particularly important with fast moving areas, such as Computing and IT.

Another approach: the wheel

Ideally, the literature review chapter should be a story about your reading, sitting within a bigger story, which is your whole project. There are different ways you can present your findings: you can present it in terms of chronology (the order in which you read articles and papers), or you can structure it thematically. 

For TM470 where there is a limited word count, the thematic approach can work really well. It gives you an opportunity to highlight the connections to module materials, and then to share evidence of further reading, allowing you to show how you have ‘dug deeper’ into the subject.

A more sophisticated approach to discussing and presenting the materials that you gather during a review is expressed in the ‘the wheel approach to literatures’ blog. It adopts a model known as: And, But, Therefore.

The Wheel goes beyond what is required for TM470. You should aim at highlighting what you consider to be important, and why. The Wheel may well be helpful for students going onto postgraduate study, or students from disciplines where writing takes centre stage. The point amongst all this is: writing and structuring complex and detailed documents is a graduate skill, irrespective of what you study.

Types of literature

When working on a project that involves creating a solution to a problem, there is often a temptation to use blogs, reports or articles found on the internet. These types of articles are known as ‘grey literature’, which means they are not formally published in the way that books or academic articles are. This means they are subject to a lower level of scrutiny. When working with grey literature, a good question to ask is: is there another, more formal source? If the answers is ‘yes’, then please refer to the more formal source. By doing this, you acknowledge the articles that are contributing to academic discussions and debates that relate to a particular topic.

A good example of a resource that is really useful is, of course, Wikipedia. A reference should be something that is static and does not change over time. Since Wikipedia pages can easily change, a recommendation is to avoid using them as formal references. Instead, use them as a way to find more formal references. Look at what Wikipedia references, and then go and find those articles in the OU library.

Referencing

If something exists in the world, it can be referenced.

When writing a formal report, the most common type of references will be, of course, books and articles. You should also, of course, include clear references to module resources. Arts students can reference physical artifacts, photographs and paintings. Students studying computing and IT can, of course, reference software and technical standards.

To find out how to reference anything, visit the CiteThemRight website. The OU makes use of the Harvard referencing style, which takes the form: Author, Initial (year) Title of item, where it was published, and any page numbers (if appropriate). 

Module materials

Before preparing your literature review, it is a good idea to read through the 'Preparing a Literature Search' page. This shares four stages of a literature search, which offers a helpful framework:

1. identifying and locating relevant materials
2. comprehending the content
3. abstracting the significant content, systematically recording and categorising this content and the related references
4. synthesising the content and relating it to your project aims.

Academic writing

Every part of your TM470 project report should be written in an academic style. More information about what this means can be found by visiting the following article: Academic writing in TM470. 

A disclaimer: this is guidance from a TM470 tutor, rather than from a member of the module team. Always refer to the official module team guidance to really appreciate what they are looking for.

Further guidance about writing can be found in the Core Skills section of the Study Skills website and the Open Learn Write it right: seven common writing resource.

Reflections

The TM470 project module is all about showing off in a number of different ways: it is there to show off your ability to pick a sensible project idea, it is there to show off your technical skills, and it is there to show off how you go about planning a non-trivial project, and it is there is show of both your reading and your writing skills. The literature review section is a really important part of a TM470 project report, but it is very often a part of the report that isn’t done as well as it could be. It is important because it sets the scene. It tells the examiner what you know.

Here are my tips: 

1. In your literature review, mention earlier module resources, and dig a little further.
2. Unless you’re referring to software, do your best to use and refer to academic resources.
3. Make sure that you spend quality time looking in the OU library and make notes about what you’ve been looking at. Use PROMPT to interrogate (or figure out) what you’re looking at.
4. If you reference something in the literature review section, it should ideally be used or applied in the body of your report in some way or another.
5. When you write everything up, structure your literature review in terms of themes.
6. It is all about showing off. Because this is important do make what you write as clearly possible.
   

On this final point, I recently heard the following bit of advice from a fellow tutor, which was shared on an OU forum: “why choose a complicated word when a shorter word would work”. The easier your report is to read, the more secure the examiner will be in making their decisions, and awarding marks.

TM470 projects can take many different forms. 

Some might be design projects, some might be research projects, and some might be development projects. One of the most important points that all students should bear in mind is that there is a need to share evidence of project activity and learning that takes place.

Evidence is shared only through the project report. If your project is all about software development, you are not required to upload software to a GitHub repository, or to provide examiners with a working version of anything you may have designed. You should, however, provide evidence of software development having been carried out, and must provide evidence of critical thinking you have applied. In other words, you should write a technical story that describes how your software was created. Although every project is different, your report should share the story of requirements discovery or specification, design, development, evaluation, and testing. The number of times you carry out an evaluation cycle is, of course, completely up to you.

I am sometimes asked a question, which is: how should I share code through my EMA report?

A case study approach

You don’t need to share all your code. 

You should share your code in two ways: in the body of the report, and in an appendix.

For the body of your report, choose bits of code that best demonstrates your technical skills and help to demonstrate a technical story of what you have done, and how you have done it. You should also show how you have drawn upon modules you have previously studied.

Think about the body of your report as a showcase, where you share a series of mini case studies which demonstrate your skills, abilities, and learning. Providing snippets of code in the body of your report that highlight show the important and difficult problems that you have had to resolve during the course of your project. In the body, you can then provide a pointer to one or more appendices, where you can provide more code, which the examiner can look at.

A simple rule of thumb is: provide snippets that show your work and your learning in the body of your report, and provide bigger sections of code as a section in an appendix.

Some projects might require the development of an algorithm, so showcasing its development will be a really important part of the technical story of your project. In this example, you might want to refer to M269 Algorithms, data structures and computability, or another module.

If your project has user interfaces that is coded up in a language, such as HTML, you might want to include fragments of these, and refer to modules such as TM352 Web, mobile and cloud technologies and TM356 Interaction design and the user experience.

You should also refer to texts, such as set texts, module materials, or any other resources that you have mentioned in your literature review section.

Presentation

In the body of your report, a practical approach is to share small sections of your code using tables. By using this approach, you can refer to your code using a table number, when you discuss how you created your software.

A suggestion is to present your code a font, such as Courier New, to clearly distinguish between what is code, and what is discussion. To make sure you don’t use too many pages in your project report, it is okay to make your code a bit smaller. From my tutor perspective, 8 point Courier New is a good choice. 

A fellow tutor shared a particular opinion about code presentation that has stuck with me, which was: try to avoid presenting code on a black background. The reason for this is pretty simple: if bits of your report are printed (which I don't think is likely to happen), it would use black ink or toner than is necessary. Another argument is that it might make the code harder to read on some devices.

For bigger chunks of code, you should use one or more appendices. A practical suggestion is to use one appendix for the code, dividing it up into subsections if you need to, since this way everything is in one place. You might want to use an appendix to share an entire file, or perhaps show how all your earlier code fragments look when they are combined together. You should use a font like Courier New to present your code, but you don’t need to present your code in a table, since you can refer to it with an appendix or a reference number.

Pro-tips: cross referencing and Word headings

The bigger a Word document becomes, the harder it becomes to maintain, especially if you’re starting to add in a lot of sections. To make things easier, I have the following recommendations:

• Make use of the Word in built headings; this enables you to easily create a table of contents using a feature of Word. Also, get Word to number each section for you, since this way you don’t have to renumber everything is you need to add a new section.
• Use the Word document navigator view to get an overview of your document.
• Have up to 3 levels of headings, i.e. 1.2.2; too many levels will make things confusing.
• If you add tables and figures, get Word to number them for you.
• If you refer to a table or a figure, do so using the Word cross reference feature, since that way if you add more tables, you won’t need to mess with editing table numbers.

The final point is: if all this is a bit much, do what you need to do to get your report written. Sometimes it is best to decide to get things done. TM470 is all about OU study and running a project, rather than making a perfect Word document.

Edited 15/7/23, adding a further bit guidance about the formatting of code.

I’m a tutor for the Open University's TM470 Computing and IT project module. TM470 is different from most other OU modules, since it is less about learning about Computing and IT concepts, and more about applying what has been learnt. 

When I was a computing undergraduate, I had to write a dissertation. I had to identify a problem, do some background reading, figure out what I needed to do, go ahead and do what I needed to do, and then write everything up. TM470 asks you to follow a similar process, whilst offering some helpful guidance.

One of the most important decisions that has to be made is choosing a project, or identifying a problem that you want to solve. 

This blog has been written for TM470 students, and aims to share some useful advice and pointers to help you with the process of choosing a project. This post accompanies earlier articles that I have written relate to TM470, which can be found by following my TM470 blog tag (OU blog). The articles about Understanding the literature review, Academic writing, and the TM470 Project report structure might be helpful.

In essence, the project is all about showing off: showing off how you can use the skills and knowledge you have acquired throughout your studies. It is also about showing off how you’re able to plan. Finally, it is an opportunity to show off what you have learnt from the process of completing a project.

Starting points

Within the resources section of the TM470 website, there is a section called Study Materials. 

At the start of TM470, it is recommended that you have a good look through four different resource sections:

• Study Guide
• Project Choice
• Sample Project Titles
• Choosing a Lifecycle Model

Defining a project

The module materials shares dictionary definition of a project: “a carefully planned piece of work to get information about something, to build something, to improve something, etcetera.” 

It goes onto mention some of the key characteristics of a project:

• They are unique – i.e. specific to a particular set of circumstances and not part of routine activity – and would not arise without deliberate intervention.
• They are planned around a collection of available resources, schedules, budgets, etcetera.
• They are self-contained around aims and objectives, and it is possible to decide when they are complete, and whether they have been completed successfully.

For TM470, the module team suggests that a project should:

• identify a problem,
• be practical or have a strong practical context,
• have a proposed solution using (or related to) computing and IT,
• include aspects of planning, evaluation and revision,
• be broadly based on one or more level 3 computing and IT modules
• will not be pure research but will extend and apply what has previously been learnt at level 3 to a practical problem.

Types of projects

There are, broadly speaking, three different types of TM470 project:

• Development projects: involve creating something: processes, algorithms, software, hardware, interface design, etc.
• Research projects: involve addressing a research question or analysing the possible solutions to a research problem, making detailed recommendations. This typically involves investigating the relevant academic area in depth.
• Evaluation projects: are sometimes named ‘compare and contrast’. You might compare processes, analyse an implementation, assess different user interactions, etc.

The most popular type of project is the development project. This is where you build something, and then write a report that describes what you have built, and how you have built it. You would, of course, start the building after you have done some detailed planning and shared a detailed summary of all the resources and skills you need to start the project.

Sometimes, projects will not have a clear boundary between each of these categories. A development (or implementation) project might contain bits of research, and also bits of evaluation too. A project that is based on the interaction design module is a good example of this, where you might ask the question “is my design any good?”

Project choice guidelines

Your project should address a non-trivial question. The question should not have an obvious answer, and this means that it should be “reasonably difficult” (but not too difficult). It should ideally occupy the time that you have available, the resources that you have access to, and draw on many of the skills that you already have. 

Here are a set of collated and edited tips from both myself and fellow tutors:

• Your project should ideally be based around a clear, concrete problem or scenario that needs a solution.
• Your project must have a clear focus and ideally focus on a specific level 3 modules that have been previously studied.
• Your project should be sufficiently detailed to allow you to achieve significant depth of analysis and reflection about what you have learnt and achieved during your project.
• You should not attempt to do too much.
• You should choose something that enables you to play on your existing strengths rather trying to learn an entirely new skill set.
• You should choose something that you are interested in; this will keep you motivated. Make sure that you have fun whilst working on your project.

Starting your project

The first TMA is all about setting the scene and sharing your project ideas with your tutor. It is also used to help you to plan what you are going to be doing:

• Choose (and justify) an appropriate lifecycle module; always ask why you have chosen the approach you have chosen.
• Create a project plan and include this in the TMA (and all subsequent TMAs); create a Gantt chart.
• In your plan, outline very concrete 'deliverables' (including your TMA submission dates), regardless of the type of project.
• Take time to identify risks: what are they? Write them down and submit them in your TMA.
• Make notes of what you have read; this can feed into your literature review, and have a look at the OU library to carry out some further research.
• Write about the resources that you need, the skills that you need, and the skills that you need to develop.
• Start to think about ethics.
• Take time to review all the marking grids that are provided with the TMAs: you can almost mark yourself!

Projects connected to your workplace

If you are thinking of basing your project on something that you do in your workplace, there are a number of things that you need to carefully think about:

• Timing: does the timing of a work-based project align with the timing of TM470? For TM470, you need to go through a complete project lifecycle, from beginning until end.
• Who is involved: sometimes work-based projects involve teamwork. If this is the case, whatever you do on a work-based project might not be suitable for TM470 for the simple reason that everything that you do, and you submit in your project report must be all your own work.
• Planning: are you able to do your own planning for the project? If someone else is doing the planning, or deciding on deadlines for your project work, your work-based project might not be suitable for TM470.
• Complexity: some work-based project address a very small part of a much bigger project. Are you able to choose something that enables you to demonstrate a breath of skills and abilities?

Essentially, TM470 is all about what you do, and what you learn through the process of completing a project. Another way to choose a project is to think about what skills you might like to develop. Only choose a work-based project if all the above criteria can be met.

The degree apprenticeship version: TMXY475

There are two versions of TM470; a degree apprenticeship version, which goes by the code TMXY475, and the non-degree apprenticeship version. Although the aim and structure is broadly similar, TMXY475 has a slightly different focus to TM470. 

Apprentices who are taking TMXY475 have the challenge of identifying a project that aligns in two different ways: it connects with the level 3 OU modules they have previously studied, and also relates to some task or activity which relates to their workplace. Working with their module tutor and line manager, apprentices must choose a project that aims to address a particular business need, or to provide a clear benefit. Their project must also fit within the module timescales.

An important difference is that apprentices will need to not only write a project report, but also to prepare and deliver a presentation about their project.

Reflections

Choosing the right project at the start of TM470 is really important. If it is too simple, there might not be enough to get your teeth into; you need something that really allows you to show off your skills and abilities.

A TM470 must always link back to Computing and IT, irrespective of how technical it is.

Whilst it is often great to see technical skills demonstrated through an implementation or development project, some of the best projects I have seen have been about design. Rather than developing lots of a code, a project might share a series of detailed designs, which are then thoroughly evaluated, by applying the concepts presented through the interaction design module.

TM470 is all about sharing a technical story about what you have done within your project. Within this wider story there will be other stories, such as a story about your reading and what you know (which is presented through the literature review section), and what you have learnt (through the reflection section). 

The key bits of advice I have are: play to your strengths, and try to have fun with it. If you’re having fun with your project, you’re likely to be motivated. Also, do some thorough planning, write down potential risks, and consider the resources and skills that you need to do what you need to do.

Acknowledgements

I would like to thank fellow tutors Chris Thomson and Eleanor Dare, who were kind enough to share some PowerPoint materials which offered useful advice and guidance about TM470 project choice. I would also like to acknowledge the TM470 module team, some of whose words I have creatively shared through this post. I would also like to acknowledge Alexis Lansbury, who is my TM470 line manager.