In this guest post an industry expert will share some tips in order to manage your IA well. Skills in project management are critical for software development so applying a popular approach for your IA will serve you well in future endeavours.
An Introduction
So you've decided to embark on the IB and you are taking a shot at Computer Science 👏 👏. Whether you are starting in Year 12, or in the last leg of the race in Year 13, the IA will definitely be on your mind.
Before we start, it helps to know a bit about the background of the writer of this post, being myself. I have personally not done the IB Computer Science course, but I have been project managing software products for the last 10 years. During this time I collaborated toward their design and development.
The Approach
There are various methodologies for implementing complex software products. You need to pick the right one and I believe that keeping the user at the forefront is key. Ultimately what you program should result in a happy customer! I also feel that this mantra is very evident in the IB approach towards Computer Science, which advocates Design Thinking.
Watch this quick video if you're not familiar.
I would also like to bring in the Agile Methodology, which some of you may have heard of. If not, I suggest you have a quick look at this video.
Agile Software Development is all about visualising work clearly, approaching it in increments, getting feedback, and improving the product based on that feedback thus works well Design Thinking.
This is in contrast to the classic Waterfall method of getting all the requirements first, spending a lot of time trying to build something perfect, and then hoping the client likes it. A more modern approach should save you time, stress and help you gain high grades.
So let's dive in...
Six Tips
1. Think Big Picture
One of the biggest reasons for incomplete projects is unawareness of the actual scope of the work. Avoid this pitfall by getting familiar with what the IA requires. Early on gauge how 'big' the different aspects are because as this will affect how you approach it. To give me a sense of the different criterions and complexity, your teacher has kindly made the timeline and checklists available to me here.
The 5 Criterions in your IA represent the different phases of the Design Thinking Process more or less, followed by an overall evaluation:
Empathy and Problem Definition | Criterion A This is focused on understanding the user need through interactions and defining the problem to be addressed. Also includes awareness of how any solution will be judged mapping to the criteria of success.
Ideation, Prototyping and Test | Criterions B + C This is focused on designing and building the solution and how it evolved through successive interactions with the user. Includes documenting the techniques used in the solution using appropriate diagrams and flows.
Evaluation | Criterions D + E This includes documenting the use of the solution using a video, as well as a general evaluation from the client against the original Criteria of Success.
The Gantt chart below illustrates the above. Each phase tallies to documentation requirements across Criterions A to E
2. Know the Constraints
Understand what is required from your end to get the diploma because it might affect the delivery. Also know what you are working with. Your teacher has informed me of:
Ingenuity and Complexity There is an old document roaming about that describes some complexity guidelines for both SL and HL. Your teacher informed me it does not strictly apply anymore but it makes sense to keep these guidelines handy as you are doing Criterions A and B. You don't want to get to development when you realise that the project might not be complex enough.
Documentation The programmed solution on its own will not satisfy the IA criteria. You will be graded on the number of documents that you produce which must match Criterions A to E. Do not tackle all the documentation at once at the end of the project. Familiarise yourself with the basic checklists here.
Video Presentation Keep in mind that your final deliverable will be demonstrated using a video. Fancy stuff should happen in the background to hit your complexity requirements but you want it to have enough visual appeal and interest.
Word Counts There is a strict 2000 word limit overall but certain criterions have different word counts. Keep short notes in every phase. Fulfilling the word count should not take up too much of your time.
High Pressure Periods School years have certain high stress level periods. This is especially true around exams. Do not plan a lot of IA work during these periods.
3. Diligent with Deadlines using Time-boxing
Your teacher will be setting deadlines for each criterion and you must stick to them. This will be difficult but they can be used to your advantage if you befriend a technique known as time-boxing. If you have 3 days to do a task you will get it done, but you will also likely get the same task done in a day. It's strange, but it's actually a thing called Parkinson's law, which states that...
"...work expands so as to fill the time available for its completion".
So if time can increase and decrease then what is affected? The quality of course, so create a time-box that makes sense for each task. This will also contribute towards your RoT in Criterion B. The image below illustrates time-boxing for a simple scenario of cleaning your room.
4. Adopt the Iterative Approach
Leverage Agile and time-boxing to create iterations for each of the three phases described above. For the high grades your solution should be built in versions whereby each version is improving on the previous through feedback from your user and from your teacher.
The advantage of using iterations is that you reduce risk. After each iteration your work should be good to submit even though it might not get full marks. Like this if plans change and there is less time on your hands, you can adjust. Better submit something of a lower quality but feels complete rather than unfinished work.
For example, let's say that John and Mark are doing the following project for their IA:
John and Mark have 3 months to cover Phase 2 before then finalising their documentation. John and Mark will adopt different approaches:
John will use a traditional approach.
Mark will adopt agile.
John | Mark |
Meticulously plan flowcharts in detail. | Agrees with teacher that each iteration is 3 weeks. In a span of three months he can get guidance 4 times. |
Everything is outlined before any code is written. This takes longer than expected. | In the first iteration he is just roughly sketching out proof of concepts for the most important success criteria. |
Only a week before the deadline does he start coding in a panic. He also needs to write his documentation. | Using teacher feedback he also keeps Sam in the loop and collects evidence of consultation. It turns out that Sam also gave him ideas that he can consider. |
The deadline would be the first time his teacher and client see the program in action. They both have feedback. Sam realised she missed an important success criteria. | In his second iteration he focuses on increasing the quality and implement at least one idea from his teacher and one idea from Sam. |
John does not feel he has enough time to take on feedback on board. He will just include it in the Evaluation. | By the third iteration both teacher and Sam feel that Mark has something good to submit so he can confidently focus on documentation. |
Many students tend to use John's sequential approach because they feel they like immersing themselves and getting it out of the way. This can work well for other school projects but for this IA the iterative approach is the way to go. Like Mark, you should work to get feedback regularly and build your solution in versions. Be sure that you are on the right path and address difficult questions with your teacher. If you adopt Mark's approach and at some point get ill, you will be able to adjust expectations much better.
Now we will apply this thinking to our original phase diagram. I have added in some iterations and matched them to tentative dates. No need to be too prescriptive with our dates. A rough idea is enough.
Take note:
Each phase has an appropriate time-box for the amount of work involved.
You need to start Phase 2 in Year 12 and do some work over your summer recess. Then have some iterations in Year 13.
The number and length of iterations for each phase varies. Phase 1 should be good with around 3 short iterations. Phase 2 may require more iterations that are longer in nature because different challenges lie ahead.
The final phase is there to get feedback on a draft and do minor changes to the documentation. Therefore 2-3 short iterations will suffice.
5. Visualise Your Work on a Board
This is perhaps my favourite tip. Agile makes work more visual and one of the best ways is to use a Kanban board. Pending work is kept in the backlog, and the most pressing work is moved to the 'To do' or 'Up next'. New cards are added whenever new work becomes known, and cards being worked on move to the in progress. Here is a typical Kanban board with some simple columns to show the different stages our work may be in.
This is not mandatory but it definitely makes the process more fun. You should share the board with your teacher and client to get help, quick feedback and most importantly encouragement as work is being done. I have created a sample of what such a board would look like at the beginning of your journey during Phase 1.
And another example using the same board later in the journey, during Phase 2. The cards from the previous phase have moved to the 'Done' column, as cards relevant to Phase 2 are moving from Up Next through Doing, and being reviewed with the teacher and user.
To create the boards I used Trello which allows you to set labels on tasks. These are handy to differentiate and filter. I used labels like Feedback and Programming but you can use any labels you want. Each card can have your short notes, evidence as attachments, checklists, and feedback in the form of comments. Feel free to access the sample here.
6. Plans change and that's OK
This is more a word of advice rather than a tip. We live in a chaotic world, and Computer Science will not be the only subject you tackle. It's good to have a plan but also know that plans can change. Adaptation is actually a very important part of Agile.
You will need to catch up on another subject next term and need to gain time. You can widen your iteration time-boxes slightly to give yourself some space.
If you do not get as far as you wanted in Year 12 or over summer, you can scale down the complexity to get it done in a shorter time-box. It is better to have a full deliverable at 75% than have missing components.
Year 13s it's crunch time!
If you are in Year 13 and for some reason or other you've found yourself behind the tentative schedule outlined by your teacher, this is the section for you! Feeling behind can be a source of great anxiety but it's a situation that can be managed by using the tips outlined in the post you just read. Time-boxing and small iterations are the key aspects that will work in your favour. At the time of writing it is assumed that you are starting out Year 13 having not made any headway on your IA at all (if you have, all the better!).
The first thing we need to do is scale our timeline down to the time we have. In Parkinson's law the work will fit into the time available. You still need to be mindful of the three main phases that differ in difficulty.
Here is a scaled-down timeline of the phases presented earlier, giving priority to Phase 2 because it is the most complex. Phases 1 and 3 are not that difficult so can be scaled down. You must leave enough time for Phase 2.
Have a clear strategy so that you can gain the most marks. Your teacher asked me to make reference to the IA Grading Scheme. This is what I recommend:
A Quick and Effective Phase 1
Two short iterations for Phase 1 can be enough to establish your scenario and problem. There is no programming so it can be fast-tracked with your teacher. Find a problem that is going to be manageable but try to be a bit creative even if you do not quite hit the complexity. Get this done by November.
Functionality over Aesthetics Phase 2
All of December and January should be constant cycling between design and development. Be cautious on the development side and manage your time-boxes well. Keep your documentation notes updated in rough bullet points. It is important to have regular check-ins with teacher and quality meetings with your user. A three week time-box gives you enough space to get something decent done. Try to gain ground as early as possible with a tutorial (don't forget to reference). Communicate programming gaps to your teacher so these may be prioritised. Aim to have a working version of your solution that is ok to submit by early February.
Package It Phase 3
After mid-years you should be gearing up to package your project. Using your previous notes compile the different documents needed for each Criterion. Get each document to a skeleton before perfecting any one document. You should also be thinking about recording the video of your solution. There will be a feeling of relief as things come together. Don't fuss and lock your eyes on the prize, which is to have a complete submission.
Good luck! Do reach out if you have any questions through the comment section.
Comments