Chapter 3 – Coding Conventions
Welcome to the latest in my series of articles on the subject of college management. As a recurring theme, we’ve been looking at the cross-over between technical and non-technical staff, emphasising the requirement of staff from both camps to work collaboratively. As a former lecturer who for many years has been doing technical work in software design and data analysis, I’m particularly interested in the interface between technical work and its practical applications – based on the assumption that unless it has some positive practical effect, technical work isn’t worth doing in the first place…
The previous chapter looked at some ideas about managing the production of reports, a fairly accessible and generalised subject matter. This chapter delves into something more specific and fundamental, which partly underpins reporting and data management more generally – how data is structured and the influence of that structure on reports.
This may sound a bit of a dry and narrow topic, but bear with me, if you manage data or design or use reports you should find something in this article which you can relate to.
Codes and their impact
In order to make this topic accessible, allow me to simplify. Based on years of experience of reporting, I’ve learned to think of the ‘basic building blocks’ of any college as one of two things:
- Individual students
- Groups of students (which may be by course, taught group, register group, curriculum area)
And hence, the two most commonly used data types in college reporting are therefore:
- Student ID numbers
- Course or group codes
This might sound overly simplistic, but this is a helpful starting point from which to build. In report building we talk about grouping data by various levels (or headings) and sometimes we simply present data at student level and that is sufficient. Reports including only data which sit directly against the student are usually very simple to produce. For example, we might want to know what proportion of full time students have completed a work experience activity. As long as we have something at student level to define whether a student is full time (this may be a field from a list or a GLH figure) and a table of work experience activities which references our student ID numbers, this will be an easy task. It follows that if we talk about any ‘group’ of students which is defined only by a personal characteristic (e.g. ethnic group, disability, gender, mode of attendance), then this is equally easy to include in a report as this data sits directly against the student ID number. This is a different sense of the word ‘group’ from that which follows.
The other sense of ‘group’ (and the usual intended meaning when using the word) is when we think of students grouped by taught session, course, subject area or department/faculty etc. Reporting on these ‘curriculum based’ groupings of students is much more complex for two reasons:
- We have several different ways of defining curriculum groups.
- Most students enrol on more than one course, which makes the structure of reports more complicated.
Defining Groups of Students
Fundamentally, students enrol on courses and are then normally placed within a group on that course (group A, B, C etc – and where only one group exists within a course, colleges will often call this ‘group A’). Hence we often use ‘enrolments’ as a way of defining our groups of students, but this is not always sufficient due to the way in which students are actually taught. A class register is sometimes the only accurate way to define which students physically sit within a class, and registers do not always tally exactly with course or groups codes (this is especially true where students from different ‘courses’ are taught together on one register, which is highly prevalent in maths and English provision and also common in many vocational areas). Hence, registers become an alternative way of defining groups of students as opposed to enrolments. Also, different levels of grouping exist. Sometimes when we talk about groups of students we are literally talking about ‘one class at a time’, but more often we actually mean a larger group containing students from many courses. This usually involves grouping students along the lines of the college hierarchy such as by department, curriculum area, faculty, directorate or campus. Other examples would be subject sector area (which will normally be held against the course code) or qualification type (e.g. BTEC Nationals or GCSE English/maths). In other words, ‘groups of groups’!
An Example of Why Groups can be Difficult
Here’s a practical example. Many colleges use ProMonitor or an equivalent system, where staff can record indicators of how well students are progressing (marks for homework, coursework, tests and exams etc). This can provide a rich source of data on how students are getting on with their study. In simple terms, imagine that each student has a + or – figure which represents whether their work on an enrolment is better or worse than might be expected against their target. This simplification in no way affects the relevance of this example.
With the current emphasis on progress, managers are increasingly requesting reports on student progress. A member of senior management might say, ‘what we need is a report from ProMonitor which shows how well all our students are doing against target, highlighting those who are below target’. This is a perfectly reasonable request and it can be achieved – but we need to be more precise. The report should not simply be an endless list of student names with + or – figures against them, which would be very little use to anyone. In the first instance it is of course very simple to restrict the report to only those students with poor progress (e.g. worse than -10), or to highlight in red any students with a strongly negative score. However, the report needs to show how students are progressing by course, so we need to group students using course or group codes. This is relatively easy, but most students enrol on more than one course (e.g. multiple A levels, BTEC plus English and/or maths), and we may need to see their progress in each course, which means that many students will appear in the report more than once. As we are using the course as the main way to group the information, students will then appear at different places in the report, making it difficult to see a student’s progress in all areas in a single place in the report. Again, this can be done, but we are starting to make the classic mistake of cramming too much within a single report and we start to see a tension emerging between data at course level and data at individual student level. Furthermore, different courses are assessed and graded using difference scales, so a student might score +10 on an A level and +15 on a BTEC, but the +10 may actually represent more progress than the +15, so a skilled and experienced eye is required to interpret the report effectively. The apparent simplicity of the senior manager’s request is starting to morph into something a little more complex as we examine the detail.
College Structure
Things start to get even more complicated when we introduce the college hierarchy. A Head of Curriculum might see the report described above and wish to see only students in their area. This then creates the danger which I discussed in chapter 2, of many different people in similar roles requesting what is effectively the same report. The college needs staff to work collaboratively to enable a report to be created which serves the purposes of all curriculum managers at a given level, which can be interpreted consistently.
This will also require the data to be joined to a definition of the college’s structure and most colleges are now able to do this quite effectively. However, the connection between a student and their place in the college structure will normally be via the group(s) in which they are taught, as students don’t have a ‘college structure level’ indicator directly against their student ID. This can have implications for the final structure and content of the report as progress will be presented course by course and it can be much more difficult to present a student’s overall progress in all their enrolments, but under the heading of their main course or programme. Hence we end up in the territory of ‘groups within groups’ such as the case with English and maths. As responsibility for progress in English and maths is being increasingly landed in the hands of curriculum managers in students’ ‘home’ subject areas, these managers will then ask for a modified version of our report – where the main courses in their area provide the primary groupings but the data then shows student’s progress in English and maths as well as their main enrolment. Again this is possible to do but is deceptively difficult and its complexity will often depend on the coding conventions which a college follows.
Sometimes we need to divide students up using factors other than the college structure. For example, the Head of Quality might see the report we are discussing here, but want to see the progress of students who are following level 3 BTEC programmes (in all subject areas, for comparative purposes). The difficulty (or possibility) of doing this once again depends on coding conventions which may not be immediately obvious. In some cases, a system such as ProMonitor may already provide a field which allows us to specify students following a certain type of qualification (in ProMonitor this would be the ‘student group type’), but this may not be a perfect match. It might require a skilled technical member of staff with knowledge of MIS and query writing skills to join on another field within the MIS system to define courses of a specific type.
This last example also tells us something important about course coding, namely why so many colleges are tempted to build logic into the way in which they code their courses. For example, a college might think ‘OK, let’s start all our National Diploma course codes with the letters ND, that’ll make reporting on National Diplomas really easy’. Although this may be true in the short term, in the longer run this may not be the case, as we shall see later on.
Course Codes and Names -why somethings so apparently minor is actually so important
Most colleges offer dozens, if not hundreds of different courses. These courses differ by subject, level, awarding body, qualification type and mode of delivery, plus they are also classified by other groupings such as ‘NVQ level’ and ‘subject sector area’ as used by OFSTED. In the past, partly because college management information systems (MIS) were not so extensive, a trend emerged for colleges to build a large degree of logic into their course coding conventions. Many colleges would have course codes which included characters alluding to the subject area plus sometimes a numerical digit to signify the level at which the course was offered. As a generic example, a suite of accountancy courses offered at levels 1, 2, and 3 might have included AC1, AC2 and AC3 respectively within their course codes. If the courses are diplomas we may see an extension to DAC1, DAC2 and DAC3. Further, if the college has 2 campuses, campus X and campus Z, and if the courses are offered at both campuses, we may then end up with XDAC1, XDAC2, XDAC3, YDAC1, YDAC2 and YDAC3. This basic logic is then repeated until a list of course codes is created to cover potentially hundreds of courses, using a logic which can be applied to create new codes for new courses which may be introduced.
However, there are two main problems with this approach:
- It’s fine until something changes – and this being education, things will change. This is a particular problem with using characters to represent ‘course types’ such as diploma in our example above. National Diplomas became Extended Diplomas and are now heading back to becoming National Diplomas again! The same problem applies when using characters to represent the college structure, which changes even more frequently…
- In nearly all cases, this logic isn’t even necessary in the first place, assuming that the college’s main MIS system (where the codes are created and maintained) is fit for purpose and used correctly. This is simply because modern MIS systems contain numerous related fields against the course code which are designed to cater for all these variables, plus a large number of user-defined fields where colleges can specify anything they want to hold about their courses.
Hence the requirement for logic in course codes is much less than might first be imagined. In some cases it’s perfectly acceptable to use a random or continuous sequence of numbers for course codes, as long as all the variables relating to courses are held and properly maintained within other related fields in the MIS system. In some cases course codes may be part random and part logic-based e.g. where it might be difficult to use a field to group courses. This may be the case in grouping course types together at a very high level e.g. where colleges offer study programmes containing different elements. In this case it might be useful to distinguish the ‘umbrella’ programmes from main qualifications and then the tutorial, work experience and English/maths components of the overall programme. In this case it may only be necessary to use one or two digits within a code to separate programmes into their broad constituent areas (and these digits should always appear at the same point of a code e.g. digits 1 and 2, or after a hyphen – to aid the job of report builders in using them in queries).
When I was creating and maintaining a dataset for testing and development purposes I started with a 6 digit code of ‘123456’ and simply counted on from there. I did however add a hyphen and a further two digits, so that I could have 123456-00 as the overall study programme, 123456-01 as the main enrolment, 123456-02 as the tutorial element, 123456-03 as the maths element etc. This helped in that I could group different elements under the same main course code, although in reality these different elements are often given completely different codes of their own. Where this happens, the college can find related fields in the MIS database to represent these differences between courses.
Course Names and Changes to Courses
One area where consistency will be rewarded is in the conventions not for course code, but for course names. As well as for clarity and aesthetic considerations, the course name field will always have to be completed, so it may as well be completed in a consistent way which may prove useful. The course name will often appear in reports and in some cases may be useful in filtering reports. For example we may have a logic that course names should always be constructed thus:
Awarding Body – Course Level – Course Type – Subject Area (Specialism) – Year of Study
Hence the first year if a BTEC National Diploma in Engineering would read:
BTEC Level 3 National Diploma in Engineering (Mechanical) Year 1
This convention may provide a very quick and easy way of generating reports on e.g. all National Diploma students regardless of subject area, simply by using *National Diploma* in a query. This does of course depend on precision in data entry when the course names are entered and we must always be mindful of the potential dangers of querying and reporting on free text fields.
The added advantage of having a random course code but a logical course name is when things inevitably change over time. One of the challenges of the ever-changing landscape of UK qualifications is the requirement to report on performance over time at a course or college level, but using courses which can be meaningfully compared. For example over a 3 year period, one vocational qualification may replace another and become its new equivalent. In this case the course code could be left static from one year to the next in order to allow easy comparisons in reports, while the names may be re-written using the logic described above, to allow consistent comparisons within a given year.
Summary
This article has turned out longer than planned, as this is a topic rich with detail once you scratch the surface. Many readers may have many years’ experience in data and/or MIS and may have thoughts and comments to add to this debate – please feel free to contact me if so.
My next article will be released in the autumn and will be about that all important first half term for the new student intake.
Leave a Reply