It’s been one of those projects. I was the one who estimated it, so how can I complain when it takes me the majority of my estimate just to figure out what it is that the specification documents is really trying to tell me to do? How can I push back that it is a change for me to be able to understand the bits and pieces of detail that don’t fit together in any logical fashion? The answer is I cannot. So that is why I have been not posting lately and instead have been working as hard as I can to meet my deadlines, even when it means extra hours that I do not bill to the project.
I have a friend, Avonelle, who is an independent. She has a very different way of dealing with estimates. Instead of giving an estimate to her client and tracking her actual hours versus her estimated time so she can bill hourly, she assigns a “value” to her projects, and bills the “value.” Although she creates an estimate to help her decide what the value should be, the actual number of hours she works is immaterial. She is encouraged to be efficient with her time since her “hourly rate” decreases with every additional hour she has to put into the project. It is still in her best interest to deliver quality solutions to her clients if she wants repeat business, so her client should not suffer for Avonelle’s efficient use of time or cutting of corners.
I wonder if a large consulting company could ever take this approach to billing clients…
Subscribe to:
Post Comments (Atom)
9 comments:
Christopher-
Maybe in my frustration, I was not very clear on my issue. Here I am at my company, and a project is handed over to me. I am handed a spec, and told to lead up the project and get going. I am also handed an estimate. I say "Whoa!!! I had nothing to do with the creation of this estimate, and am not comfortable with the numbers until I review the specification myself and come up with my own estimate." With a short schedule and an already approved budget, this did not go over all too well. I was given the opportunity to re-estimate, however. I had one day.
So I poured over the spec. The specification is 200+ pages long, and was written by a project manager who acted in the capacity of an analyst. A million questions arise in my mind as I write each line item of the estimate. I jot down my questions, and turn my questions into assumptions as my time is dwindling. I carefully document each assumption and go over my estimate and my assumptions with the client project sponsor.
My estimate, by the way, exceeded the original estimate by double. As background, the original estimate was done over 6 months ago before a key accouting system was purchased that changed the project drastically. I also did not have any detail for the original estimate.
Anyway, so there I am with my estimate, which is wrought with assumptions. I know that this is not the ideal way to begin a project, but sometimes you have to deal with what you have. So as I go through this project, I find that like every single other functional spec I have worked off of, there are holes. As I build functionality, I uncover discrepancies that I did not find in my initial one-day review. I uncover outright conflicts in the document. Again, this is not surprise to me as I have encountered the same in every other project I have worked with.
As I go through this process, what comes to my mind again is the realization that whether I am right or wrong, I just have not seen a project where large amounts of time and money have been spent on a planning phase with the result of a plan that is complete and exactly what the client wanted. Here is where I long for my next project, where I am going to lobby strongly to be involved in the upfront client meeting where the requirements are gathered. I am also going to push for an iterative approach with frequent releases of working software from the start instead of a long planning phase. I think it works better to plan a small piece, build the small piece, get feedback on the small piece, and then move on when the client is satisfied with that small piece.
Sorry for the rambling, but your comment sparked my frustration with the whole waterfall process that is so often used in software engineering. I agree with all of the phases in a project, I just disagree with doing each phase alone from start to finish before moving onto the next phase.
Have you ever worked with a large project, lets say with a longer than 6 month requirements gathering phase, where at the end of that phase an estimate was created that ended up being correct without requiring change orders to meet the budget? I am just curious, because I never have. So I am back in the boat where we have an estimate, and we have a change control process. And we have a long list of assumptions that accompany the estimate, which will spawn more change control as the projects unwinds.
--Valerie
So, Christopher...not to back you into a corner, but if you had your druthers, how small would you like projects broken up? A month of requirements gathering, followed by a month of spec writing, followed by development, for example? Or maybe a week of each followed by a release? I am interested to hear what has worked best for you.
--Val
I used to work for a small software house, which was taken over by a large engineering consultancy. In both cases, projects were bid for with a fixed price. The customers almost always chose the cheapest bid, so we had to quote low to get the work, whilst still ensuring that we covered costs, and maybe even made some profit.
The problem often arose when the sales team were preparing the bid. They would chat through with the customer what they wanted, and then chat with techies about how this could be done.
The sales team would work out an estimate of how long the project would take, based on the conversations, and maybe a quick prototype knocked up in a couple of days by a developer.
This was way before a spec was thought about. There may be an "invitation to tender", which would detail what the customer wanted, but the spec was a deliverable, and would be charged for.
There were some successes, but some big failures. One project needed to be finished in a year, and it was a two year project. We had to rush it out with hardly any design, and no testing. The PM actually said not to test the code as we write it - just write the code. It took many, many months after the first site installation before the bug reports finally stopped.
Charging for extras could be a useful gambit. Some features may have been missed in the original requirements, which wouldn't be included in the original cost.
It was frustrating, but in the manufacturing industry, that's just how it is.
Christopher-
Thanks for the link to your conversation. I do agree that each project is different, and what works for one project may not work for another. I also agree with your in generals :)
Can I post a reply on your site? I don't see a spot for doing that.
--Val
Simon-
I feel your pain. I have been involved in projects where the technical staff was brought in after the sales team delivered an estimate and sold the project.
I work for a consulting company, and when we are trying to win business, and our prospective client has a set budget and a (supposedly) fixed set of requirements, we are competing based on price.
Our techinical team has been meeting with our sales staff to attempt to foster more understanding between both teams as far as what we need to do to win business as well as deliver a quality solution and create happy clients.
Anyway, that is another story. But I have been in the same boat that you have been in, and I find it very frustrating to be bound by some else's estimate and as a result, deliver shoddy code that hasn't been tested in order to meet schedule and budget. Often in this situation, I opt to work extra non-billable hours just so I am not embarassed by the quality of my solution.
--Val
Your Blog. It's nice . Here's a subject that may interest you; estimate home value Start Planning estimate home value
Your blog is great If you have a mortgage issue, I'm sure you'd be interested in financing Bad Credit? financing
Your Blog. It's nice . No better time than now to stop best refinance mortgage STOP renting best refinance mortgage
A real enlightening blog. Don't stop now. Here's the secrets a lot of people are searching for; bad credit home mortgage loan Learn about purchasing bad credit home mortgage loan
Post a Comment