2. Tracking progress
2.01 Tracking progress, managing resources and time
How can we track our progress as we go? We need to know where about we are in the process and know what we need to do to complete certain steps.
Our aims and objectives provide a framing for our goals as they give us an opportunity to define things at a high level. However, we have lots of small elements we’re working
on all the time.
We need to ensure all these small elements are tracked against the bigger goals. Moreover, our smaller goals is what we’re really interested in while progress tracking because
we work on small increments to achieve a longer goal.
To track progress, there are many tools that can be used:
- Content Management Systems
- Version Control Systems
- Divide by process
- Divide by projects/deliverables
- Holding regular meetings
- Integrated tools use as VSCode, Trello, Basecamp, Slack (or a combination)
While the specific tool to be used is a free choice, one thing to remember is that failure to plan is planning to fail.
We must be vigilant against feature creep, where the requirements and scope increase over time. We should also consider dependent processes and the impact that certain steps
will have on other moving parts.
2.02 Gantt charts
Gantt charts are a good way to think about a linear breakdown of a project. They include milestones that define important points in a project’s lifetime. Usually, tasks in
Gantt Charts are linked to their relevant resources and dependencies.
A resource could be anything you need, from access to people, to physical equipment such as a camera.
If you are building a website that showcases properties, things like a camera are going to be critical.
Dependencies are things that need to start or finish before other steps can start.
Gantt charts are useful in that they can embed this complex relationship of dependent components and concurrency.
A Gantt Chart can also embed a critical path, which is a route from start to finish that explores the manifestation of a project. A Gantt Chart looks like the table below:
In terms of the critical path, we should consider the project in relation to:
- All the activities necessary to complete the project
- Timescaled steps for each state
- Relationship between states
- Critical endpoints where a certain state must be reached
The critical path is, of course, an estimate. Unexpected events may occur that change the path of the project or prevent completion of a milestone.
One thing we can do, is build a contingency plan in our model, which could mean taking a different approach if something happens that prevents us from completing the original path.
We should also consider adding what’s called Float Time to the critical path. This will help us build robust timelines where variants can occur.
This basically means our activities should be defined, not with a single date for delivery, but with a range of dates.
Ideally, we want to start on a process as soon as we can, so if we complete a task sooner than expected, we can move on to other tasks.
We might want to allocate an individual to track the process to ensure accountability.
2.03 Managing our project
Start out with aims and objectives.
This will enable us to define what we want to achieve and how we intend to go out and achieve them.
How can we ensure our aims and objectives are robust?
They should clearly define what you want to achieve in a given timeframe – a statement of intent.
For general tips for aims and objectives, keep them SMART
- Simple goals – don’t muddy the water with unnecessary complexity
- Metrics – useful for measuring success and failure
- Achievable – you should all agree on an outcome
- Realistic – given time resources and team dynamic
- Timescales – define outcomes more broadly
What are “bad aims”?
– My aim is to build a system like Facebook. (System doesn’t really describe what it’s going to do, it doesn’t describe intentions or actions, we’ve got no idea about what a system might look like, it could be a back-end system. We could be dealing with a database of information and some users and some registration authentication type functionality. We could be dealing with the front-end etc)
– Our aim is to build a game that is entertaining and engaging. (What do we mean by entertainment or engagement? We’ve not set metrics here that allow us to evaluate these things over time. What we’re effectively saying is they have to achieve these things in some given way, but we’ve not described the way in which they’re intended to achieve these things)
– The aim of this project is to find out the best design for any mobile betting app. (This is a problem purely because there probably isn’t a best design. The fact that there are so many different apps out there that do the same thing, they’re designed in different ways, suggests that there are value propositions from each of the different designs in a given context)
What are “better aims”?
– To investigate how information systems are used to produce and to perform music from a user centred perspective. (We’ve got a lot in there, but actually that’s what we want with aims. We want to be very specific. We’re looking at a subgroup of a subgroup of a subgroup here. We’re looking at two particular types of actions; production and performance. We’re looking at the context of music information systems, and we’re also saying we’re looking at this from a user centred perspective)
– To evaluate requirements of musicians against current systems. (Now, this is a fairly easy one to do because it’s a mapping job, you’re looking at the requirements of musicians. You can then write down all the functionality of current systems and you can evaluate this very easily. You can look at two lists effectively and compare them and say, “Well, this system does X, Y and Z, but it doesn’t perform this particular functionality that the musician would like or the musician has to do as part of their job every day.”)
– To provide a framework by which future systems can be developed. (Again, this is one of those things that is quite well defined. So we’re looking at a particular type of framework and we’re looking at how we can develop systems using this framework, and this framework is likely to come from our previous two aims. We’ve already achieved this, if we’ve done the first two things, we can then look at generating a set of requirements, eliciting these requirements, and providing a framework for understanding how to design these systems in context from the knowledge we’ve generated already).
An example of a research method
PRINCE2 stands for (PRojects IN Controlled Environments) is a process-based method for effective project management used by the UK Government, widely recognised and practised in the private sector in the UK and internationally.
Whenever we want to do something, build something, achieve something or go somewhere, we need to answer some questions:
What are we trying to do?
When will we start?
What do we need?
Can we do it alone, or do we need help?
How long will it take?
How much will it cost?
Monday 18 October 2021, 269 views
Next post: 3. Requirements and specification
Previous post: 1. Project management and team working