Personal Blogs

One of the most important sections in a TM470 project is your account of project work section.

This section might go by the factual title of ‘account of project work’, or just simply ‘project work’. What you include in this section should reflect your project plan and your high level summary of all the activities that you have determined you need to carry out.

How you organise your project work section will, of course, depend on the character and nature of your project. If you adopt an iterative approach, where you have used a series of sprints, you might want to have a series of subsections which relate to each of your iterations.

Before we get into looking at a potential structure of a project work section, it might be useful to return to what a project report might look like by reviewing a TM470 project report template.

The key point is this: in your account of project work section, you must show, rather than tell the examiner what you have done. It isn’t enough to say  ‘I designed a prototype’, you need to show the creation of the prototype. You need to show the identification and evaluation of requirements, the creation of potential designs, or potential mockups. I’ll get onto saying a bit more about this later.

A potential substructure

What follows are some suggested headings. As mentioned, every project is going to be different. This means that you must adapt this guidance to suit your needs. You may need only some of these suggested headings.

Requirements

Begin by analysing or presenting your requirements. This is the start of your project. It sets out what you need to do, or need to build. More information about how to approach requirements can be found in the following two posts: TM470 Considering software requirements and TM470 Requirements revisited.

Sprint number ‘n’

Your project may contain any number of sprints, where you may aim to implement an element of your project (or, find out about something, or do something that relates to your project. The letter ‘n’ suggests that you may have a number of these sprint sections. Give your sprint a title. Make it easy for the examiner. Tell them what you are doing. You might even be creating a prototype within your sprint. It is up to you, but show them what you do.

Topic number ‘n’

Rather than presenting your account of project work section as a series of sprints, you might instead split your project work section into a number of related topics, or themes. This is an appropriate form if your project is a research project.

Evaluation

How do you know if your project is a success? Another way to phrase this question is to ask: does your project satisfy all the requirements you have specified in an earlier section. Evaluation might be something that you do as a part of an iterative cycle, or it might be a phase within your project. More guidance about how to think about evaluation can be found in TM470 Considering evaluation.

Presenting your work

Repeating the earlier phrase, it is important to show the examiner not what you have done, rather than just ‘saying’ you have done something. Your examiner will need to see evidence of your project work. They need to see your thinking. You should do this by providing a narrative description of everything that you have done.

There are two places to share your work: in this account of work section, and in any number of appendices. Think of this account of work section as a showcase, where you show off your best work, and the work that forms the heart of the project. If you have created a lot of designs, analysed a lot of research, or have written a lot of source code, put everything you have created in a series of appendices, and copy the best bits into the body of your project report, to the ‘project work’ section.

Consider:

• Taking photographs of your context, or the environment which your project relates to. This helps the examiner to understand more about your problem domain.
• Sharing any early sketches you might make. It is okay if they are really rough. A series of them will show progression.
• Showcasing problems that you found difficult to solve. Take screenshots of significant bits of code, or present your code in a different font. Accompany code with descriptions to explain what you are showing, and why.
• Sharing screenshots of early or later prototypes.
• Sharing screenshots of any complex configuration pages or files that you either struggled with, or are important to the completion of your project.

Some further resources

This post relates to a series of other posts that relate to your project report:

TM470 Considering planning

This post says something about what you need to do to plan, and what you should include in the planning section of your report. Do not skimp on planning. Also, return to planning throughout your project.

TM470 Considering LSEPI

Ultimate, computing is a subject that is connected to people and society. Your LSEPI section is important. It should ideally be situated before the literature review. Use it to consider the potential impact of your project. Do consider those unexpected consequences. It is also important to treat everyone as ethically as possible, as explored within TM470 Considering LSEPI (again). The issues and points that you identify within this section can be further explored within your literature review section.

TM470 Understanding the Literature review

The lit review section is about three main things: it is about showing what reading that you have done, showing what literature and resources you will later go on to use and apply, and it is about educating the examiner about the context of your project.

TM470 Considering prototyping

Prototyping is an important and powerful technique. In your account of project work section, you might show the creation of a number of different prototypes.

TM470 On Reflection

When you get to the end of your project, you need to say something about what you have learnt by completing your project. This post highlights the connection to the various learning outcomes that the module is assessing.

Reflections

The project work section of your project report accounts for 40% of the overall result of your EMA. This means it needs to be detailed and comprehensive. The biggest tip, of course, is: show, don’t tell. If you’re unsure as to whether to put something in, include it. You need to show lots of evidence of everything you have done.

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.