Timing is Everything

Introduction

When someone walks up to you and asks you "How long will job X take?" or "How much work is it?" the answer is usually spit out too quickly and is probably the closest to guessing as one can get (as opposed to a reasoned estimation). There is also a general complaint that development projects (or IT projects in general) are never on time and are often to always delayed.

It can be frustrating for clients, managers and yourself to be confronted with this, so this is why I wanted to write down my own experience on this topic. There is "some" methodology in the article, but it is not my intention to discuss anything in particular.

Background

I've been around in about every aspect of software development, as developer, analyst, tester, but also as project manager and team leader (or resource manager). In any of those functions, you often get the question how long something will take. I will try to write down my approach or thought process and hope you can use (parts of) it.

About Time

In project management, time has a double meaning and you should make it clear which time you are talking about. Often, the person you talk to is unaware of this issue and that can lead to misunderstandings.

1. Run-Through Time

The first time is the run-through time, the time from date A to date B to complete a task. "The task will be done in 1 month". Meaning that 1 month from now, the task will be done.

2. Work Time

The second time is the work time, the amount of work it will take to complete a task. "The task will take 1 month of development". However, this could mean that if one person is working on it 1 day a week, it will take about 28 to 31 weeks (of run-through time) to complete the job.

See how the underlined statements are almost identical, but can have a completely different meaning ?

To avoid frustration, make sure to clarify which time you are talking about.

Work Time Estimations

As you probably can see in the About time paragraph, if you're asked to make an estimation of how long something will take, you'll need to combine the actual amount of work with the resources you have. Your first job is thus to determine the amount of work, usually expressed in FTEs.

FTE : Full Time Equivalent, this is the amount of work 1 person can do in 1 day (more or less.)

More information can be found here.

To do this, I usually use an FPA type of approach.

FPA: Function Point Analysis. A breakdown of the task to be done as you will.

More information can be found here.

It can be as simple as opening Excel and writing down your estimations for a task, however, here you can delve deeper and try to divide your tasks in smaller tasks, my rule of thumb is that the subtasks should be small enough so you (with your knowledge and experience) are confident that the estimation of work time for that subtask is correct. (Note that you can always ask the "expert" at hand for input on any task) If you already know who will perform the task, it never hurts to get their input.

WBS: Work Breakdown Structure

More information can be found here.

For example: The task is "write a login system for our existing application" which is often the only thing you get unless you yourself start to dig deeper. You cannot make a good estimate based on that sentence alone. Things you can make a better estimation on are: "write database access module" (assuming you know the database), "create login webpage", ... but even smaller tasks are better.

By breaking down the tasks, you can also see many questions rising:

• Do we have a database access module already and can I reuse it?
• Do we need that database access or do they want an SSO system (oAuth eg)?
• What does the login page contain, should it recognize visitors if they come again?
• How will visitors be recognized (cookies, IP, ...) ?
• ...

It's not hard to see that this analysis runs a bit parallel with a good functional analysis (although high level).

But determining your tasks is just part of the job. Keep in mind that estimations are just that: "estimations", "a guess". We want to make that guess as good as possible, as close to what will be reality as we can get.

To increase our chances of guessing correctly, you can add for each task a complexity index. I use an index from 1 to 5.

1. As easy as it can get. E.g., create a database table, is (usually) easy, write to file, create additional textbox on form, ... (multiplier 0,5)
2. Easier than normal, but involves a little more work (multiplier 0,75)
3. Normal complexity, you're confident you can pull it off (multiplier 1)
4. Above normal complexity, you have some idea where to look for a solution, but you'll need some research (multiplier 1,5)
5. Very complex, You barely have an idea how to start or how to get this done, these tasks might even have to be dropped or replaced by an alternative because it might not be possible (multiplier 2)

For each index, you multiply your work estimate with the multiplier in order to get a new work estimate, mostly closer to reality. (I added examples of multipliers, but you can choose your own.)

More often than not, after creating an FPA (in an Excel sheet for example), you start opening your eyes of how wrong your initial thought was. In our example, "create a login page", you probably have a number in your thoughts right of the bat (assuming you know the background a bit), after creating the FPA for a specific task, more often than not, you realize one's tendency to underestimate.

Run-Through Time Estimations

Although an FPA for a large project can already be a daunting task, getting the run-though time can be even more difficult, especially if you have a larger team where people are assigned to multiple projects.

When doing these types of calculations, DO NOT make the mistake of thinking that 1 + 1 = 2!

Concretely:

• if a task's work time is 10 FTE, then 1 person working on it full time will result in 10 days run-through time.
• if a task's work time is 10 FTE, then 2 persons working on it full time will result in about 12 days of run-through time.

This is a very common mistake and also results in a lot of frustration towards managers and clients. The reason why this does not add up as you would immediately expect is because the 2 developers need to work together, they have meetings, they need to sync there work, they need to check, etc... in other words, the more people working together, the more overhead it generates. For 2 developers working together, I add 20% of time (1/5 of the time), for more developers, you'll need to add more, 3 people goes up to 33% or more and 4 people will already have 50% to 60% overhead, but when you do have 3 or 4 people working on the same task, you could start questioning your FPA and double check if you cannot divide the task in better/more subtasks.

It helps if you can divide the work so developers are not in each other's way and each has here/his own scope.

Once you determined who will work on a task, you'll need to check how much of their time they will commit to it, chances are they work part-time or have other projects in parallel. In this situation, you also cannot get away with thinking that 50% allotted time equals a 50% run-through time compared to the work time. For a 10 day work time task at 50%, the run-through time will also result in more likely around 12 days. This is because you need to take in account the "getting into the zone". Imagine you're coding a complex algorithm and suddenly your manager walks in with a basic question ("Hey, are you coming to the meeting tomorrow morning?"). When that happens, you need time to get back on track again. The more you're interrupted, the more "getting into the zone time" you'll add up. Again a form of overhead.

Once you have the right number of people and their availability for the task, cross-check the run-through time with the planned holidays and make sure to add that. If it's a long holiday, allow at least a day of getting back on track (read emails, get back up-to-date with the current status, ...) As a team leader, I asked my team members to plan their long holidays as much as possible well in advance. In addition, it is my belief that any manager should have a maximum of 10 team members to manage. Anything above that will result in loss of overview and bad management. (Of course, it depends a bit on how "close" the manager needs to be to its team members)

So you got up to the point where you made an FPA in detail, you assigned your resources to each task and take in account the amount of time they can spend on the project as well as their holidays. In our simple example, you allotted 14 days run-through time for 10 days of work time for 2 people to work on as they both took 1 day holiday. You go to your manager, present him your detailed analysis and he's happy, you're happy, everybody's happy. One of the sub tasks for this task is "create a database table", so one of the developers writes the script and sends it off to the DBA (DataBase Administrator) who replies with:

"Your request has been accepted and will be implemented no sooner than one week and no later than three weeks, we will inform you when the request has been completed."

F***! (pardon my French, but I'm pretty certain that everyone in this position will react similar).

But unfortunately, you do need to check for each task if there is a dependency on another task OR another person. It could be that you need input from the client, a DBA, another developer or that a certain module needs to be developed first which you'll need in your task. In other words, not all tasks can run in parallel.

Questions to ask when calculating the run-though time

1. How many people will be working on the task?
2. How much of their time will each person spend on the task?
3. Are there holidays planned?
4. Are there dependencies on other tasks or people?

Do NOT tell the client this, but:

When assigning resources to calculate the run-through time, chances are these are for multiple tasks for a longer time. In order to estimate your run-through time even better, do not assign a 100% usable resource as 100%, but rather 90% or even 80%. The other 10% or 20% is a buffer for multiple reasons: having an off-day, being disturbed much because he's known as the expert, having a longer lunch, phone calls, unforeseen meetings, ... You still bill them 100%, mind you, but the run-through time will be more realistic.

Overhead

We already mentioned overhead a few times. I believe it to be one of the major factors in delays in projects. Overhead is the time lost on non-core project time. This could be by synchronizing your work with others, having meetings, but also filling in time sheets, expense notes and other administration.

Waiting for input is also a form of overhead. Sure, your developer probably has sufficient work on other projects and tasks, but that does not speed up your current project. Waiting on somebody (the DBA in example above) or something (a module that needs to be developed first) is difficult to calculate. The best way to do this is by knowing the project and the stakeholders involved. It helps if you personally know the people (and their reputation).

One form of overhead we did not talk about is documentation or better "project management time". In larger companies, this can take large proportions (sometimes taking up more time than actual development). Imagine that the client asks you to change the label of button in an existing application. Let's say the button says "GO" and they want it to be "calculate". There is a huge difference if you need to setup a separate project for this, or if you can take this up into a next release together with a large range of additional changes. When done in a separate project, you need to take in account:

• documentation (functional and technical), if you ever wrote documentation, you know there's always a large portion of nonsense in the documents (juridical blablabla, project scope, list of linked docs, stakeholders, ...)
• development itself
• testing (with documentation)
• release (with documentation)

Counting all this, a simple label change can take up days. Now we will take up the task in a larger scope of a project. You still need to do all of the above, but the overhead of all the documentation, testing, release, ... is now divided over the entire project. Now changing the label of the button is perhaps calculated in half a day or even two hours.

Analysis, Development, Testing

Very often, we only create an FPA for development, but the client is only interested in when he can have the system/project delivered. The best thing to do is to expand your FPA to include analysis (functional and design), testing and release (incl user docs, installation guides, ...), however if you can't (for one reason or another) A good rule of thumb is that you take 1/3 time for analysis, 1/3 for development and 1/3 for testing, meaning you multiply your estimate by three. These numbers are useful because in most cases, if you DID make the complete time estimate to include analysis, development and testing you can verify your estimates. They should count more or less 1/3, 1/3 and 1/3. If not, there is a good reason for that, or you made a mistake. So it's a quick check if you will.

Advice

• Always clarify what time you're talking about (work time or run-through time)
• Never fall in the trap of giving a forced answer. Managers will always try to make things "urgent", but it rarely is. Take your time to analyse things properly.
• Do not let anyone change your estimate based on their "guess". E.g., If you say "the job will be done in six weeks", someone else should not try to overrule your guess "Surely you can do it in three weeks?".
  Besides, you'll look better if you said something will take six weeks and you deliver in three weeks than vice versa.
• An FPA comes in quite handy when you need to make decisions about projects that can have different options like "Should we buy an off-the-shelf product or develop in-house", create an analysis for both and compare. Verify you have the in-house knowledge for either option.
• When doing run-through time type of calculations, DO NOT make the mistake in thinking that 1 + 1 = 2!
  2 developers do not do the job twice as fast.
• Do not assign a 100% available resource for the full 100%, rather take 90% - 80%.
• Make sure to clarify to all stakeholders (clients, managers) that estimations are subject to changes. They are guesses, calculated guesses perhaps, but guesses nonetheless.

Conclusion

Estimating work and run-through time is never an exact science. You base yourself on a variety of input parameters ranging from your own (or someone else's) experience to the availability of resources within and out of your control. These parameters can change from one company to the other or from one project to the other or even across time. When it comes to project management and planning, I believe that good communication makes all the difference. Having a good estimate calculation at hand, helps with that communication.

So in the end, a project can still be delayed or not on time, but at least you have very good information at hand to communicate. In addition, the chances of a large delay decrease with the quality of your estimates.

Thank you for reading, I hope you found it helpful.

History

• Version 1: Article created (February 2^nd, 2018)
• Version 2: Article updated (February 5^th, 2018)