This article was written in response to a question from a 3rd year Computer Science student and it uses terms familiar to that domain. However the principles it puts forward are generally applicable and should be useful to any reader.

What is “work”?

“Work” is a verb, it doing something to create a Deliverable and it is measured in hours. The act of working is often valuable to worker, for example, the coder feels “in the zone” while writing code or a painter may enjoy the act of painting. However in most cases the act of working is not valuable to others, they are only interested in the Deliverable, the thing that is produced by the work.

When Consumers (and their proxy, Management) are valuing our work they do so by assessing our Deliverable. Do they find the code useful? Do they enjoy the painting? Does car built in Detroit work well? There are many that argue to assess a Deliverable only by its utility is morally wrong but let us proceed on that the basis that is what most consumers actually do.

From this discussion we can see that “work” is a bad thing for the consumer. It is a cost, what consumers want is Deliverable without cost; a cheaper loaf of bread, a better car for the same money. To the reader this idea may seem discordant. They have just spent several years learning how to do skilled work and I am telling them that it is a bad thing.

However it is only a bad thing for the Consumer, for the Worker it is a source of income and Workers who produce more value should be able to capture more income.

So how do we minimise work while maximising the creation of value?

How to make a Deliverable

There are three types of work and they should be done in the correct order,

1. Planning
2. Doing
3. Checking

Most inexperienced workers will mix these up or miss out a step in their enthusiasm to get started.

• Ready! Fire! Aim!

For example, they might write an essay (Doing) without Planning it, or forget to Check it against the brief when they have finished it.

The most skilled workers who produce the highest value Deliverables are those who can achieve the correct balance of these three types of work for the particular problem they face. Often it takes about 3 years experience to be able to achieve this in your own work and a couple more to understand it in the context of a team. This is why many people are promoted to team leader roles in their late twenties.

In general the larger the endeavour the greater proportion of the time will be spent on Planning and Checking. Compare building a kennel (dog house) to building a sky-scraper; in the first case there is little needed for planning and checking, in the second it is fundamental to the success of the project.

How to Plan a single Deliverable

Planning is the step that contributes most the success of your work – there is no point running if you are going in the wrong direction.

Fortunately planning is formulaic task that is easily learnt

1. Read (or create the brief).
   1. Print it out and keep it to hand for reference while you are Doing the work.
2. Breakdown the Deliverable into Features that can be prioritised.
   1. I use a Mind Map for this purpose, either drawn by hand or entered into the Freemind software.
   2. You may wish to use the MoSCoW prioritisation scheme discussed later
3. Estimate the work required to produce each feature in hours.
   1. Just guess, your estimates will get better with time
4. Create documentation to support Checking
   1. (this is described below.)

for a big report this might take 1 hour but often it can be less than this.

How to Do

Your planning has given you a very clear idea of what you have to do and how long it will take. You should know which are the riskiest bits and in general you should do these first so you get them out of the way and relax. Take a break every so often (20 mins to an hour) to make sure you are still on track.

Of particular interest to software developers is the Pomodoro technique. Allow 20 mins to crack a difficult problem. If you have not done it. Stop! Go for a walk, reformulate the problem. Try again. If you can’t solve a problem in 3 Pomodoro then you doing something wrong. Stop and get help. There are two sources of help, a peer or a fresher, smarter version of yourself the next day. If you are working in a team then use your peer – that’s what working in a team is for. If you are on your own, come back to the problem tomorrow.

How to Check

The success of the Checking process is dependant on the quality of the definition in the planning phase. In general you will create a Checklist with Pass/Fail criteria during the planning stage. This check list must have these sections,

• Location – where is the work product stored?
• Format – what is it?
• Maker – who will make it (they must have the correct skills)?
• Review – who will check it other than the maker?
• Acceptance – how will we know that it is done?

For example for a report you might have,

• Location
  • Stored in my OneDrive for submission to University using account xxx, on date xxx
• Format
  •  Structure
    • Introduction (100 words)
    • Findings and Discussion (300 words)
    • Diagram with caption
    • Conclusion (100 words)
  • Spelling and grammar
    • Microsoft Word shows no issues when set to UK spelling and grammar
• Maker
  • Me
• Review
  • My mate Bill has read it and says it makes sense
• Acceptance
  • Me!

For a software feature you might have

• Location
  • Successfully merged into the Development branch
• Maker
  • Harry
•  Format
  • C#
  • Each class has Java Doc
• Review
  • The code has been peer-reviewed (Bill)
• Acceptance
  • During the show and tell at the team Sprint Review Meeting

 How to Plan a Project

What is a project?

A project is any extended piece of work that has a beginning, middle and end and contains many deliverables. Examples include, a revision timetable and building a video game.

So far we have considered just one deliverable but a project will contain many Deliverables and together these comprise its Scope.

Understanding project management

It is much more difficult to make many related deliverables than a single deliverable. Project Managers have found that there is a strong relationship between Scope, Time, Resources and Quality. It is often said “You can have it good, cheap or quick – chose two”.

This relationship is shown in the ElephantPM project triangle. If you increase the size of the elephant (Features) then you must make one of the sides of the triangle longer.

• Time – spend longer Doing and Checking the extra features
• Resources – apply more developers to the task
• Defects – don’t bother testing new features because you have run out of time

Ideally every project team would have a full time professional project manager who has managed many projects and can manage these trade offs and other aspects of project management. However in the real world teams often have to be self-managing. To help them cope with complexity we make some simplifying assumptions.

Most small projects will have fixed Resources and in software development it is good practice to work at constant quality (~ Defects). Therefore a team on a software project can often only vary Time and Features.

However even this is too hard and to make it even simpler software teams often follow an “Agile” development practice that use time boxes. I will use the Scrum methodology term  for a time box, a “Sprint”.

How we use Sprints

The guiding principle in project management is that problems become simpler when you break them down. The name of my company ElephantPM comes from the school yard joke

• Q. How do you eat an elephant?
• A. You cut it up into small pieces and use a knife and fork.

Following this principle we divide the duration of our project into several shorter sprints. We decide on a fixed length of time for our Sprint, typically a week in small project or a month in a bigger one and commit to completing some of our Features (including Checking!) within each sprint.

With Time, Resources, and Defects now fixed for each sprint it is immediately obvious that the only thing that we can change is the Features.

Each Sprint must contain many features (at least 5). This are all “MoSCoWed”,

• Must – this feature must be completed in the Sprint for it to succeed
• Should – this feature should be completed in the Sprint
• Could – this feature could …
• Would – this feature should …

Each feature should be sufficiently well defined that the number of hours work can be estimated and it can be Checked.

If we have 40 hours work available in the Sprint then perhaps 25 hours should be assigned to Must features, 10 hours to Should and 5 to Could. Teams will often put in a few 20 min Woulds to give developers something to do if they they are blocked on their main tasks.

The order that features are delivered within a sprint will be determined by a variety of logical and resource dependencies. However as far is practical Must features are to be delivered first. This ensures that the sprint will actually succeed because Must will only take 60% (say) of the labour available to the Sprint we have build in success.

Summary

There are now conceptual frameworks that solve the challenges of personal productivity (Getting Things Done) and the management of large projects (PRINCE2 ). Agile development methodologies (e.g. Scrum) are helpful for some software development challenges. In this article I have tailored these practices for the needs of a university student or person in their first job.

If you find this article useful or have any thoughts or criticisms please contribute to the comments.