Skip to content

01

develop

project plan

what this page is not

  • this is not a prescription how we MUST do things
  • these are not set in stone

what this page is

  • these are suggestions for us to think through
  • this is a basic blueprint for us to adopt and adapt
  • these are very typical stuffs global project deliveries think about

01

Team building

It is important to recognise that we will come from different parts of the world from different cultural backgrounds, we might speak different languages and importantly we will never meet each other physically, which will make throw in more challenges as we collaborate.

So, let us take time to know and understand each other so we can work together successfully.

As part of this step we might want to do some exercises so that:

  • We know each other personally
  • Understand the specialities and skills we bring to the table
  • What are our goals and what we want to achieve – as a team, individually
  • Our ways of working
  • What are important for us as a team
  • What are our expectations from each other
  • What are our strengths/weaknesses as individuals and as a team

02

task backlog

This could be akin to a product backlog where we as a team are trying to brainstorm and identify all the tasks that are needed for the team to deliver the project. There are very high chances that the overall task backlog could overwhelm us. In my view it is extremely critical to do this exercise.

Just like a product backlog, this would be a living document which we would update and prioritise as needed on an ongoing basis.

I will encourage that you breakdown these tasks and internalise them as user stories with similar size or cycle time based on if you use Scrum or Kanban. Let me explain this a bit more, let us assume we have the following tasks:

  • Product research – 5 tasks of size 2 days each
  • User Journey Map development – 4 tasks 2 days each
  • Story mapping – 1 task 2 days
  • Story map updating – 5 tasks 0.5 days each
  • Product development – 50 tasks (user stories)
  • etc
With the above you can already visualise that you have approximately 60 days and how many tasks/user stories are there and can you achieve that as a team. We can start having conversations around these from day zero rather than waiting til late.

03

project horizon

  • Recognise the no of weeks we have to deliver the project. 
  • What deliverables do we have and at what points
  • What are the hard deadlines

04

winning recipe

Didn’t want to call it the winning recipe so as not to confuse us that Step 03 has all the sauces to help us win the prize. But this is more intended to make sure we understand how we will be marked and evaluated. That will help us to focus and prioritise the tasks and the effort we will put against them.

05

tools to use

Let us put together all the tools we might be using during the project, some we know already and some we will discover as we go.

Tool like:

  • Project planning
  • Communication – Chat, Email, Conferencing 
  • Collaboration tools
  • Prototyping
  • Delivery and 

06

visualise what we got

Once we have identified the tasks and have a view of the timelines, we wanna visualise that in some form like this – use any tool we have a basic excel might be the best.

Note: Please don’t mistake this approach with creating a waterfall model of product development. A lot of these tasks that we are visualising are going to be repetitive and I am not encouraging you to create such a fixed project plan. I am only suggesting that as you get on with the semester given that we have 3 months in total, having such a over all plan to capture the most critical deliverables and dates will help you be on-track and chase the target.

07

risks and mitigation

we must cultivate a habit of identifying risks and how to mitigate them. Will be great if we can come up with a typical risk identification template and work through that during delivery.

typical template, I am keeping it as simple as possible.

  • Risk
  • mitigation
  • owner
  • impact

08

trainings we need

It is a good practice and critical to recognise areas that we need to gain further knowledge or expertise on. Whether it is a tool, more about Agile or whatever that might be and account for it.