Personal Blogs

During the planning stages of your project, it is really important to consider resources. There is a link between the notion of resources and one of the module learning outcomes:

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

To satisfy the requirements for a distinction level project, you need to have:

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

Resources can be thought of in a couple of ways. Firstly, you should draw upon and use academic resources. Your choice of these resources will make up your literature review chapter. Secondly, there are the resources that you will need to use to get your project done. There is, of course, a link between both of these types of resources and the skills that you need to apply.

There is another link to bear in mind, which is a link to the risks that you have to take account of. Some risks that you identify might lead you choosing certain types of resources over another. Whatever you do, it is going to be important to justify your decisions about what you have done within your project report. Your considerations need to be convincing.

To read more about risk, and how it relates to TM470, it is worth reading an accompanying blog, Considering project risks. 

Academic resources

Your TM470 project is all about building on your earlier learning and studies. This means that you need to identify what academic resource might be useful when thinking about your project. The starting point is, of course, the previous modules you have studied. 

The TM470 module materials has a resource called Preparing a Literature Search, which you should read. To offer some complementary guidance, the following blog offers a bit of guidance: TM470 Understanding the Literature review.

The library also maintains a list of links to online databases that relate to ICT which might be useful. A really important point (which I share to students) is: the OU library is your friend. It is a huge resource. Do make sure you find the time to look at it.

When working on your project, it is worthwhile thinking about the following categories of academic resources:

• Module materials.
• Textbooks that accompany module materials.
• Academic articles (such as those found within academic journals).
• User guides or instruction manuals.
• Technical websites.

It is all very well knowing which modules, textbooks, articles and databases may help you with your project, but when it comes to your TM470 project you actually need to get on and do something. This takes us to the following section, which addresses the question: ‘what do I need to complete my project?’

Resources you need to complete your project

Your TM470 project will be typically based on a level 3 module. The TM470 module team have written a number of few short articles about what a project (which is based on an earlier level 3 module) might look like.

You might want to draw on TM356 Fundamentals of Interaction Design, for example. In doing so, you may wish to apply the interaction design life cycle. With ID projects, students should ideally carry out a number of design iterations, potentially leading to either a high fidelity prototype, or a design of a particularly implemented software tool or system.

There are many different approaches to prototyping. A prototype can, of course, being as a paper prototype, and then lead onto a series of higher fidelity prototypes. Some students have used PowerPoint, for example. There are other tools that could be used, such as Balsamiq, Adobe XD or Figma. When you have created a design, you will need to carry out an evaluation. This leads to the questions: ‘what do we do to carry out an evaluation?’ and ‘what do we need to carry out an evaluation?’.

Unpicking this further, we can identify different broad categories of resources that we might need.

Software: Software products, such as prototyping tools, software development environments, or products to help you manage information or aspects of your project.

People: Put more broadly, the people category includes stakeholders. Stakeholders can be defined as anyone influenced by or affected by a project. People might also be participants; people who might help you with the testing or evaluation of your product.

Tools: Broadly, tools are anything that helps you to do what you need to do. If you’re capturing requirements and interviewing stakeholders, you might want to use a data recorder. If you’re carrying out an evaluation, might choose to make notes about happens.

Facilities: by facilities you might think about rooms, spaces, or physical places where project related activities occur. If you’re gathering requirements and need to run a focus group, you’ll need to find a place where this takes place. If you will be creating software as a part of your project, you will need a computer and maybe some server space to get it working. If you are evaluating an interface, you’ll need to find somewhere to do that evaluation. 

Different projects will require, of course, different resources. Since your project is only small, you should only use what you have easy access to.

The link to skills

By identifying the resources you need for your project, you will begin to think about the skills you have, the skills that you need to apply, and the skills you need to develop.

As mentioned earlier, resources can be thought being in two broad types: academic resources, and resources you need to complete your project. When writing and preparing your literature review, you may well develop your academic reading and critical thinking skills. When it comes to project resources and project management, you may well need specific skills to make progress on your project.

Practical advice

The different two types of resources needed to be treated differently. Think of your literature review as a narrative (or story) of what you have read. Don’t present a summary of papers, or articles that are relevant to your project. Instead, show the examiner what you have read, what readings are going to be useful within your project, and explain why they are important. There are different ways to structure a literature review, but a practical recommendation is to adopt a thematic approach.

Let’s turn to the other type of resources: project resource. In the planning section of your report, create a table that summarises the resources you need. Give each resource a name, and then offer a brief summary of that it is and why it is important to your project. If appropriate, you might even want to provide a reference.

When you have prepared table of resources (which could include different types of software, people, tools, and facilities), it is time to write about skills. Just as you did with your list of resources, create a table that summarises the skills that you will either need to have, or need to master in order to use these resources.

Considering reflection

Identifying the resources and skills that you need is both important and helpful.

When you get to the end of your project, you will need to complete the reflection section. When you get to this bit of your project ask yourself:

• Did you choose the right set of resources?
• Have you developed the skills that you expected to develop?

There is always a further question to ask, which is:

• Have there been any surprises?

There is (or will be) a whole other blog that relates to reflection, and the importance it plays in TM470.

Acknowledgements

Many thanks to the TM470 project team and fellow TM470 tutors. Although this blog (and other TM470 blogs) are intended to provide useful additional guidance, always refer to the module materials. If you have any questions, please do contact your tutor.

If your TM470 project is all about the developing software to solve a problem, requirements are really important. Requirements are all about specifying what needs to be built and what software needs to do. A good set of requirements will also enable you to decide whether or not your software development has been successful. They can help you to answer the question: “does it do what we expect it to do?” There is a direct link between requirements and testing.

The exact nature of your requirements will depend on the nature of your project. There are different types of requirements. Two high level types of requirements are: functional requirements and non-functional requirements. Modules such as TM354 Software Engineering provide some further information about the different types and categories, and different aspects you might want to consider. 

One thing that you need to decide on is: how to you write down your requirements? The decisions that you take will, of course, relate to what your project is all about. Some projects will need formal approaches, perhaps using Volere shells, whereas other projects may use something like use case diagrams. If your project is interaction design heavy, your requirements may be embodied with artefacts such as sketches, prototypes, scenarios and personas. To learn more about these different approaches, you need to refer back to the module materials for some of the modules you have studied. You should also consider having a look in the OU library to see what you can find.

There is also, of course, also a link between your chosen project model, and your choice of requirements. Stakeholders are also of fundamental importance: you need to know who to speak with to uncover what your requirements are. You need to make a decision about how to record your requirements, and justify why you have adopted a particular approach. Different people will, of course, understand requirements in different ways. How you speak to fellow software engineers will be different to how you speak to end users.

I recently listened to a really interesting podcast about requirements engineering from something called Software Engineering Radio, which is associated with the IEEE Software magazine. Here's a link to the podcast: Software Requirements Essentials: SE Radio 604 Karl Wiegers and Candase Hokanson.

Although this is just over an hour (and I know everyone is busy), it is worth a listen.

Some key themes and topics addressed in this podcast includes:

• What do requirements mean?
• What is requirements elicitation?
• How can requirements be presented? Or, what is does a requirement specification look like?
• Do users know what they need?
• How much requirements analysis is needed?

The podcast concludes with a question which begins: what tips would you share for someone who is involved with an ongoing project? (The answer to this question is very pragmatic)

Reflections

An interesting reflection (and comment that emerged from this podcast) is that the requirements approach that you adopt relates to the risks that are inherent within your project, and the implications of any potential software failures. This, in turn, is linked to the LSEP issues which are starting to be explored within your TM470 TMA 2.

When you are addressing requirements, you can highlight different requirement gathering approaches in your literature review. Do use module materials that you have previously studied as a jumping off point to do some further reading about the subject by looking at resources you can find in the OU library, but do be mindful about getting sucked into various ‘rabbit holes’; requirements engineering is a subject all of its own. When it comes to your TM470 project, you need to make practical decisions, and justify your decisions.

When considering planning, I’m minded of a familiar glib phrase: “if you fail to plan, you plan to fail”. When it comes to TM470, planning is really important. Effective project planning is the backbone which holds up your project. Also, a big bit of learning that can come from TM470 is learning about planning, and how to maintain a project plan during the course of a project.

Importantly, planning is mentioned very clearly within the EMA learning outcomes, for example:

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

To get a distinction for this criterion, you must provide evidence that you have: “clearly planned and accurately managed progress in relation to the original plan” and that you understand “what has gone well and what has not gone to plan.”

In the EMA summary, it is suggested that you should provide evidence of your ability to: “plan and organise your project work appropriately, and keep systematic records of plans, progress and outcomes”.

This leads us to some questions: what kind of records do we need to provide, and how do we go about creating a plan?

To begin with, there’s a lot of practical advice within the ‘planning and organising a project’ module resource, which offers a lot of helpful advice and some helpful background information. A recommendation is to get a printout of this.

Your first TMA emphasises planning. This TMA assessment guide suggests that your first assessment should have three main sections: “preparing for and planning your project; the project work; reviewing and reflecting upon your planning and preparation, and project work”. In other words: what you are doing to do, what you have done, and what points you have to share about what you have done.

This is expanded in one of the tables that can be found within the TMA 1 guidance, which offers the following points which relate to planning: 

• Outline of the major tasks and subtasks within the project at an appropriate level of detail to enable your tutor to assess the viability of your project.
• Choice and justification of a lifecycle model for its management. Within the context of the chosen lifecycle model, a schedule for completing the tasks and subtasks.
• An outline of the resources and skills needed and the methods you are considering using, taking into account the risks and how these will be minimised.

What to provide

Your first TMA (as well as your EMA), you need to provide the following:

Choice of lifecycle model: you need to justify what overall project management approach you have chosen. There is a useful resource about this in the module materials. Different projects will necessitate the choice of different models. Choose a model that works for you and your project, and justify your choice. A practical suggestion is to provide a table. Say something about each of the different modules, saying why a particular approach either is or isn’t appropriate for your project.

Table of tasks: Give your tutor a very high level of the things you’re going to do as a part of your project. You could think of these in terms of project phases. Keep it high level. Again, use a table. Give each task a name, a potential start date and end date, and a brief description, providing no more than a sentence. Your choice of project model will help you to form your task table. Your table s will help your tutor (and your examiner) to get a good idea about what you’re going to do to solve your problem. 

Table of resources: The resources you use within your project are important. Although the primary resource is yourself, you may need to get other people involved in your project. If you’re doing an interaction design project, you might need some help with the evaluation of your designs. If you can’t get hold of ‘ideal’ users, you can also use proxy users (such as friends or family members); users who are pretending to be your target users. You also might need to use software tools, or maybe even some cloud computing resources. Like with the tasks, do share everything in a table. Try to describe everything as succinctly as possible.

Gantt chart: Gantt charts are really useful tools. When you have created your task table, have a go to great a Gantt chart for your project. Aim to have two Gantt charts. Create one at the very start of your project, make a copy of it and save it somewhere. When you start work on your project, maintain a Gantt chart to reflect progress on your project. Submit a copy of your chart for your first TMA. When you get to your EMA, submit both your first Gantt, and the one that you have maintained throughout your project. By looking at the one that you had at the start, and one that you had at the end, you will be able to see the difference between what you thought would happen, and what actually happened.

On the subject of Gantt charts, you can create them in different ways. If you are working on a company, you might be able to use of products such as Microsoft Project to help you to plan your project and to create a Gantt chart. Another approach is to make use of an number of Gantt chart templates for Microsoft Excel.

What to do

There is some good guidance about planning within the module materials. In terms of creating a Gantt chart, I recommend that you do, and take account of the following:

• Record all your TMA cut off dates as milestones. If you’re studying multiple modules at the same time, do put these in too.
• Do make a note of time that you need to allocate to writing and submitting both your TMAs and your project report (your EMA).
• Make a note of when you’re going to be on holiday and put these dates on your chart.
• Make a note of any other non-working time. For example, if there are any family or work responsibilities that need to be attended to, make sure you make a note of them.
• Begin to record high level tasks, or project phases that match your choice of project model.
• Within those phases, attempt to break them down to one or more subtasks.
• Consider the risks that might apply to your project. (There will a blog post about TM470 and project risks. When you get to your EMA, project planning and project risks should go into the same section).

Some accompanying thoughts are: 

• Do expect to change your plan during the course of your project.
• Don’t prioritise your plan over your project. If you find yourself spending loads of time on the plan, you might need a simpler plan, or find another way to plan, or choose a different tool.

Some important tip that I share with all project students are:

• Create a project log. This could be something as simple as a Word document, which has dates for headings. Use this to make notes of what you’ve done. This could only be a few sentences; it doesn’t have to be anything very detailed. You can also use your log to make a note of what you have learnt.
• Email your tutor regularly, ideally every two weeks, just to keep them informed of what you’re doing. You might think about emailing your tutor sections of your log.
• When you compile your EMA, you can put a copy of your project log, or emails, or both into an appendix. Doing so relates to learning outcomes LO5 and LO6, where to get a distinction, you need to provide evidence of having “worked under own supervision, communicating regularly and accurately in respect of progress” and “sought guidance when needed, but offered own ideas when doing so”, and “has clearly recognised new skills and knowledge”.

Reflections

When you get to the end of your project and you have to write the reflection section (which accounts for 20% of the overall mark) if you have made a good plan, and have your original plan, you will be able to say something about what went well, what didn’t go well, and what you have learnt about running a project. Of course, you should also be saying something about what technical skills you have further developed too. Although project planning isn’t very exciting, it is pretty important, and it is also important to get on top of it early. One of the jobs of your tutor is to offer you some practical advice about how your plan might be further developed or improved.

Acknowledgements

Many thanks to the TM470 project team who have prepared some very helpful materials on choosing a project model and carrying out a project planning.

During a group tutorial I asked students how they kept motivated. With their permission, what follows is a summary of the hints and tips they shared with each other. Their points are accompanied by some of my own thoughts:

Have a chat with your tutor: your project tutor is there to help. Do find the time to speak with them. It is important they learn more about your project idea, since then they can help and offer advice.

Speak to people: if one exists for your module, consider joining a WhatsApp group, or other online groups, since speaking to other students can be really useful. One thing to bear in mind is that these informal spaces are, of course, not monitored or regulated by the university, which means that students need to take care when participating in these spaces. Students do, however, still have to abide by student conduct policies.

Tell your managers: if you are completing your project module as a part of an apprenticeship, or there is a connection between your project and your workplace, make sure you tell your managers all about it. Get them involved, and consider how best to keep the informed about your progress, and consider what kind of help they might be able to offer.

Remember where you are in your studies: when you’re doing a project module, you’re nearly at the end of everything, and it’s important to remember this. Your project module is the pinnacle of your studies. Look back at how far you’re come, and look forward to see how far you have to go. This helps to put things into perspective.

Remember why you’re doing this: remind yourself of what you want to achieve by carrying out all your studies. It might be a better job, a change of career, or maybe a route into postgraduate studies. Reminding yourself on the big picture, and what you want to achieve, can help you to regain your motivation.

Little rewards: make sure you make time to celebrate your achievements, whatever these might be. They might be completing a plan, finding something out about an aspect of your project, revising bits of module materials, or submitting a TMA. Make sure you build in time to enjoy life.

Manage your time: although this isn’t necessarily directly about motivation, it is important to make sure you find a way to manage your time. When you have a plan, or a study habit, this will help you to internalise that you’re able to complete your project.

Break things down: there’s this expression that goes ‘how do you eat an elephant?’ The answer is: in little pieces. The same applies to your project. You should always aim to break your project into smaller chucks to make sure you can achieve the bigger goal.

Take regular breaks: stepping away from your project work can be really helpful. If you spend a lot of time working on a problem or a task, you might begin to make mistakes, and the quality of your work might go down. Consider going for a walk, completing a mindless chore that needs to be done, or watch some nonsense on television: whatever works best for you.

Understand what study or work habits work best: some of us are morning people, whereas others work best late at night. Understand what works for you, and apply this to your project work. This will make things easier.

Acknowledgements

Many thanks to the TM(XY)470 students who attended our introductory tutorials. Good luck with your projects!

TM470 is the Open University’s Computing and IT project module. It is what is called a capstone module, which is studied towards the end of the Q62 Computing and IT BSc qualification. It is an important element, since it is linked to the degree being recognised by the British Computer Society (BCS)

If you study this this module, you are required to carry out a substantial project which demonstrates your learning that has taken place on earlier modules. It is also used to develop your project management skills. Given the final output from the module is a project report TM470 also helps to develop your writing skills.

Like many other modules, TM470 is assessed through a series of learning outcomes. To pass the module, you must demonstrate that you have met these outcomes. This means that you need to provide sufficient evidence in your project report to ensure that the examiner can see that you meet all the criteria that are embodied within those outcomes.

A fellow tutor has described TM470 as a bit like a very long assignment (or end of module assessment). Every tutor marked assessment (TMA) is designed to help you to move towards the writing of your end of module assessment. As you study the module, it is recommended that you review the learning outcomes of each TMAs. Different TMAs will be assessing different learning outcomes. In turn, this will take you to the EMA, and its learning outcomes.

What follows is a brief summary (and my own interpretation) of the learning outcomes that relate to the module EMA, which is the same thing as the project report. A full summary of the learning outcomes and the accompanying assessment criteria is, of course, available through the module website.

Before looking at all the outcomes, I should note that these are my own notes, and my own opinions, rather than that of the module team. Always refer to the module team materials for official guidance.

Interpreting the TM470 Learning outcomes

LO1: Demonstrate your understanding of technical concepts relevant to your project

I have paraphrased this learning outcome from the original version: demonstrate and apply a systematic understanding of the fundamental technical concepts and principles relevant to your project. In other words: you need to do stuff to show what you have learnt from your earlier studies. There is an implicit link between this learning outcome, and learning outcome 11.

LO2: Identify and refine the goals and content of your project

This is all about the aims of your project. Does it solve a specific and easily defined problem that can be described in a few concise sentences? A quick check is: does it make sense if you explain your project idea to someone who doesn’t know what you have been studying? Does it solve a real need? Do refer to the module guidance about what constitutes a good project aim and idea.

LO3: Skills, resources and activities

The full outcome is: identify, list and justify the resources, skills and activities needed to carry out the project successfully. Another part of this outcome is: identify and address any associated risks. If there evidence of each of these elements? Do you consider what resources you need, such as software, or people? Also, how about risks? Is there evidence of how you have considered risks? Are these risks sensible?

LO4: Gather, analyse and evaluate relevant information

In my eyes, this theme cross cuts a couple of sections. Is there evidence of your reading in your report, by way of a literature review section? Also, when it comes to make decisions about what to do with a potential design, have you documented what you think is important. In other words, is there enough information that enables the reader of your project report to understand the story of what was done within your project?

LO5: Critically review how you have tackled the project

This outcome is one of the two outcomes that is all about reflection. If you don’t get everything working as you had hoped, or things didn’t go to plan, don’t worry. Instead, do tell the examiner about it. Importantly, tell them why you thought it didn’t go well, and what you have learnt from it. Also, do assess whether you felt your original plans were appropriate. During the planning of your project, thinking about risks is important. Did you go overboard on your risk planning?

LO6: Make effective use of a variety of information sources

This outcome is linked to LO4, but it is more about your reading, and how what you have read has informed what you have done. You also need to demonstrate that you have drawn on sources that have academic credibility. Whilst blog posts (such as this one) can be useful, they don’t hold as much weight as books or formal articles. An element of the project report is to demonstrate not only your practical skills, but also your academic skills. In turn, you need to make sure you reference everything clearly. 

LO7: Communicate clearly

The full title of this outcome is: communicate information, ideas, problems and solutions clearly. In other words, you must demonstrate that you’re able to write a well written report that describes what you’ve done. A really useful bit of advice I was once offered was: “make sure what you write is as interesting as it can be”. Academic writing, whilst formal, doesn’t have to be boring. Put a bit of yourself into your writing, especially when it comes to the reflection section.

LO8: Learn independently and reflect on what has been done

This outcome is all about reflection. When looking back across your project, it is okay to get a bit more personal. This outcome is all about saying what you felt went well and what went badly, what you have learnt, and whether there were any surprises. Also, do you now know something new about yourself and how you work, than you did before?

LO9: Plan and organise your project work

The full outcome is: plan and organise your project work appropriately, and keep systematic records of plans, progress and outcomes. This outcome is linked to learning outcome 3, which is about resources, activities and risks. In your report, is there evidence of creating a plan? A practical tip is to great a Gantt chart, but break it down into a fair amount of detail. This said, don’t make it too detailed, as otherwise you’ll spend too much time updating your plan and not doing any project work! A further practical tip is: do begin a project log, and put this as an appendix. This will help you when it comes to the learning outcomes that are all about reflection.

LO10: Ethics, equality and diversity

A more detailed heading for this outcome is: identify and address the legal, social, ethical and professional issues (LSEPIs) and the equality, diversity and inclusion (EDI) concerns. Since computing systems can have real impact within society, and to individuals, it is important to consider what these are. There should be a section within your report that addresses this, and concerns about ethics should inform what you do, and how you approach the different stakeholders.

LO11: Analyse a practical problem and devise and implement a solution

The full learning outcome is: 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. Put another way, you should demonstrate what you already know, what you have learnt, along with what skills you have gained from earlier study, and what skills you have developed during the period of the project. You should do all this through your project report. 

Summary

TM470 is very different to OU modules that teach a particular topic, since so much of the decision making about what you do, and what you write about is up to you. The module begins to make sense if you think in terms of producing ‘something’ (a project report) that demonstrates your skills and abilities. I often tell students that TM470 is all about showing off your skills and abilities, i.e. showing off to the examiners what you have learnt, and what you can do. The module learning outcomes help you to understand what you need to focus on to show off in the best possible way.

Acknowledgements

Many thanks to the TM470 module team, and the follow tutors that I work with.

The main output from the TM470 project module is a project report. 

The report shares what has been done and what has been learnt. The ‘things done’ bit relates to the planning, the reading (and any research that has been done), and the actual work that has been carried out. The ‘things learnt’ bit is shared in a section which is used to share reflections, or thoughts about all the work that has been carried out.

One of the bits of advice I offer students is: think of the TM470 project report as a “technical story”. When sharing this view with fellow tutors, another tutor, Kawal Banga, shared another metaphor: the TM470 project as a journey. 

Kawal shared a list of 13 really useful points which relate to actions that take place on the journey of completing TM470. The links to the module learning outcomes are, of course, associated with each of these points:

1. You identified a real business/social problem that could be solved through an ICT solution (LO2), engaging with sponsors/users who needed a solution to the problem. 
2. You project managed (keeping evidence of records, plans, outcomes) the delivery using a suitable project/process lifecycle (LO9). 
3. You identified and managed risks (LO3) on the way and identified and utilised skills, resources and people you needed (LO3). 
4. You made use of technical concepts and principles (LO1) from your Level 3 modules. 
5. You analysed, designed and developed an ICT solution building on and extending skills from your Level 3 and other modules (or equivalent professional skills), and using any additional skills you needed (LO11). 
6. You took into consideration any LSEPIs (Legal, Social, Ethical, Professional issues) and EDI (Equality, Diversity and Inclusion) issues and modified your project and your behaviour to deal with such issues (LO10).  
7. You carried out a literature review using quality, credible and relevant sources in which to ground your work, and supporting your decisions (LO4, LO6). 
8. You worked independently as much as possible and learned new skills and knowledge that you applied to your project (LO8). 
9. You reflected on things (processes, tools, resources, studying, etc) that worked or things that didn’t work (LO5), and lessons and skills (technical, professional, academic, organisational, project management) that you learned through the project.  
10. You replanned and rescheduled your work when things went wrong (LO9, LO3, LO5, LO8). 
11. You communicated effectively through TMAs/EMA, reports, emails etc with your tutor and other project stakeholders (LO7).  
12. You engaged the sponsors and/or users throughout the project journey, where appropriate, seeking feedback on interim deliverables and they evaluated your final artefact. 
13. You can prove all of the above with solid evidence that you collected over the project journey, and can communicate this effectively to your tutor and other stakeholders.

It's really helpful to reflect on his list. 

Another thought is that the notion of stories and journeys are compatible with each other. In some respects, my advice for the TM470 Project Report Structure reflect both perspectives. This structure intends to take the EMA examiner on a journey from the start of the project to the final summary, which should clearly highlight the learning that has taken place.

Acknowledgements

Many thanks to Kawal for giving permission to share his list. Thanks also to fellow tutors who responded to my post about the notion of the project report being a story.

In TM470 LSEPI is an abbreviation for Legal Social Ethical and Professional Issues. A good TM470 project report should clearly address these issues to show the examiner that you have thought about how these issues have impacted on your project, and what you have done to take these into account.

LSEP issues are increasingly important in computing due to the increasing impact that computing and IT has within society. When speaking with students I often a recent example: the Volkswagen emissions scandal. In this case, there are clear environmental impacts and legal implications. It is also clear that both the engineers and leaders have to make ethical decisions.

In TM470, LSEP issues are assessed through the following learning outcome: “LO10. 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.” In the marking of the EMA, this learning outcome is assessed with LO2, which is all about the aims and goals of your project.  When just looking at the number of learning outcomes, and the marks available, the LSEPI section could account for 10 marks.

To gain a top score for this learning outcome a student: “has comprehensively identified the relevant LSEPIs and EDI concerns arising during development and use and modified their project work to take these into account and behaved professionally in all aspects of their project work”. EDI being an abbreviation for equality, diversity and inclusion.

Given the importance of both LSEP and EDI, a suggestion is to include it as a top level section in your report, just before the literature review section. The justification for this is that if you identify some issues that need to be explored in greater depth, you can then go onto provide evidence of your reading.

Module materials

At the time of writing, it takes a bit of digging to find two documents that relate to both LSEP and EDI issues. From the module website, click on the Resources heading, and then click on the Study materials section.

The LSEP document contains the following key headings: working with stakeholders, working with human participants, and asking the right questions. Do review the materials that are presented under these headings and review Appendix A Guidelines for conducting research with human participants. Related to these are two template documents: a sample consent form, and a participant information sheet.

Informed consent is the process through which researchers share the aims and purpose of their research with participants, and gain their approval that they are happy to participate in a study. The accompanying information sheet is designed to offer further information under a set of familiar headings.

When working with participants, I always remember two points. The first is that participants are at liberty to leave a study at any point. The second point is related: the participants are always more important than the research that is being carried out.

The equality, diversity and inclusion section addresses “why equality, diversity and inclusion are relevant to computing and IT professionals”, introduces the concept of protected characteristics, and “unconscious bias is and how it might affect your practice as a computing and IT professional” and what mitigations might be adopted (TM470 module materials).

EDI relates to people, and differences between people, irrespective of whether they are perceived or due to physical, cognitive or sensory impairments. Since Computing and IT products are, ultimately, used by people, it is necessary to consider EDI issues. If you design an app or a website, your product should be accessible to the widest possible group of users. The motivations for doing this are twofold: firstly, there is a legal obligation to ensure that products and systems are accessible under the Equality Act, and secondly, all users are potential customers. If a product isn’t accessible or perceived negatively, a consumer might choose another service that has a more accessible, usable, or appealing interface.

Looking at this issue from a slightly different perspective, if your project uses artificial intelligence or machine learning, it is necessary to question the extent to which biases might exist within either data that informs your project, and the extent to which bias might be potentially reinforced, or even magnified.

Questions to ask

As highlighted earlier, the LSEP materials contains a section that has the title: asking the right questions. 

Go through each of these questions in turn. 

When working through these questions, do think about the stakeholders who are involved with your project. A stakeholder can be thought of anyone who is affected by your project, either directly or indirectly. Ask yourself questions about what data might need to be held and collected, and what bits of legislation might play and impact if you were ever to deploy your project. The Equality Act was mentioned above. You might want to also consider data protection and computer misuse legislation.

If your project is a research report it is important to ask: what might be the impact of my report? If something is discovered by the report, what might be the impact of disclosing the results, or not disclosing the results? The point here is that it is important to go further than just the immediate project, but also to consider wider and broader impacts.

Differences between student projects and university projects

Before university staff can carry out research that involved human participants, they must submit project proposals through a formal ethics panel. The aim of this panel is to make sure that researchers have carefully considered everything, and any potential risks to all participants (and to the university) have been mitigated.

Unlike official university projects, undergraduate and postgraduate projects are not required to go through such a rigorous process. Rather than having an ethics panel and a lot of electronic paperwork to complete, students should think of their tutor or project supervisor as a mini ethics panel.

Interacting with your tutor whilst considering your LSEP and EDI issues should be thought of as a useful and necessary part of your project. Your tutor will be able to offer some thoughts about what needs to be considered. Plus, interactions with your tutor or supervisor can be documented in an appendix of your final reports.

Further resources

A lot of good resources about ethics are available, and some of these resources are mentioned in the module materials. Here are a collection of links that might be useful:

• Association of Computing Machinery (ACM) Code of Ethics
• British Computer Society (BCS) Code of Conduct

For those that find this subject really interesting, there is a whole suggested curriculum about Society, Ethics and Professionalism on the ACM website.

Going through the ethics bit of TM470 gives you a taste of what university researchers have to go through when they plan and design studies that involve human participants. More information about what goes on behind the scenes at the OU is presented through Ethics support for projects: Which studies need review, by whom and why? (OU blog)

Reflections

I find ethics a fascinating subject. In computing it comes into play more than you might initially expect since computing touches on so many different areas of human activity. Rather than being a subject that was once on the periphery of the discipline, I now see it as a topic that has moved to the centre. It is an important and necessary part of becoming a computing professional.

It is also interesting to reflect on how ethics has developed since I was a graduate student. There is now a lot more that has to be done, but this isn’t a bad thing. Additional scrutiny along the way helps researchers to carry out better research. For TM470 students, my key bit of advice is: speak with your tutor; they are your own personal ethics panel.

One of the important components of the TM470 EMA is your literature review.

The literature review component serves a number of purposes:

• It tells your examiner what you have read, and enables them to understand where you are coming from. In other words, what you present in a literature review enables the examiner to understand, broadly, what your project is all about. 
• It enables you to demonstrate to your EMA examiner your research and critical thinking skills. 
• It allows you to demonstrate your writing and communication skills. Just as your TM470 EMA is a narrative of your entire project, the literature review within that broader narrative (or story) presents a narrative  (or story) about your reading and your research.

The literature review can be primarily linked to the following TM470 learning outcome:

LO4: Gather, analyse and evaluate relevant information to complete the project successfully.

It can also be linked to the following learning outcomes:

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

LO7: Communicate information, ideas, problems and solutions clearly

A really important rule of thumb is: if you use a resource in the body of your report, that resource should be introduced within the literature review section. A resource might be any number of different things, depending on what your project is all about: it might be some module materials, a textbook, an academic paper, or even some software. Also, if you have something in the references section, it should have been ideally in the literature review section (although it is okay to occasionally break that rule, if it helps with the writing and presentation of your project report).

What follows are a set of what I hope to be useful ideas about how best to complete a TM470 project literature review.

Starting the literature review

An important question to ask is: how do I start my literature search? The biggest tip I can offer is: begin with what you know. This might be the specifics about a project, or maybe beginning with some of the level 3 module materials that you have previously studied. If you have studied TM356 Interaction Design and the User Experience, for example, a really good place to start is the module materials, and the accompanying set text. The textbook contains a lot of references which you can look to, and you can find many of these resources in the university library.

The OU library is also a great place to start too. It contains a whole host of useful resources, such as eBooks, and hundreds of thousands of academic articles that have been published in academic journals. When starting out to look at a subject they have not looked at before, some researchers carry out searches of library databases using a systematic approach, making notes of what keywords they have used, and what they have found.

Another tip is: if you find an interesting paper in the OU library it is sometimes possible to find out how many times a paper or article has been referenced, and what papers have referenced the paper that you have found. Looking at the popularity of papers, and chains of referencing can enable you to find out what papers or bits of research have been influential in a subject area. Sometimes, it is also useful to look to see what other papers a particular author has written about.

A final tip in carrying out a literature search: ask your tutor! The TM470 module team try to match students and student projects with tutors who have a particular specialism. After having an initial discussion with your tutor about your project, it is completely okay to ask the question: do you have any suggestions?

Criticality

During the course of your TM470 project, you might look at a lot of resources. Whilst it might be tempting to show everything that you’re read or looked at whilst working on your literature review, please don’t. You need to be selective, and you need to do this to demonstrate your critical thinking skills. 

More information about what this means is available in the OU booklet about Thinking Critically.

In terms of TM470, it is important to ask: how does this resource influence, affect, or relate to my project? A good literature review will introduce some concepts or ideas, which are referenced. These concepts or ideas are then used or applied within the body of a report to solve a particular problem.

Resources

In TM470, there are a number of useful resources that you may have seen, that you should be aiming to revisit whilst you work on your project.

The two key bits of module materials that you must review have the title: Preparing a Literature Search, and Reviewing Literature. A recommendation is to get a printout of these resources (by using the “view as single page” option), and work through each of the activities. You should also have a listen to the Finding and using research podcast. 

From the Preparing a Literature Search resource, do pay particular attention to the four stages of a literature search. The Reviewing Literature resource offers a set of useful pointers in the introduction which helps you to look at resources. 

Regarding this second resource, the following bit of advice is important: “This template isn’t always applicable, not least because it can become monotonous to read. You will need to make your own decisions about which elements should be included and which omitted.” These two sentences relate to the point about criticality, and the need to write a literature review that is appropriate for your own project.

On the subject of writing, a good resource to look to is the OU’s pages about Developing academic English. I also recommend The Good Study Guide, which is available to download as a PDF. Chapters that may be particularly useful when writing the literature review (and your EMA report) are Chapter 9, Researching online, Chapter 10, Writing the way ‘they’ want, and Chapter 11, Managing the writing process.

Referencing

If you use, or write about a resource in your project report, you need to make sure that you reference it correctly. In your TMAs and EMAs, there are two key bits to think about: the first is how to reference something within the body of your report (when you’re referring to something), and the second is how to provide a reference to a resource within the references section towards the end of your EMA. Another rule of thumb is: if you are writing about a resource, you need to reference it. Similarly, if you quote from a resource, you definitely need to reference it. 

The OU makes use of the Harvard referencing system, which is both comprehensive and flexible. Using this system, you can reference just about anything. Not only can you reference books and journal articles, you can also reference art works, web pages, and software. The OU has a subscription to a web resource called CiteThemRight. If you’re unsure how to reference something, do have a look at this website. 

When referencing papers or textbooks, a firm recommendation is to make sure that you also include page numbers. The reason for this is simple. Including page numbers clearly demonstrates attention to detail, and gives your EMA examiner further evidence of your depth of reading and understanding.

Finally, do make sure that you reference (and demonstrate an understanding of) earlier OU modules you have studied. This is a really efficient way to demonstrate to your examiner what topics or subjects your project relates to. You can reference any OU module material, whether it is a module website, a PDF, or printed module block. If you’re unsure about how to reference materials from any of your earlier studies, do ask your tutor.

Common Questions

Do ask your tutor any questions that you might have whilst carrying out a literature review. Here are some answers to some common questions, which might be useful.

Q: How many references should I provide?

A: There is no hard and fast rule for this, since every TM470 is different. You should choose enough resources to demonstrate the reading that you have needed to do, to complete a project that shows technical skills and knowledge you have gained during your degree studies. If pushed, I would say that a distinction quality EMA report might reference as many as 20 resources, but these resources must be important, relevant, and applied within the body of your project. In other words, your chosen resources should have influenced the work that you have done.

Q: How much time should I spend on the literature review?

A: Again, there is no hard and fast answer to this one. Some EMA reports are all about carrying out research. In a research focussed EMA, you might spend more time doing a literature review than you would for a very practical EMA. Overall, the literature review section contributes towards 20% of the overall EMA mark, but this doesn’t mean that you should only spend 20% of the time. A suggestion is to approach the literature review iteratively. For example, whilst trying to solve a technical problem, you might have to do more reading, which means that you might have to go back and to edit your literature review section.

Q: How long should the literature review be?

I’m afraid I’m going to give you a similar answer to all the others: it depends on your project! The TM470 module guidance suggests that you should be able to write everything you need to write within the 10k word limit. Given the importance of the literature review to a number of learning outcomes, I would say that the literature review is quite a substantial section within your EMA: it sets the scene, and goes a long way to demonstrating your critical thinking and problem solving skills (through the resources that you choose). Some project will have longer literature review sections than others. It should be as long as it needs to be, given the aims and objectives of your project.

Summary

This blog has shared bits of advice (and some links) that might be useful when it comes to writing your TM470 literature review.

One of the most useful bits of advice about report writing that someone gave me was: make sure it is interesting. 

Although this bit of advice related to EU project deliverables, it is just as applicable to your TM470 EMA. 

Your TM470 EMA is a technical narrative (a story) about your project. The literature review section within your report is a narrative within a bigger narrative; it is the story of your reading. It is a story which introduces resources which you will then go onto apply later on within your report. It is an important section which demonstrates the depth of your reading, and shares what you know about with the examiner.

Other blog posts that relate to the study of TM470 can be found through the TM470 blog tag.

Good luck with your literature review, and remember to make good use of your tutor, by asking them lots of questions.

When studying TM470, students are required to design, plan and carry out a short project that will enable them to show off the skills and knowledge that they have gained from their earlier level 3 students. To pass this module, students have to submit a detailed project report, which can also be thought of as a dissertation.

Since student projects can take many different forms, the TM470 module materials offer general guidance that need to be interpreted by students. A suggested report structure might work well for one type of project, but not for another. Students might decide on a research project (looking into a very specific problem in a lot of detail), an evaluation project (comparing one product, tool, system or approach to another), or an implementation project (choosing to design and implement code that solves a well-defined problem).

In absence of some very specific guidance about how to structure of project report, this blog post offers a summary of some of the guidance that I have offered (and continue to offer) during some of my TM470 EMA preparation tutorials. After my tutorials, I also share a link to this blog post to the TM470 students that I am supporting.

I must offer a disclaimer: this guidance will not fit all projects. Students must decide about whether the below suggested structure it is appropriate for their own project. Also, they must also decide on whether their report demonstrates that the TM470 learning outcomes have been met.

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.

1. Introduction

In this section, present a really short introduction to the whole 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.

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.

3. Preparation and planning

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, and why it is appropriate. 

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.

4. Legal, social, ethical and professional issues

Legal social ethical and professional issues (LSEPI) are important, especially 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).

5. 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. I’ve suggested it comes at this point, after the LSEPI section, since the identification of some legal, social, ethical or professional issues might raise questions that can only be answered by further reading.

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 text books 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”.

6. Project work

This is one of the most important sections of the report. It shows the examiner what you have done. 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.

7. Review and reflection

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.

8. Summary

To wrap everything up neatly, I tell students to write a short summary. A suggestion is: to 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. In some senses, this final summary should mirror the introduction section.

9. References

Clear referencing is really important. The aim 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. It also offers a neat summary of all the reading that you’ve done.

For TM470, you only need a references section, not a bibliography and a references section. If you use a resource in the body of your text, make sure that you refer to it in this section. 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.

Appendices

A project report can have any number of appendices. 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).

Acknowledgements

You can include an acknowledgement section in your project report, along with a glossary if you feel it is appropriate to include one. 

This acknowledgement section is for this blog post, rather than for a project report. I would like to acknowledge Chris Thompson and Karl Wilcox, who have been very generous in sharing their tutorial resources with me. I would also like to acknowledge Alexis Lansbury, who is my TM470 line manager.