The Iron Triangle, Project Management, and Freelancing
This is Part 2 of a new series about using freelancing well, or being a perfect freelancing client. Read the first part here.
The Iron Triangle is basic Project Management, but it is still relevant because it is not understood. You want something done. You don’t want to spend a lot on it, and you need it done yesterday, and it had better work.
Good luck with that.
Cheap, Fast and Good- pick any two.
For software, the Schedule is the hardest to predict.
Seriously, it always takes longer than it should.
When I estimate, I try to triple my estimate and then increase the unit of measurement (I forget where I learned this rule — let me know in the comments if you’ve heard it before!)
So if I initially think it will take 2 hours, the transformation is:
2 X 3 = 6, and
hours -> days.
Six days is what I tell the client.
Or days to weeks, weeks to months, and if you are asking for something that is going to take months, you really don’t know what you want (but thanks, Lisa, for sticking with me for that whole contract!).
We don’t know how to estimate based on a paragraph you send us over the internet. We don’t even know how to estimate based on an internal requirement when we work at the place.
All the fancy project planning spreadsheets and Gantt charts produced before the work starts are a waste of paper.
But once we are into the project, we can give you surprisingly accurate estimates for the next one or two weeks. Now we’ve seen the beast, we’re fighting in the trenches, we are familiar with the environment. So now you can start to trust our estimates a little more. Maybe not all the way to the end of the project, but we’ll know what will get done in the next 2 weeks to a month.
One common solution to bad estimates is to add more team members partway through the project. In theory, this should speed things up. Unfortunately, software (and most knowledge work) is not like building a house, where the work is well understood, can be scheduled, and can be divided evenly between interchangeable labour units.
In software and other knowledge-based work, adding more people to a team after the project is underway will slow a team down (see The Mythical Man-Month). Sizing the team correctly from the beginning is important, because the learning and the communication has to start early and continue on through the project. The new team members increase the amount of time spent on teaching and coordinating, and by the time they are net contributors to the project (unless the project is huge), it could have been finished already.
But you can’t size the team without a good estimate. Now we’re going in circles!
In this post, I just wanted to express the frustration that clients feel when they fund a project, no matter if it is an internal or external team that does the project work. If you have felt this pain, stick with me, because we are going to go through a bit of work in the next few posts and then come up with a framework that will give you confidence and visibility into project management, even over the internet.
There is hope — but it’s not magic.
Let me know in the comments if you have felt this pain. If there are parts of software construction that are especially frustrating, I can go into painful detail in a further post, so let me know where it hurts!