If you come from agile background (as I do), you probably feel some resistance when facing the fixed-price scheduling. For an ordering party the term fixed-price often means that not only price is a constant – it’s also the scope and the deadline. If this is the case, this approach is a far cry from a typical agile (time and material) model. The difference is pretty outright and boils down to one principle: you underestimate – you fail.
You have probably learnt the hard way that the process of estimation is specific. It usually depends on the business relationship, your company condition, top management’s whims and your experience. However, I’ve noticed there is a number of helpful practices you can apply while compiling any schedule.
A good and proven practice of a schedule constructing is building a Gantt chart. Actually the Gantt isn’t a goal itself. The strength of this method results from performing subsequent steps. Although the concept is clear and the procedure seems easy, there are a few key points you should bear in mind.
Before you start a thorough analysis of any requirement, hold your horses for a moment and reassure you have outlined ALL necessary, high-level activities that comprise the project scope (e.g. team leadership, testing, deployment, workshops, analysis, documentation etc.). My experience shows that missing such one does more harm than overlooking detailed information in several requirements. You need to turn off the analytical side of your brain and turn on the holistic one. There’s an perfect tool for that – it’s called the mind map. But still it would be great if you could start with kind of a template and then tweak it to meet your context.
The good starting point I use is an MS Project Software Development Plan template. Don’t get scared when you see the waterfall at its finest, the benefit we want to extract here is the general overview of tasks needed to achieve a successful solution.
Ready for science?
- Whatever can go wrong, will. — Murphy’s Law
- Work expands to fill (and often exceed) the time allowed. — Parkinson’s Law
Buffers are must. It’s the only way to get away from Murphy’s Law. However, you need to be careful not to fall victim of Parkinson’s or so-called Student Syndrome. Fortunately, the PM literature provides a plethora of ways to deal with these issues. One of them is called a critical chain. In a nutshell the method proposed by Eliyahu Goldratt comes down to several rules we can pick here:
- eliminate safe buffers from single tasks – minimise Parkinson’s law consequences
- collect buffers into bigger one and put before milestone date – don’t forget Murphy
- deliberately plan not to multi-task – save context-switching time
- start each task as early as possible – avoid http://en.wikipedia.org/wiki/Student_syndrome
I thoroughly recommend reading the book as it presents a comprehensive set of practices for project(s) schedule buffers and resource management.
Another considerable factor that can catch your schedule by surprise is the number of working days. Actually I mean non-working days. Take the following list as an example:
- National holidays in Poland (excluding those that occur at weekends) – 12
- Holidays – 26
- Sick leave (assuming young and healthy team) – 8
- Trainings and company meetings – 10
It sums up to 56 days. Almost 3 working months of out a year for one man! It does influence your deadline and as a result – your costs. So you’d better update the schedules and make sure you figure out how to cover the extra cost. Naturally, if your project is shorter you should calculate the extra cost proportionally. E.g. if it takes 6 months, then holidays to be covered goes as follows: 6m * 26d/12m = 13. Similarly you can find out other AFK parameters.
An efficient developer works up to 6.5h out of contractual 8. The average I measured in one project was 5.5. A good practice is to agree this unit before your team starts estimating.
The other case is that you should not expect the team to work overtime. Otherwise, the aforementioned index will start dropping bit by bit and the technical debts (see below) will start growing.
As it is sometimes impossible to allocate people or even teams in course of project’s run, one might be tempted to take advantage of magic solutions provided by software. My advice here is – do not trust it unless you understand how it works. Your software needs a few assumptions to generate a logical and sensible output.
You might assume a development speed will soar up to the sky after your team has grasped the business domain and has embraced the latest technology bits. From what I’ve experienced this is pretty unlikely. The problem lies in inevitable last minute change requests. These, in turn, lead to ugly (also last minute) hacks that make acceptance tests pass. As the project goes, the number of workarounds becomes a serious risk when it comes to not only the schedule and costs but also people aspects like motivation and team spirit.
With this in mind, I usually analyse several elements that can have influence on buffers:
- project/milestones high-level schedule,
- acceptance process,
- team structure (skills, experience),
- relationship experience/lessons learnt from previous ventures with the client.