designing ebooks and other fun things

estimate-project-time

Infographic: Estimating Project Time

FacebookTwitterShare

A few weeks ago, during a lively and inspiring #pitstopchat hosted by the lovely Kellie Walker, there was a spontaneous discussion about estimating the time a certain project might take — and how difficult it can be. As I took in the various questions, tips, and ideas, a sort of a jumbled map began to form in my mind. It was then that I had decided that the topic of estimating project time needed some sort of an infographic, or a map.

Of course, since I have never done one of those before, it took me about three times as long as anticipated. (it’ll make sense once you look at it, I promise.) And I am sure that I have missed some important parts, and forgotten some of the ideas and suggestions.

That’s why this is a beta version.

Click to see the full size version

 

But I wanted to post it anyway, because the only way to make this beta better is with YOUR help!

Got any personal experience with estimating tricky project time lines? Tips for others? Thoughts on what else should be included? Or just feedback on whether this makes sense, and how to improve it?

Tell me in the comments!

 

12 Comments on this Post.

  1. I thought you might like to hear Ken’s Law of Project Management which my husband developed during his time as a corporate planner.

    Ken’s Law of Project Management states that any given project will cost twice as much money, take 3 times as long and require 4 times as much effort as anticipated.

    • lisa

      Thanks Anne! That sounds like an excellent guideline — I’d rather overestimate than underestimate. Wonder if I should incorporate the 3x for any “unsure” answer? (Most of the time, my estimates are closer than that, but only if I know exactly what I am doing and have been through the process before.)

  2. Hello Lisa,

    Because my production speed is relatively way slower, I’m a little confused here: at the end of each ‘path’, by the number of hours like in the example: n =X+4 hours, do you intend the number of hours per day, or the whole number of hours for a project? So either I am too slow (which is a fact for now) or either you are super fast to be able to finish a project in one day (which is too, realistic if it is Lisa :)

    Since I’m rather at a practice level with my eventual graphic design service, I rather think of projects by the number of days/weeks rather than hours (that’s why I was confused by the “+4” hours in the infographic.

    And final question (for now): is finishing projects within a day, a standard?

    Thanks for your answer(s) in advance, have a great evening!

    • lisa

      Sorry about the confusion Karim! The number is the total of hours, not hours per day. I am used to thinking in total hours — as probably anyone who has worked in bigger studios/agencies/etc. — and then dividing it by days.

      Because it’s very unlikely that I can dedicate an entire day to just one project ( I generally have anywhere from 5 to 15 of them going at the same time) — this approach makes sense. Also, it was the easiest to apply to all kinds of projects. (Meaning that there are some projects that only take a couple of hours.)

      But let me give you an example to clarify: let’s say someone asks me to do a short ebook. Let’s say they send me the draft, and I can tell it’s going to be about 15-20 pages, plus cover. Because this is the kind of project I have done before, I know that it is going to take me 18 hours total. There are a few stages to this, with rounds of feedback in-between. So 18 is my base number; and I’ll go through the map and end up with a few extra hours as a cushion. (I tend to do that anyway.)

      Days are a whole different story. My total hours for something like this are usually broken into a few stages. So we have 2 hours for initial research/brainstorming, 2 hours to put together a couple of ideas and present a few pages, 8 hours for the actual layout once the idea is approved, 2 hours for the cover, 2 hours for the edits, 2 hours for final files/adaptations/etc. There are checkpoints in-between those stages as well, where it depends on how quickly a client responds.

      So what I do at this point is look at my calendar, and find where I have a block of 2 hours that I can dedicate to the brainstorming (it’s important to me to have uninterrupted hours in those first stages); then allow a day or two of a mental break before continuing. The next two hours are actually putting together the few pages for approval. Then I send it off for feedback before continuing. This might take a few days as well. (in the meantime, of course, I’m working on the rest of those 5-15 projects.) Once I get the approval, I continue. The hours spent on the actual layout can be broken into smaller blocks, even 30-minute one — and I switch between various projects to avoid those numb brain moments.

      As you can see, to me it makes no sense to calculate in days, but rather later go through the calendar and tentatively stick those hours in here and there.
      This might not be the same for everybody, but it’s the only thing that works for me. Basically, the hours thing is just a guideline; how you divide them into days is up to you. But it is a useful skill to be able to estimate total hours. (Time tracking can really help in the beginning if you have no experience with this.)

      Hope this made sense! And if not, just let me know and I will clarify.

  3. Hey Lisa,

    Now everything makes a perfect sense! thank you very much for clarifying it to me :)

    It is true that my lack of experience in graphic desgin project management is the reason why I didn’t see the things like you do, and now I understand very well how you organise the estimated overall hours on your schedules/calendars. I was planning to use Google Calendar (Google Agenda in my french version) in order to organise my work in the near future.

    One thing I should learn from you is working on different projects at the same time: which is not something I am used to yet.

    About the time tracking part: I tried it once, but I was disturbed by the huge amounts of time certain tasks were taking me, especially postponing the work on a graphic element because it didn’t fit in the context as I imagined (now I have much less issues with that part)

    And also, the same time tracking you are talking about is what I included in my improvised “project time management,” I wrote it just before reading/exploring yours, so that I get the most of yours too :)
    I don’t know if I’ll beusing it soon but here’s the plan:

    Project time estimation part I :

    Step1: Devide the project into microscopic essential tasks to do

    Step 2: Estimating the needed time for each small task

    Step X (part of step 2):
    Classifying the tasks depending on their different types:

    – a) Already done before tasks (mastered process/technique) – should be easy to time estimate
    – b) Done in the past but with a complex context that need more mastery/ new processes/techniques
    – c) Never done before tasks but still technically feasable -requiring using new techniques/new tool- (those should be granted an important amout of estimated time)

    Step 3: Taking into account daily relaxing periods of time (in hours,) especially with tasks that are tiring

    Step 4: Taking into account the needed “incubation time,” which is the time for the concept to get even clearer and more precise, with last touches that make really big differences.

    Step 5: Calculating the total estimated time, which should be in hours, then deduce the number of estimated needed number of days (the incubation time can require a number of days)

    That’s it for a first step that I imagined, a Part II would be just time tracking the small tasks in different types of projects and creating a small index, especially for persons like me who are not experienced yet with an important number of projects to manage.

    Wow Lisa 18!!! Yes, three exclamation marks, that’s a huge number of simultaneous projects, that’s crazy, I’m not wondering you are master project/time manager, and your great infographic expresses it.

    Thank you for all your feedback Lisa, it is super interesting, and I know i’ll come back frequently to this infographic to revise it and consider some approaches.

    Have a nice evening! See you soon.

  4. Love this!

    Lisa…. You are a God-send!!!

    • Thanks Kiri! So glad you like it! Was worth waiting for, wasn’t it? ;)
      Oh, and if you have any input to help make this beta better, I’d love to hear it!

      • And then some! I am hoping to give it a thorough investigation by using it on all the things I’ve got on in the next few days (and launch…eek!) so when I do I’ll be sure to let you know how it went :)

        • Can’t wait for you to try it and hear all about it!!!

  5. Great infographic.

    I miss a point where you have to count things in order to get a good estimate. This is the step most IT guys do not think of. If you plan to paint your house you will roughly count the squaremeters of the surface. For IT projects you can count websites, reports, tables, classes or similar.

    I propose to add a decision like “Can you count things for your estimation?” , Divide your initial rough estimate by these things. Is it yet reasonable?.

    • Thanks Jan!

      I admit I have trouble thinking of things to count. (I was using creative design projects as my main starting point, and it can really vary.) So hmm, maybe pages or something like this. Let me think about it and try to work it in. I’ll post a revision when it’s ready.

      Thanks again! If you have other tips, feel free to share.

Comments have been disabled.