Project planning and estimating


(Daniel Hollands) #1

One of my long-term goals at Foxsoft is to get better at project planning and estimating.

This is something I’ve always had trouble with, and the couple times I’ve done it professionally while working for Foxsoft have been very stressful and time-consuming while being equally rubbish.

This very week I’m working on something I estimated a month ago. The planning and estimating took an entire day (of non-billed work - although that’s a different issue), and resulted and an estimated week’s worth of work. Five days worth, which I think is going to be closer to seven once I’m actually finished.

Anyway, getting to the point, I’m looking for some help on improving my planning and estimating skills.

Can anyone offer me any sage advice, or maybe point me to some resources which may be helpful?

Thank you.


(Marc Cooper) #2

http://ronjeffries.com/xprog/articles/the-noestimates-movement/

Edit: Links to interesting articles: http://softwaredevelopmenttoday.com/noestimates/

There’s obviously mountains of stuff written about estimating. Almost all of it fiction. Unless a piece of work is tiny, then a single figure is a guess. Even then, it’s still a guess. Hands up who’s had a one-line change that ended up taking a few days? o/

Keeping this super simple, I’d suggest something based along the lines of:

  • provide a range, not a single number
  • list all risks with detailed mitigations
  • detail deliverables and acceptance criteria
  • detail all personnel commitments (particularly availability)

By far the most successful and productive approach I’ve found is simple time-boxing – no planning required, estimate in points/complexity. I’d suggest this is because best value is continually reassessed and appropriate conversations take place close to the work being done. It’s critical to review each timebox (retro), so that everyone learns from what happened – Why did that one-line change take a week? – and that broader organisational plans can react – and folk with budgets can offer help.

In reality, there are so many moving parts and contexts, there’s no answer to you question. Again, my experience is to adapt to the organisation. If you have the authority (if you don’t, level up) it’s often worth changing the organisation too, but that’s probably beyond what you’ve asked. (See this on trust: https://www.stevefenton.co.uk/2014/05/No-Estimates-Anger/)


(Philip Wattis) #3

I speak from my own personal experiences. The difficulty in estimating a job always increased with the lack of detail in the specification, so it’s important to try and separate the two - are you actually spending time on estimating the costs, or are you spending time on fleshing out a poorly drafted specification?

In the past, I’ve charged for producing a specification along with costings, because it’s a piece of work that can then be taken elsewhere and have some other firm complete the job. As an incentive I’ve offered to discount it off the final work. To be clear, the charge has been for producing the specification, not in providing the price estimate.

Similarly, where an estimate has been produced, I’ve ensured I’ve stuck to it, unless the client has caused scope creep, in which case the ramifications are discussed and approved with them. If I’ve made a mistake in the estimate, then I take it on the chin. There is little worse for your reputation than billing a client for more money than they were expecting to pay.

Finally, when estimating, be sure to add contingency. I knew I was quite good at estimating, so worked on 20%, unless I knew something specific about the client. For example, is it the sort of client who can’t make decisions, is unsure about what they want, and changes their mind every 5 minutes, or is it the sort of dream client who knows exactly what they want and can explain it in full detail? 20% allowed for my mistakes, and some scope creep, without the need to create a fuss with the client. I don’t think I’ve ever worked on a job where there was not some scope creep.

Now, you could go one step further, and record internally your actuals against estimates and this may help you refine your estimating to something more accurate for future projects.


(Andy Wootton) #4

Agile is largely about the impossibility of estimating software projects. The only thing your day of estimating guaranteed was that you had a day less to do the work. If you’d spent another day, your estimate MIGHT have been slightly better, or not.


(Marc Cooper) #5

(Marc Cooper) #6

This just turned up in a tweet that @stevejalim retweeted. Seems apropos:


#7

I’ve found this a good guide for explaining the differences Kanban and Scrum, which has helped when approaching project planning for me: https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf


(Daniel Hollands) #8

Thank you for the feedback, everyone. I’ve taken a look at what you’ve linked to, and it seems this is about trying to introduce a culture change in the company, and about how a service is sold to a customer. All of that is great, but what about the customer that wants a fixed price?

In a perfect world, I’m sure the above is possible, but when I’m told by my boss that I need to look at a spec and assign it an hourly value - even if not for the sake of a customer, but simply for our own internal planning purposes - none of the above really helps.


(Andy Wootton) #9

Scrum makes that very easy. Give a fixed price per iteration. The first iteration should be highest value. If they aren’t happy with what they get, stop. The risk is very low - 1 iteration. They buy as many iterations as they feel are still giving value.


(Andy Wootton) #10

There are a number of statements in that document that would really upset some people. I didn’t think it explained Scrum very well. I’d go to The Scrum Guide. Kanban can be either the board, which can be used with Scrum too or the ‘method’. Scrum is only a framework, into which you paint your own process, so it’s often used with XP ‘tools’.


(Dom Barnes) #11

There’s two sides to this: estimating time and how you charge. There’s been a lot of talk of late around charging for value rather than on time. Your iPhone doesn’t cost based on time it takes to create and assemble, it’s costed on value of the output. Who’s to say software dev shouldn’t be charged based on the value it provides. If it takes you 2hrs to make a feature that saves the customer £100,000 a year, there is a big value to what you do for them. Charging £300 for your time isn’t a direct correlation to what you’ve output. Your skills are the sum of your past learning.
But not every client is prepared to work that way. Some are happy to discuss value and you can charge on that matter.

Most of our prior client work has all been based on time equivalent. We estimate it takes T time, we add about 10% extra for managing the project (emails, phone calls, etc) and 10% for general admin. Those amounts should be covering a large portion if not all of the time it’s taken you to obtain the client/work.

If you’re spending 2 days doing a proposal for a 5 day bit of work, you should be charging them for closer to 10 days of time.

We always try and put a relevant amount of effort into a proposal as the job size is. For example today we wrote a proposal to add some new email features for a client. It’s about 4 days work, we spend 2hrs on that. The main project, for that client took about 60 work days, we spent about 5 days of planning on it.

The other think over costs is your rates. People are very cautious about discussing rates but I resent listened to a podcast where they were discussing this, and they basically both said that they just gave a higher figure to the next client each time. People will either accept it or not, and you can negotiate down.

If you haven’t increased your prices in 12 months, do it.

When it comes to the actual time estimations, only experience tells you this. I’m only a fairly junior developer (not my main role) but I’ve done enough to be able to guess time to do tasks, and overseen enough projects to be able to estimate the time we need to do a job.

As a note, most of our current client work is fixed price. Only if it’s a big unknown unknown do we leave it open. And even then we tend to opt for a small paid investigation period, then a full scope and estimate.


(Andy Wootton) #12

I find the idea of value-based pricing very odd. It creates a market where developers want to work for the organisations with the most profitable ideas. How do less creative organisations then get work done?

You may ‘value’ your iPhone highly but are you sure it’s benefit:cost ratio is higher than an alternative? Value has 2 meanings.


(Daniel Hollands) #13

Again, this makes a lot of sense to me, but this is a change required at a company level, not something I’m able to implement myself as ‘just a dev’ with a boss that’s waiting for me to provide an estimate. That’s not to say that I’d not be able to suggest such a thing to my boss for the next project, but for this one, we just wants an estimate.


(Dom Barnes) #14

Luckily the market is full of people at all scales of costs and ability so it fills in the gaps. Not everyone is a £800 per day developer. Not everyone wants to be.


(Andy Wootton) #15

Do you think the rate reflects ability, of the ability to sell yourself like an iPhone?


(Dom Barnes) #16

Partially yes. If you can’t show that you’re confident in your ability to complete the job on time, and to an acceptable standard, you won’t get paid as much. Would any client pay you a higher rate if you seem uncertain if you can deliver their requirements on time?
Your rate should/will reflect a combination of both. A good salesperson can sell you junk at a good price. I’ve heard many anecdotal stories of people telling a customer they can deliver their needs, knowing full well they have no idea how to, and they then go and learn how to. Compared to a skilled developer who has no confidence in communicating may be fully able to do the job, but doesn’t demonstrate that. Its a quadrant diagram (like so many things) where the best is a combination of confidence and ability.


(Andy Wootton) #17

One of the interesting things about working as a contractor was the immediate assumption that you must know what you’re doing. There seems a widespread belief in British businesses that someone from outside must know more about your business than the employees. If they do then someone needs to take a look at the people making the recruitment and training decisions.

Employers take a risk when they hire someone. They are more willing to if they can get rid of you quickly if it doesn’t work out.

The down-side was when I started meeting ‘consultants’ who were paid twice as much as me and knew nothing but how to schmooze their way in then take the credit for other people’s work. We need better educated customers. Luckily, we’ll be getting them soon.


(Daniel Hollands) #18

http://chrismm.com/blog/project-delays-why-software-estimates/?


(Andy Wootton) #19

IME, that’s over-optimistic, as it assumes someonone else knows what’s needed. At best, they know what they think they want but with experience of the software you provide, will change their mind…


(Marc Cooper) #20

“Given that they are just 0.05% through the migration and already 10 times over budget it is unclear when it will be finished”

https://www.linkedin.com/pulse/what-isnt-being-said-canadaca-mike-gifford