OU blog

Personal Blogs

Christopher Douce

TM470 module briefing: 2025B&D presentations

Visible to anyone in the world
Edited by Christopher Douce, Friday, 22 Nov 2024, 16:05

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.

Permalink
Share post
Christopher Douce

TM470 Considering LSEPI (again)

Visible to anyone in the world
Edited by Christopher Douce, Friday, 4 Oct 2024, 16:03

This post follows on from an earlier post: TM470 Considering LSEPI. The difference between this blog and the earlier one is that this article places more emphasis on the ethics bit, specifically, how to treat participants ethically.

Before looking at anything specific, it’s useful to remind ourselves of what learning outcomes in TM470 relate to ethics:

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.

To gain a distinction for this learning outcome, you need to provide evidence to show that you have “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 [your] project work.”

At the beginning of your project it is very likely that you will be gathering requirements from stakeholders. During the middle of your project, you may well ask stakeholders for opinions about your intermediate designs, or emerging solutions; maybe asking their opinions about some prototypes. Towards the end of your project, you may (or may not) choose to carry out an evaluation. Your final project evaluation may involve stakeholders, who might be potential users of whatever product or system you have created.

Treating participants ethically

Given that you are likely to use participants throughout your project, what do you need to ensure they are treated in an ethical way?

A fellow TM470 tutor, Kawal Banga, offers the following useful summary: “you will need to consider how you are collecting data, where you are storing it, what stakeholder contact details you are storing, how you are ensuring anonymity and confidentiality, what will happen with the data on completion of the project, etc.“

Hold onto these points. 

Planning your project

TMA 1 is all about identifying a project, describing its aims, creating a plan and sharing it with your tutor. TMA 2 is all about showing that you have made some progress on your project and beginning to write about the ethical issues.

TMA01 states that:

“You will be considering in detail any legal, social, ethical and professional issues relating to your choice in TMA 02, but at this point you should consider whether these are likely to be serious enough to mean your project choice is inappropriate.”

It directs you to read some resources that have been prepared by the module team.

Before you begin writing your first TMA, do make sure you find the time to have a discussion with your tutor about your project and its aims.

In many cases, one of the first activities that you will carry out will be to establish requirements which may mean that you will need to talk to stakeholders. A stakeholder is, of course, anyone who has a vested interest in your project, or will be affected by its implementation or creation. Before you speak with anyone, you need to consider (as Kawal pointed out) how to collect data, what data you are collecting, and where you might be storing it.

TMA02 states that:

“If your project involves you working with human participants, you should include, as an appendix, your TMA02 LSEPI Form, found in the LSEPI Templates folder.” 

The point being made here is that you may need to address ethical issues before you get to your second TMA. Gathering requirements may mean working with people.

Working with stakeholders

When gathering requirements, if you need to consult people, it is important that you seek permission from those who you speak with and their line managers. Here is a suggestion about different resources that you should consider preparing before you interview anyone:

A project information sheet. This could be a single printed page, which you could then read before you go ahead with any data collection.

A consent form. This form is used to secure permission to gather data, and also to store data. More information about storing data can be seen in a related blog: Writing successful data management plans.

A set of interview questions, a set of survey questions and forms that can be used to gather responses.

Do consider sharing each of these with your tutor; they may well have some good ideas about how they might be improved.

Evidencing an ethical approach

When your examiner reads your project report, they will look for a description of what you have done and evidence that shows you have done what you have said you have done. Using a concept from creative writing, it is important to show the reader, rather than to tell the reader. 

You can show the examiner you have adopted an ethical approach by sharing evidence. You might, for example, share the following appendices:

  • Provide a copy of a project information sheet.
  • Provide samples of signed consent forms. You don’t need to provide copies of all the signed consent forms; one of each broad group of stakeholders will be enough. Make sure you hide any names and signatures. There is no reason why the examiner needs to see these.
  • Provide copies of any interview scripts or data collection forms.

Each appendix should, of course, be referenced within the body of your report.

Resources

The module website contains a number of helpful resources and pages. In particular, within the Legal, Social, Ethical and Professional issues resource, the following two sections are particularly useful:

  • Working with human participants
  • Appendix A Guidelines for conducting research with human participants

There is also a folder called LSEPI templates which can be found within the study materials section. At the time of writing, this folder contains the following files:

  • TMA02 LSEPI Form
  • consent-form-template
  • participant-information-sheet-template
  • EMA LSEPI Form

Do take the time to have a look at each of these files, and reflect on how they might be used within your project. 

When you submit your EMA you need to include a completed copy of the EMA LSEPI form as an appendix (which is something that be easily forgotten).

These above points offer some very practical advice about what you need to do to provide evidence of working with participants. This is, arguably, a very narrow treatment of the connection between your project and ethics. 

Thinking in an ethical way means that you need to consider the impact on any digital tool or product. If you are interested what this means, a good starting point is Carissa Weitz’s Oxford Handbook of Digital Ethics (Oxford University press). You might find a chapter in this handbook that connects with the aim of your project. 

There is a requirements that your write about legal, social and ethical issues within your TMA 2 submission. If you're unsure about what this mean, or how to begin, a good bit of advice is, of course, find some time to speak with your tutor.

Acknowledgements

Many thanks to Kawal Banga and the TM470 module team.

Permalink Add your comment
Share post
Christopher Douce

TM470 Considering evaluation

Visible to anyone in the world
Edited by Christopher Douce, Friday, 4 Oct 2024, 16:04

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.

Permalink Add your comment
Share post
Christopher Douce

What should I do if my TM470 project goes wrong?

Visible to anyone in the world

You have a plan, you have identified all your resources and the skills that you need, and you’ve identified a good number of risk and accompanying mitigations. If things start to go wrong, you should look to your risk log to see if it (and your accompanying mitigations) might be able to help. If they don’t help, there are many things you can start to do.

When things start to go wrong, start to make notes of what has happened, and how you have responded to what has happened. In other words, add entries to your project log. If you haven’t started a project log, start one. It is never too late.

Even though you may have prepared a plan (and identified risks) at the start of your project, these are not set in stone. Your project plan and all the other elements of planning (your resource, skill and risk summaries) should always be updated.

An important tip: keep two versions of your Gantt chart; the plan that you prepared at the very start of your project, and a version that you continually update throughout your project. 

If things are not going to plan, do update your plan, and make a note of why you think this is the case. If things happen in your life which mean that you have to break your regular study pattern, and you find that key project milestones will be delayed, write down what has happened and replan your project. If you need advice about how to approach this, do get in contact with your tutor.

The reason for writing everything down is simple: it gives you some useful material you can use when you get to write your reflection section.

At the time of writing, the reflection section of your project report accounts for 20% of the overall project score. This means that there are a lot of marks available just for writing about what has happened during your project (and saying what you have learnt).

If everything went to plan and there were no surprises, your reflection section would be pretty uninteresting. Examiners are not very fond of uninteresting project reports. If your project doesn’t go to plan, this gives you something to write about.

To summarise, projects can and do go wrong. If you realise that your project has elements of complexity that you never expected, and need to replan, that is completely okay. If life intervenes which means that you need to reevaluate your project’s aims and objectives, that is okay too. Both of these situations will lead to a changed project which means you have a really interesting story to tell in your reflection section.

If you’re unsure about anything, my biggest tip is, of course, contact your tutor to book in a chat.

Permalink Add your comment
Share post
Christopher Douce

TM470 What should I submit?

Visible to anyone in the world

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.

Permalink Add your comment
Share post
Christopher Douce

TM470 Considering resources and skills

Visible to anyone in the world

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.

Permalink Add your comment
Share post
Christopher Douce

TM470 Considering project risks

Visible to anyone in the world
Edited by Christopher Douce, Thursday, 18 Apr 2024, 17:05

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.

Permalink
Share post
Christopher Douce

TM470 Considering software requirements

Visible to anyone in the world
Edited by Christopher Douce, Thursday, 11 Apr 2024, 09:30

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.

Permalink Add your comment
Share post
Christopher Douce

TM470 British Computer Society (BCS) requirements

Visible to anyone in the world

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.

Permalink
Share post
Christopher Douce

TM470: Considering planning

Visible to anyone in the world

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.

Permalink Add your comment
Share post
Christopher Douce

TM470 Learning Outcomes

Visible to anyone in the world

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.

Permalink Add your comment
Share post
Christopher Douce

TM470 Literature review: further tips

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 16 Apr 2024, 18:21

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.

Permalink
Share post
Christopher Douce

TM470 Project Report as a journey

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 25 July 2023, 08:55

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.

Permalink Add your comment
Share post
Christopher Douce

Sharing source code in a TM470 project report

Visible to anyone in the world
Edited by Christopher Douce, Saturday, 15 July 2023, 11:38

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.

Permalink Add your comment
Share post
Christopher Douce

TM470 Considering LSEPI

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 24 Apr 2024, 10:44

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:

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.

Permalink Add your comment
Share post
Christopher Douce

TM470 Choosing a project

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 28 June 2023, 09:01

I’m a tutor for the Open University's TM470 Computing and IT project moduleTM470 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 reviewAcademic writingand 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.

Permalink Add your comment
Share post
Christopher Douce

TM470 Understanding the Literature review

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 28 June 2023, 09:02

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.

Permalink Add your comment
Share post
Christopher Douce

Academic writing in TM470

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 28 June 2023, 09:03

One of the questions I’m regularly asked regarding TM470 is: “how should I write my TMAs and the EMA? Should I write it in the first person or in the third person? Should I say ‘I did this and I did that’, or should I say ‘the author did this, and the author did that’?”

First of third person?

I recommend using the first person, rather than the third person, since you are doing the project, and you are learning from the experience of completing it. The reason I say this is because of the importance of writing clearly, and that it does sound a bit weird (and adds a whole load of extra words) if one refers to oneself in the third person, referring to oneself as the author. 

I consider that the first person is more accessible to the TMA marker and the EMA examiner. Clarity is important, since the EMA report at the end of the module is all about presenting what I consider to be a "technical story" or narrative. All this said, the TMAs and EMAs should be written in quite a formal and academic way. In other words, your submissions shouldn’t be too chatty, and should adopt an academic tone, whilst clearly drawing on materials and sources in a critical way.

What does “being critical” mean?

I understand “being critical” as “showing that you have through about something” and demonstrating that through your writing. It can mean understanding that there is an argument to be unpicked, or it could also mean choosing (or summarising) resources that will then be used and applied (in a critical, or thoughtful way) later on during your project.

In an earlier blog I wrote, I dug out a number of links to a some OU study booklets which are really helpful. I do recommend that you have a quick look at Thinking Critically. The section Writing with a Critical Voice, might be useful too. Section 3.4 on page 22, getting critical thinking into your writing, is also useful too. Also, before you get to the writing bit, there’s also a booklet about Reading and Taking Notes.

Another booklet called Preparing Assignments also offers a bit of guidance about writing introductions and conclusions, writing paragraphs, paraphrasing, quoting and referencing.

Referencing

Talking about referencing, it is important to spend a bit of time looking at the CiteThemRight website. This offers guidance about how to reference anything and everything. It contains sections about referencing academic papers, textbooks, internal reports, bits of software, and even personal correspondence. Reference everything that may have influence your thinking. Also, do be specific in your referencing. Do include page references to really demonstrate the extent and the depth of your reading.

My colleague Charly Lowndes also provides A one minute reminder of where to get advice on the OU CiteThemRight citing and referencing style (YouTube).

The project isn’t just about what you do. It is also about what you have learnt, and you can demonstrate that by the extent and the quality of your writing and referencing.

Other resources to look at

Finally, a few other resources that might be useful.

I’m a big fan of a book called The Good Study Guide. I was sent a copy of it when I started my OU studies back in 2006 or 2007. I remember thinking: “if I had read this when I was an undergraduate, I might have gained a higher degree classification”.

I’ve also written this short blog about academic writing (OU blog), which offers a summary of some of the points that a fellow tutor gave me when I was studying.

Whilst working on the project, it is helpful to have a project log. To help to get a view on what is needed, I have written a short blog, but about how to create and structure a TM470 project log (OU blog).

Finally, looking longer down the road to the EMA, I have written a blog that offers a suggestion about a TM470 report structure (OU blog). Since very project is different, these are not hard and fast rules. It is more important to hit the learning outcomes than to try to follow this structure.

Permalink Add your comment
Share post
Christopher Douce

TM470 Project report structure

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 28 June 2023, 09:03

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.

Permalink Add your comment
Share post
Christopher Douce

Reflecting on TM470

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 17 Sept 2019, 15:17

I’ve now been tutoring on TM470, the Open University’s Computing and IT project module, for three years.

I heard it once said that it takes around three years to get to grips with the tutoring of a module; I agree with this view.

After this amount of time, you’ve marked a good number of TMAs, EMAs and have a solid appreciation of what is on the module website. You also (hopefully) should have a thorough understanding of what is in the head of the module team, enabling you to respond to student queries with a degree of confidence.

Also, three years is enough time to get a feel for what makes up a good project report, a distinction level project report, and a project report that might not pass. Having that experience has also enabled me to question what I do as a tutor, and to help me offer the best feedback I can.

What follows is a set reflections that relate to what I think is important when tutoring on the project module. I’m sharing since it might be of interest to fellow tutors, TM470 tutors, but also the module team too (since they, of course, guide how we approach everything).

These are, of course, my own opinions, and I do expect that different tutors will (of course), have different views - and, of course, have slightly different practices.

Welcoming students

I feel that I started very well in my first presentation but didn’t do so well with this on my second presentation. This said, I think I’m happy with the approach that I have used with the most recent presentation.

I begin by sending each student an email to say hello. If I see that any of my students have any additional requirements, I add a sentence to each introductory email to ask them to let me know whether there’s anything I need to be aware of to ensure that I help them with their studies. This tends to open up a dialogue.

In my introduction, I also mention that it might be useful to have a quick chat on the phone. I try to do this with every student in my group, but not everyone wants to have a chat; and that’s okay. I feel it’s important to be supportive whilst not being pushy.

A final point is that I also tell students to subscribe to their TM470 tutor group forum. The reason for this is that I use the forum to send updates and reminders about various things, and subscribing enables them to get notifications about those notifications.

Keeping in touch

One of the things I do regularly is send all students regular emails. Not every tutor runs tutorial, but I do; I send them dates of the tutorials as soon as they have been scheduled. I also send them a note to remind them of the TMA cut off dates, and send them reminders to let me know that I would like to receive regular updates.

When I send reminders about a willingness to receive updates, I also make the point that everything that is sent to me can also be used and presented within the project report as evidence of progress. I hope this offers a further encouragement!

Tutorials

At hinted at earlier, some TM470 tutors run tutorials, whereas other don’t. There isn’t a requirement for TM470 tutors to run tutorials; some tutors only run one to one sessions with their students.

I find tutorials useful for a couple of reasons.

At the start of the module, I fix a date for two introductory sessions: one that takes place in the evening, and one that takes place in the day time. I send all these dates to students in a group email and post the same information about them on our tutor group forum.

I split my tutorials in to two parts: the first part that is recorded, and the part section that is not. Dividing the tutorials in this way enables the first section to be viewed by the students who were not able to attend either of the tutorials. The second section becomes an informal chat between the students who come along.

In the introductory tutorial, I talk about the assessment strategy and the first TMA and do some screen sharing to introduce students to the module materials.

I tend to run two EMA preparation tutorials which has a similar structure, but with more focus on what a good EMA might look like. I also do some screen sharing: I take the students to the referencing guidelines site, and might even take them to some Skills for Study sections materials that are about academic writing.

One-to-one sessions

Every student has four hours of personal one to one time. I don’t keep a very close tally of how much of that time is used; some of it could be roughly allocated to tutorials, whereas other bits of time could be allocated to one to one sessions.

I mention one-to-one sessions in different ways: in the TMA feedback, during tutorials, and in the keeping in touch emails. If students don’t want to take me up on the offer of a one to one chat, that is okay, but I do make it clear that this is an option that is available.

Rather than having telephone chat, I’ve tended to use the Adobe Connect tutor group room. One of the great advantages of this is that we can do some screen sharing. Screen sharing is really useful. I’ve used it as a way to get an understanding of how a student’s draft submission is coming along, or to guide students to resources that have been prepared by the module team. I sometimes give the student screen sharing permissions so they can take control of those sessions.

TMA Feedback

There are, of course, two main components of the TMA feedback: the summary page, and the on-script comments.

On the summary page, I tend to focus on offering three clear points of advice that student should work on to improve their performance on the next TMA. When I’m writing these points, I try to explain why these points are important, and how they connect to the aims and objectives of the project module.

When I’m working on later TMAs, I always tend to do a quick read back of the previous TMA summaries. On occasion, I’ve copied and pasted text from the previous TMA and have put it on the current TMA, saying: “I gave the following feedback; it is important because…”.

I also tend to conclude a TMA with a suggestion about having a follow up call or chat.

For the on-script comments, I encourage students to use the Word in built heading tools (if they are not using them already). I make the point that it enables the student to use the navigation tool (which helps the student to view the structure of their EMA). Also, increasingly I tend to offer some practical advice about the formatting of sections (showing how students can move between portrait and landscape page layouts). To help students get to grips with these elements of Word, I have also offered link to various YouTube videos to help them understand the points that I’m making.

Tutor group forum

Students don’t tend to you my tutor group forum much, but I tend to use it as a simple notice board.

Here’s a summary of how I use it:

  • Sharing dates of tutorials, and providing of links to recordings.
  • Giving updates about TMA marking. I make a post to the forum when I start marking, and then post again when I’m roughly half way through (to give students some idea about when to expect their results). I tend to ‘pin’ these posts at the top of the forum during the marking.
  • Sharing of additional resources and links.
  • A space for students to ask questions.

Staff tutors can (or may) dip into tutor group forums from time to time to see what is going on. A well populated tutor group will give a staff tutor the impression that all is well with the group.

Additional resources given to students

During this most recent presentation I prepared two really short resources in the form of Word documents that might help students:

  • A very short sample introduction to an imaginary project and project report. This sample presents a structure that is very similar to the guidance that is offered by the module team.
  • A sample table of contents, which includes an introductory section, a section that outlines the project, a literature review section, an account of project work section, a reflection section, a summary or concluding section and a series of imaginary appendices.

The aim of these two resources is to emphasise the point that the project report, and it’s overall degree of readability is really important.

Advice to students

I’ve sometimes offered the following tips at various points during the module. I might mention these suggestions during tutorials, or in one-to-one sessions:

  • Make sure that you use the features that are provided in Word well; they can help you to find you way though, navigate, and work with larger documents. 
  • Try to write the literature review as a narrative rather than a list of papers or resources that you consider to be useful for the project.
  • Think of the examiner as a friend who doesn’t know very much about the project (and subject) that you’re writing about. Subsequently, you might have to spell things out for them. Don’t worry about doing this, since this will all help to demonstrate your understanding of some important concepts.
  • Consider the reflection section, the bit in the EMA where you have to write about how things have gone, as a gift. It’s a gift because it’s all about you, and there are no wrong answers, and the examiner really wants to hear about you and what you’ve learnt. Also, don’t be afraid to be opinionated! Tell us what went well, what didn’t, why you thought that, and what you might have done again differently.
  • Provide copies of two different Gantt charts; one that was created at the start of the project, and the Gantt chart that was being used as the student got to the end of the project. These two Gantt charts gives a student a neat way to generate some interesting reflections, simply by considering the differences between what the plan was at the start, and what happened during the project.
  • Use the appendices as a way to share extra information about what project work you’ve done on the project.
  • Keep to the word count (10k words) but don’t worry too much if you go over by a little. If you’re going over by a lot, consider putting some bits into a series of appendices, but always make sure that you reference these in the body of your report.
  • Finally, find someone to proof read your report. It’s okay to do this, since you’re the one who is doing the writing, not whoever is doing the proof reading. Typing mistakes can and do happen. A friendly proof reader will be able to pick up on some of them.

EMA marking

EMA marking is hard work, and we don’t have too much time to do it in. When I start marking, whenever I open an EMA report, I turn tracking on, and highlight sections that I’ve read that really stand out to me as being good, important or significant. When I’ve read everything, I might go back and re-read sections before going to the learning outcomes that are presented in a grading spreadsheet. I then make notes, which are later copied and pasted into the OU’s grading tool.

My own approach is to do some marking first thing in a weekday morning (when I’m fresh), hopefully working through a couple of reports, with a view to doing more over the weekend.

If there is a moderation exercise, the highlighting annotations I’ve added really help me to remember what a project was all about, and why I assigned certain marks against a particular learning outcome.

Closing thoughts

TM470 has a slightly different tenor to the other modules I’ve tutored. Although there is a lot of learning to be done during the project, it is more about doing and writing (and then learning from that doing and writing).

Students sometimes ask whether they can see an example of a project, but this is something that the module team doesn’t provide. I can understand why students would like to see a sample (to understand more about what the module team expects), but I can also why the module team doesn’t provide one (they worry that the tutors would then receive a hundred or so projects that look remarkably like the sample projects).

One of the challenges (in my opinion) of being a TM470 tutor is to help students understand what the module team expects, but from the perspective of their own projects and their previous studies.

Permalink Add your comment
Share post
Christopher Douce

Making a TM470 log by using a blog

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 10 Apr 2024, 17:05

TM470 is the Computing and IT project module. The project module allows students to draw on skills and ideas that they have studied and developed during earlier level three modules. It enables students to demonstrate skills across a more substantial piece of work.

This short blog post is basically a bunch of ideas that might be useful for fellow TM470 tutors, but also for any TM470 student (and anyone else who might be involved in a project module).

A really important part of TM470 is the end of project report which summarises everything that has been done. The report requires students to present a description of the outcomes of the project, and what has happened during the project.

The project log

TM470 project can last up to eight months. During that time, a lot can happen. To keep track of things the TM470 module team recommend that students create something that is called a project log. Here’s an excerpt from the module materials that offer a bit of guidance:

"Keeping a project log is similar to keeping a diary. It is a useful aid in helping to manage a project. In a project log, ideally you should make a log entry each time you have a work session.

Whether recorded on paper or electronically, your log is where you keep details at regular intervals of salient events or facts that have occurred in your project. The log differs from your plan in that it provides more detail of things you have done, whereas the plan is a schedule of what you are or should be doing. The log is purely historical information; it can contain facts about your project but probably more important is writing down reflections about what you are doing."

The module team suggests that a log serves three purposes:

  1. They provide a reminder of how your project developed; this will be useful when it comes to writing your TMAs and EMA.
  2. They help you when in discussions with your tutor because they provide a record of how you planned your project, how you managed your time, how you tackled the tasks and how you dealt with any problems.
  3. Using the log sheets on a regular basis will help you to keep to your schedule, and may suggest changes to your schedule. 

Students are told that they should be spending approximately ten hours per week on their project. The project log also enables students to keep track of how much time they’re spending on the project. 

Students are also encouraged to submit excerpts of their blog to their tutor, to keep them informed about how their project is progressing.

The OU VLE

The module team suggests that a log might be recorded on paper, or recorded electronically. An accompanying question is: what form might an electronic log take? One approach is to use a word processing document. You could have a day for every page. One idea is to record a ‘session number’, record a date, record how long was spent working, and also a summary of what was done during that session, and perhaps some thoughts about what the next steps might be. In some ways, this kind of log has parallels to a ‘work log’ that a researcher might keep.

Rather than using a word processing document another idea is to keep a TM470 log in the OU VLE blog.

Every OU student is given their own blog, which is hosted in the university virtual learning environment. The OU blog is useful because it provides a number of useful features:

  1. It allows students to automatically record the date and time of any entry that is made.
  2. It allows students to add ‘tags’ against particular blog entries. A tag, of course, is a useful word that can be used to help find things again. Using the OU blog you can quickly find blog entries with the same tag (in the way that the tag for this post is TM470).
  3. Students can any log entry with other TM470 students, and they can share their TM470 log entries with you. Blogs can be easily shared with a tutor, enabling them to more directly understand progress on a particular project.
  4. The blog can be accessed easily through a web browser: you don’t have to use the same word processing software every time.
  5. The blog is automatically backed up by the university, which means that you don’t have to worry. 

Another feature of the OU blog is that students can choose who sees what is posted. 

The OU blog has three settings: students can keep every blog (or log) post private; this means that a blog can be a bit like a private diary. Another setting is that blog posts are only visible to people within the university. This setting is useful for sharing blog posts to other TM470 students. The final setting is to make a blog post visible to the entire world. In terms of TM470, I personally recommend that this first two options are used.

An accompanying question is: how can students begin to use their blog? The answer is to look for their VLE profile. They will soon find a link that allows them to begin posting a blog.

Note taking advice

Whilst the TM470 module team offers some great advice for creating a log, the university also offers other advice which might be useful too, such as note taking techniques which is available on the skills for study website.

Also, the following three useful points (Making notes strategically) have been adapted from Northedge (2005) from his book The Good Study Guide, p.155:

  1. Take an active and enquiring approach to study. Ask yourself questions, such as ‘what is this about?’, ‘what do I want to remember?’ and ‘what do I want to say?’ and writing down the answers.
  2. Flexibility. Make sketched notes or detailed notes according to need. This can be particularly useful when making note to support creativity. These notes could then be ‘written up’ and used within the project log. Plus, having them in a blog form allows them to be searched.
  3. Reflection. Looking at notes and ask: ‘are they doing the job I want?’ and ‘could I be using my time more effectively?’ Or, put another way: are these the right kind of notes.

Sharing blogs with other students

The best way to share blogs with fellow students is to share links to the blogs in the module discussion forums. Once you have a link to a blog, you can then add it to something called a ‘blog feed’, to receive a notification whenever a new update has been made. Another advantage of a blog is, of course, students will see that they’re not alone; that there are others who have to contend with similar challenges.

Update 10/4/24: a fellow tutor, Karl Wilcox has written an (arguably better) companion article, Thoughts on Project logs, which might be helpful. An important point to note is that this article, and Karl's article are opinions from tutors. Students should always refer to the official module materials for guidance.

Permalink
Share post
Christopher Douce

Day in the life of a STEM staff tutor (reprised)

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 15 Feb 2017, 21:14

This blog post echoes a blog post I made in June 2015. The earlier blog was designed to accompany a presentation that I gave to the Computing and IT student support team, who were then based in Birmingham. Since I gave that talk, things have changed: the Birmingham office is just about to close and the functions have relocated to the Open University Manchester Student Recruitment and Support centre.

This post has a similar aim: to accompany a presentation that I gave to my student support colleagues to given them a feel for what Computing and IT staff tutors do. An important point is that every staff tutor has, of course, slightly different roles and responsibilities. Our exact mix of duties and responsibilities depends on our own expertise and interests. 

Another point is that every day can be very different. Here’s what I wrote last time: ‘the below narrative is a collage of aspects from different days. I’ve written it this way so give a sense of the diversity of things that we do. It’s not representative, since every day is different, but it does give a taste of what kind of things a staff tutor gets involved with’

Blitz the inbox

I wake up at any time between 7.00 and 8.00am; I often watch the travel reports whilst I eat breakfast. Now that I’m a home worker, I do find the travel reports strangely satisfying; I take a life affirming moment to reflect that I’m not in the middle of one of those huge snarl-ups on the north or south circular roads.

One of the first things I do is triage my inbox to decide what is important. The exciting thing about being a staff tutor is that anything could happen. I look after approximately sixty associate lecturer contracts (or tutor groups) across three different levels of study. To give an impression of scale, a tutor might (of course) have anything between 18 and 20 students. 

My key objective is to get to the messages that are important. So, glance through announcements about conferences and drainage issues. I delete messages that offer reminders about events in Milton Keynes, even though I’m not working in Milton Keynes. I shift-delete emails about fire alarms and electrical testing, and start to read messages, dropping updates about new procedures into folders (I don’t read things in depth if I don’t need to).

TM356 tutor telephone call

The first scheduled event was a chat with a TM356 tutor. Our tutor has been raising some really good points about the design of some online sessions; he’s also very experienced too. We shared views about how things are going on the module, and I make a note about some things that I need to bring to the module teams attention.

After our chat, I receive a delivery: it’s my new desk. To make things easier at home I’ve been reconfiguring my study area, and this has meant trying to find a bigger work area. I haul a big new desk into my lounge and start to puzzle about what the next step needs to be: my desk needs varnishing. I make a mental note.

It is a busy morning: I email a tutor about organising an additional support session, and then send off another email, this time to AL services in Manchester about transferring TMAs from one tutor to another due to a tutor being away on sick leave; a few days earlier I had found a tutor who was willing to cover.

AL CDSA

A Microsoft Outlook reminder popped up on my screen: it told me that there was an AL CDSA (appraisal) was due in fifteen minutes. I started to get everything sorted out: I opened up the tutor’s draft CDSA form that he had sent to me and the tutor’s ALAR report in a different screen (I have a two screen setup; my new desk will allow me to have three screens!) I familiarised myself with the contents of the ALAR report: turnaround times were very good, and the student surveys were very good (but like with so many student surveys, not many students had responded; this is always a problem that isn’t easily solved).

I get everything sorted out for the CDSA and give the tutor a call. He was great to talk to; he was committed and dedicated. I asked him what kinds of things I might be able to do to help him in his job, and told him to contact me if he has any suggestions about what AL staff development events might be useful.

Academic work

After a drop of lunch and a bit of TV it was onto the afternoon stint. Now that the key emergencies had been sorted out, it was time to get onto some academic work. For me, the term ‘academic work’ can mean a whole range of different things.

Over the last year and a half (or so, perhaps a bit longer) I have been a deputy editor for a publication called Open Learning: The Journal of Open, Distance and e-Learning (Routledge).

The journal has an interesting history: it began as an internal OU publication that shared information about ‘the OU approach to teaching and learning’ amongst its many staff. As time has moved on the journal’s remit has broadened, adopting a more international focus. It is still an Open University institutional publication but it is one that is more outward looking. It does, however, maintain its core focus, publishing research about distance education, technology and educational practice. 

I spend about an hour looking through the status of the submissions. I try to match up newly submitted papers to reviewers. One paper has been reviewed, and there is a positive ‘accept’, which is always good news. I read through the reviewer comments and have another quick read of the paper before making a final decision.

When this is done, I get onto editing a PowerPoint presentation for an online tutorial that is scheduled to take place later on in the day. I send a couple of pictures I have taken from my phone to my laptop, open up the PowerPoint, and then drop them in. I then convert the PowerPoint into the native OU Live format, and upload the new file as an OU Live preload, just to make I’m fully prepared.

I receive an email from an associate lecturer colleague that I’m working with. We’re working on a tutorial observation research project that is funded by something called eSTEeM, which is all about Science Technology Engineering and Mathematics education. My colleague has started work on a literature review and it looks brilliant. I look in my diary and I fix a time to have a chat about how things are going.

One of the things I really enjoy doing is AL development. I enjoy it because it’s great speaking to all the tutors. At the start of the month I ran a TM470 AL development session for purely selfish reasons: I am a tutor on TM470 and I wanted to run some tutorials, but I was also very aware that other TM470 tutors are significantly more experienced than I am. Put simply: I wanted to steal some of their good ideas, and a way to do this is to find a way to get tutors talking to each other. To do this, I ran an online staff development event.

After the event had finished, I had to do a couple of ‘wash up’ tasks. The first one was to send AL services in Manchester a list of associate lecturers who had attended. The second was to write a quick blog post about the key findings, and share that post to all tutors. I spent the next couple of hours going through the recording of the event, making notes, and putting everything into a blog summary of the TM470 AL development event (blog)

Evening

I try not to work evenings (or weekends) but sometimes you just can’t avoid it. It was one of those nights.

At the start of TM356 Interaction Design and the User Experience, some tutors were worried about an event called the ‘Hackathon’. The OU group tuition policy stipulates that each face-to-face event must have an online alternative. The thing is, the TM356 face-to-face Hackathon takes an entire day, and you can’t have an online equivalent of an event that starts at 10.30 and ends at 16.30; it just wouldn’t be humane!

With a blessing from the module team, I made the executive decision to create three ‘parts’ to a longer running online equivalent. After making this suggestion, I realised that I was going to making a substantial contribution to the pedagogic design of these ‘parts’. 

The tutors were asking, quite rightly: ‘how are these sessions going to work?’ 

I made a decision: showing and demonstrating a teaching idea would be significantly easier than writing a document that tutors would then have to try to decode. I had prepped a session, uploaded a session, and I worked with a tutor to deliver a session.

My fellow tutor had some brilliant ideas; we tried a ‘dialogic approach’ to teaching, which means: ‘we asked each other questions’. Listening to two voices is always, in my opinion, more fun than listening to one.

Permalink Add your comment
Share post
Christopher Douce

TM470 AL development: should we run tutorials?

Visible to anyone in the world

Just before the start of the TM470 project module, I asked myself a question: should I run a tutorial? Tutorials are not compulsory but I do know that some tutors run them. I had another question: what do other tutors do? These questions motivated me to ask my TM470 line manager another question: ‘could I run an AL development session to ask tutors what tutors do? This might be something that could help other tutors’. My line manager, Keith, agreed.

This document (or blog post) is a quick summary of the key discussion points that were drawn from that AL development session. Most of these points are from two activities. Tutors were put into four different break out rooms and asked to answer a set of questions. After the discussions, we all came back to the main room and discussed our findings.

The headings below represent the questions that were asked. The comments underneath are, essentially, a quick summary of the points that were discussed.

What would be the aim [of a tutorial] and when should you run one?

Run a tutorial early in the module to give students some guidance about the way the project should be approached (coding and creating versus recording).

Mixed feedback/feedforward and used student participation.

Tutorials seem to work better if they are studying similar subject: whole cohort sessions on specific topics? The challenge is that ALs have limited time.

To discuss key skills like research and literature: this can lead to fewer repeated emails about generic questions.

To save time repeating the same information to other students?

What would you do in a tutorial?

Setting out the approach for the module.

Getting students to generate 3 or 4 PowerPoint slides, and then discuss in tutor group (getting students to do the work). Tell us what they’re doing, and an issue that they have. Be positive.

Try to get them thinking less about the technical stuff: more about project management and reflection.

Try to get them to appreciate the need to address learning outcomes.

Talk about literature reviews.

Discuss deadlines and what is required.

A drop in session to allow students to discuss things. A learning outcome should be: students should be able to present their projects to other people.

In some situations, depending on what is taught, a video from the module team might be useful.

Discussions contribute to learning outcomes.

What are the challenges and what would help you?

Getting students to attend.

A tutorial can become a monologue (lecture)

Students without audio: most will say something in the chat window.

Recordings: will students turn up? Or will students be disadvantaged?

Privacy concerns about disclosing information about student projects in tutorials.

Having enough time to run the tutorials when tutors are busy answering emails.

How do you maximise attendance at a tutorial?

Use the forum, and the group email: allude to the benefits of the tutorials, saying that they will end up doing better projects.

Take every opportunity to encourage attendance: in every chat, email or piece of feedback (TMA!) refer to the next tutorial.

‘Put the fear of God into them’; tell them they must attend – it is there for their own benefit! This is a very difficult course! Don’t miss it.

Using a Doodle poll to set an agreed time.

What are the most difficult things for a student?

Working consistently, i.e. not trying to do a TMA over the weekend.

Managing time and deadlines.

Not understanding the requirements/components of a project.

Not having the patience to fully explore the background to the problem.

It is a module without a substantial calendar: students have to plan in their own time.

Reflection.

How to plan and structure.

Finding resources.

Getting started at the right place, and knowing when to stop.

Knowing their own limitations: they need a project that demonstrates their skills and knowledge.

What common mistakes do students make?

Trying to do too much, or under estimating time required.

Not reading what is required for the TMA: read the instructions! Look out for what the module materials are asking for.

Wanting to try new toys just to add experience rather than trying to engage deeper with the subject.

A literature review that is not deep enough.

When there are projects that relate to work situations, there can be too much focus on satisfying the client’s requirements rather than the module’s requirements.

Do the students have a backup plan if things go wrong if they have a ‘client’?

Students focus on assignments and not just projects.

If you could offer one bit of advice to a student, what would it be?

It’s not about writing code.

Stick with a simple system: don’t be too ambitious.

Don’t panic!

Use the full window of time and execute each stage completely.

Keep in contact with your tutor, no matter what is happening!

If you could offer one bit of advice to a new tutor, what would it be?

Tell students to keep evidence of what they’re doing e.g. a log of activities, which is very useful for report writing.

Application of common sense when it comes to keeping students on track.

Keep talking to your students; keep contacting them if they don’t contact you.

Keep discussing with other tutors: use the forums; there is lots of experience.

Final thoughts

From my perspective, I was really surprised with how many interesting, different and useful points came out from these discussions. This session has (personally) given me some really good ideas of things to speak about in a TM470 tutorial.

One thing that I should say is that there were two schools of thoughts about whether tutorials are needed or not. I think I remember reading (or hearing) one opinion that perhaps they are useful in terms of getting students started, but then the hours that the students have could be spent on a more personal or one to one basis.

There are, of course, many different ways to support students, and this session has helped to share some really great ideas between tutors.

A final question is: what next? I felt this session has been personally really useful. Does anyone have any ideas about what else might be useful? One thought is a ‘tutor drop in’; an opportunity to discuss interesting projects and situations. Another passing thought is the potential benefit of talking about marking or correspondence tuition. I think I’ll stop at this point, and hand this discussion back to all those TM470 tutors who are significantly more experienced than I am.


Permalink Add your comment
Share post
Christopher Douce

TM470 notes

Visible to anyone in the world
Edited by Christopher Douce, Thursday, 16 Aug 2018, 14:48

The university has been going through a lot of changes. One of the side effects of these changes is that I have now become a home worker (which I’m a bit grumpy about). To prepare for a delivery of a new desk, I’ve started to sort out loads of old papers. The process usually involves looking at a bundle of papers and thinking, ‘why did I keep this?’

I recently stumbled across a hand written form that relates to my first year of tutoring on the TM470 project module. Rather than putting it in a file (or in the recycling), I thought I would transcribe it and share it. I hope it is useful to someone!

The form is divided into four sections:

Project themes (in my tutor group this year)

The form was asking for the projects that students in my tutor group chose. I’ve decided to edit this bit and be pretty general. The project were about: an app evaluation, a database implementation, and a website redesign.

Issues encountered (and how I resolved them)

One of the challenges was projects that had a very big or wide scope. Subsequently, another issue was projects that had a really narrow scope. It was sometimes quite difficult to get hold of some students. There were many students asking for extensions. The marking (of course) was quite challenging, and on occasions I was asked to do some remarking. It was also difficult to keep students on track, mostly because everyone on the project module is different and have their own circumstances.

What I have learned (including positives)

The first item I noted was: broadness of project topics. The students can, of course, surprise you. What struck me was the importance of the literature review in the module. I learnt more about how the project module was connected to other modules in the Computing and IT programme and also how it was different to other modules. It was useful to think of the module in terms of it being an ‘extension to level 3 modules’; creating a database isn’t enough: students need to demonstrate skills and go further in terms of either their understanding principles (such as transactions or concurrency) or the application of ideas. I also learnt the importance of sending out ‘update’ emails.

Ideas for next year (things I could do differently)

Each student is given four hours of support time. Different students and different tutors may use this time in different ways. One thought is: after initial contact (perhaps even by telephone), is to run an introductory tutorial for the student group. 

Another note I made was, ‘emphasise the library screenshare’; this comment relate to a session that is run by the OU library, to help students with a literature review. Another note I made was: ‘be a bit more persistent in terms of following up; call them after their TMAs’. Another thought was an interesting one: ‘try to get students talking to each other’. A related point was: get students presenting to each other.


Permalink Add your comment
Share post
Christopher Douce

TM470 New tutor day

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 22 Nov 2016, 09:46

I first joined The Open University as a part time tutor back in 2006 where I tutored a module called M364 Fundamentals of Interaction Design. Knowing that this module was coming to an end I decided to apply to tutor on another module: TM470 The Computing and IT project, and I was successful!

I was invited to attend a ‘new tutor day’ which took place in the West Midlands regional centre in Birmingham (which is, sadly, closing in the new year) to learn about the ins and outs of tutoring this module. This was also an opportunity to meet my TM470 mentor, fellow TM470 tutors, and some of my colleagues who support the delivery of computing and IT modules from the Manchester and Birmingham offices. This blog post has been drawn from a set of notes I’ve made during the day, which took place on 2 July 2016.

Project choice

I’ve noted down the question: ‘what makes a good project theme?’ It’s a simple question and one that is very important: students must have a clear idea about what the problem is that they want to solve within their project. It should also have sensible limits, i.e. students shouldn’t aspire to creating the next big app for the iPhone.

Successful projects are those that draw upon practical skills that have been learnt (or studied) in previous level 3 modules. A project could also build on something that has been done before. Students should (ideally) be knowledgeable about the domain or environment in which a project relates to (so they don’t have to spend lots of time doing research into an area that isn’t familiar to them). Also, importantly, a project should be connected with something that a student is interested in doing (so they maintain their motivation).

Another bit of advice is: students should stick with using software that they know; don’t be tempted to play with new things, since it’s easy to get tied up in knots.

Sometimes students might be tempted to draw upon projects that relate to their work place. An important point is: work and TM470 have different goals; it is probably best to keep work and study separate for the simple reason that changes at work might jeopardise the project. This rule, however, doesn’t have to apply in all cases: students need to understand what is required from TM470.

Another really important point is: a project doesn’t have to have a successful outcome to submit a final project report. Students can still pass if things go horribly wrong: it is the description of the project, the learning, and the reflections that all count towards the final scores. If these are done really well, students will get a really good pass.

Another note I’ve made is all about research: ‘not really understanding what is meant by research that is academic, or what is meant by an academic literature review (and analysis)’. Some projects may be research projects, in the sense that they are an in-depth and critical study of a particular area. If students choose research projects, the need to be clear in terms of what is required of them. 

Independent learning

TM470 is different to other modules, since what really matters is being able to demonstrate independent learning; tutors will not be subject experts in all the areas in which projects are chosen from. A note I’ve made is: ‘if software breaks, it is part of your job on a project to fix it’. The role of a tutor is to push a student into this mind set.

Practicalities

I made a note that we discussed the importance of the introductory letter, and that we might connect this to the use of our module discussion forum.

A really important resource is the OU Library which allows student direct access to a wealth of prestigious journals. Another thought is to direct students to library tutorials (understanding eJournals) about how they can get started.

The project module doesn’t have any official tutorials, since it is difficult to run group events where every student is working on a different project (and will have different learning needs and problems). This said, some tutors do use OU Live to run some unofficial introductory tutors. 

Towards the end of the day, we discussed practicalities about end of module assessment marking, and assignment marking. Key questions that were asked were: ‘how do you do it?’ and ‘what processes do you use?’ The module has a very clear set of marking guidelines that are also known to the students. Ultimately, everything comes back to the question of whether students have met the learning outcomes.

Reflections from first presentation

Now that I have more of an idea how the module works and how it is structured, I think I will run an introductory OU Live tutorial at the start of the next presentation. This will allow me to learn more about the student’s ideas and understand more about their potential problems. I will also use this to emphasise the importance of time management.

In comparison to other modules that I have tutored on, I found the marking to be pretty straightforward once I knew how it worked. It took me a bit of time to find the forms, and then to internalise the marking criteria (but this is always the case when starting to work on a new module). One of the things that I really enjoyed was looking at the diversity of the projects, and how the students tackled them.

Permalink
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 2350525