Want to avoid getting left holding the bill after a project? Here’s the fastest, easiest way not to end up between your production team and a client in a bad situation.
This is a short little case study about something that happened at JH Media Group recently. A developer sent us a quote on a project and had in one section of that quote a block that just said 109 hours.
Clearly, this wasn’t going to work.
The project manager and I were looking at it together and he said, “Yeah, I don’t know about this,”
I replied “Yeah. No, there’s no way.”
What was wrong?
You should never, ever, ever have a block of 100 or more hours from a developer. We like to break our development time into as little as
If something gets much over that then break it down into even smaller increments.
Why?
The reason for this is because when developers give it a broad stroke on the quote, it’s not going to be right. It’s never right, they’re always forgetting something.
This can apply to designers, developers, writers, anybody doing production work. If they give you a big block of time they’re not thinking about every single thing, unless perhaps they have another document where they’ve broken down every single little thing. But that would be a different story, and definitely not what happened today.
In this particular case, the project manager and I decided to go back to the developer and tell them they had to break down the cost. We need each individual item that they are going to be doing broken down into little pieces.
The project manager and I started going through the process with the scope of work as we had it from the developer and as soon as we started, we realized immediately there were things missing.
What happens in this situation to you?
Had we let this go, the client would come back halfway through the project and point out items that were not discussed or not written out. The client would more than likely ask for items clearly not discussed or partially discussed to be added or added to. It’s reasonable for them. There was nothing saying we wouldn’t do those things, and there are a ton of variables that could clearly use improvement.
Then…
The developer would come back and quote more money to do items requested. Which they would be within their right to do, even though they had poorly planned the project.
So what do you do?
Make everyone write everything out as clearly as possible and quote items granularly. It’s as simple as that.
Don’t let this happen to you. Make sure that when you put together these estimates you break it down into the smallest possible pieces, otherwise it’s going to be a problem.
