|
in reply to Improving Your Ability to Estimate
We do something very similar at my work, except we dont use index cards (in part because my handwriting is atrocious (damn that Palm graphitti!) and because I type much faster than I could ever possibly write).
When we have to estimate a task, we start out with a list of the functionality the client wants. Then we break it down into the tasks we need to take to accomplish that functionality. Then we begin estimating how long things will take.
We then have a few general rules we follow.
- Murphy's Law is always taken into account (for those who don't know, "anything that can go wrong, will go wrong")
No matter what, it is better to estimate for the worst case scenario, then the best case. You can even tell the client this if you want. I find telling this to the client is useful in illustrating how important it is that they meet their deliverables ("it will take a week if you get us the data on time, or two weeks otherwise", etc. etc.)
- Testing, testing, testing.
Our general rule of thumb is x1.5-2 for testing. This includes unit testing, integration testing and final acceptence testing.
We use to just double our estimates to allow for problems/bugs/issues. But the more we adopted TDD, the more we realized that if that time went to writing tests, then the likelihood of those problems/bugs/issues was reduced and overall quality was higher. This also can be brownie points with certain clients, they like to hear you are properly planning time for testing rather then just leaving it till the end (which basically means it won't get tested).
- System administration time.
As a programmer, I never would think about the sys-admin time to accomplish a certain task, because I never saw it as "part of the task". This actually goes for all tasks which you in particular are not responsible for. It helps to know the bigger picture basically.
Once the estimate goes off to the client it is out of your hands. However, this does not mean that everything is written in stone. Proper handling of scope creep is critical. I used to be hesitant and uncomfortable when dealing with clients on scope creep. But I have realized over the years that you get more respect from a client, and get taken advantage of less if you are hard and fast about scope creep. If explained properly, your client will understand and agree, and you can negotiate. If a client is too pushy and want's you to do it for free, then they are clearly trying to take advantage of you, and you need to respond appropriately. Always remember, your clients are not your friends. That is not to say that a particular contact at a client might not become your friend (I have worked with one guy for 3 years now and we are good friends), but when dealing with matters of business, friendship and feelings need to be left at the conference room door.
Another thing I have found is very helpful, is to make sure that client deliverables are on the schedule and those dates are enforced. Many times my estimate has been derailed because they were late, however since compliance was not enforced, my schedule was never changed, and I ended up working nights and weekends.
I say client many times here, but within reason you can substitue "account guy" or "project manager" for client (taking into account the subtleties of office politics of course).
|
Re^2: Improving Your Ability to Estimate
by dws (Chancellor) on Feb 12, 2005 at 17:02 UTC
|
But I have realized over the years that you get more respect from a client, and get taken advantage of less if you are hard and fast about scope creep.
It sounds like you have a good grip on this, so what follows is for folks who don't.
There are several ways to handle scope creep. One is to say NO and wave contracts. Two other ways come out of Agile: Let the customer reprioritize at the beginning of each iteration, before the team estimates the work and establishes a cut-off point. Or, if the customer must make a priority change during an iteration, have a conversation that goes something like this:
"We've estimated the change that you asked for as taking 12 hours. According to the way you and I prioritized the features when we planned this round, that means that features P, D, and Q will fall off the list, unless you're like to designate 12 hours worth of other features to defer. Your call."
A likely counter at first might be
"No, you don't get it. I need the new feature and the old ones. Do it all."
to which a sane response is
"I hear that you want this new feature and everything else
we planned. And to keep the quality level commitment I made to you, I need to avoid overcommitting. If I were to ask the team to go into overtime, quality would suffer, and we'd both be paying the fallout for a long time. Neither of us really want that. So, to do this new feature, which you've said is important, we'll need to choose some other work to defer. Do you want to defer features P, D, and Q, or would you like to choose something else? Your call."
This shows your customer that you're honoring the larger agreement in a way that they can trust. It also prevents them from training you to bend over on command.
As a developer, this probably isn't a conversation you'll have with external customers. Your company probably has people who are much better skilled and practiced at such negotiations. More likely, you'll have a conversation like this with your internal customer (be that your management or product management). In dysfunctional organizations (i.e., in most companies) standing up to them can be very scary. You'll need to gauge how dangerous it is. But the consquences of not standing up with integrity and defending agreements can be very, very bleak.
| [reply] |
|
|
Excellent points. I have one comment to add.
More likely, you'll have a conversation like this with your internal customer (be that your management or product management). In dysfuncitonal organizations (i.e., in most companies) standing up to them can be very scary.
I agree, scary and politically dangerous, although not doing it can be just as dangerous. I want to share a point of view though, which took me many years (and many 80 hour weeks) to realize. In short, you probably have much more power in these situations than you realize.
I have been in many a dysfunctional organization, and 9 times out of 10 by the time the project/product manager gets too you to ask for the new feature, they have already promised it (usually because they were pressured by those above them who have promised it already as well). However here is where you need to realize that while you are the bottom of the food chain, things are not as bleak as they seems. Because what that really means is that in order for your manager to look good, and their manager to look good, etc etc on up the chain, you have to come through. In other words, you have them by the you-know-whats. Now I do not in anyway way advocate abusing this fact, however I do think it can be used (much as they are trying to use your overtime to make themselves look good). This is the time to sit up and tell your superior exactly what dws is advocating, basically "If you want this to work, you need to re-proritize". You need only stand up to your manager and in a calm clear manner explain why this will ultimately come back to haunt them (it is critical to make it about them here, not about you). It is then his/her problem to run it up the chain, but if you give them a lot of good information, reasons, examples cases, what they are asking is a bad idea, they will have plenty of ammunition.
The critical thing here is to not sound like a nay-sayer, do not be bitter, and be sure to site examples of where things went wrong and where things went right in the past. Avoid blame (always a bad idea) and try to be as cold and logical as possible. In the end if your argument is solid, you may make some headway. And if you don't you have said your peace and stood up for yourself, and hopefully things will be better the next time.
And worse case scenario, you get fired, and you go get a job at a porn site ;)
| [reply] |
|
|
"If you want this to work, you need to re-proritize". You need only stand up to your manager and in a calm clear manner explain why this will ultimately come back to haunt them
This also gives you an opportunity to 'refactor' the extent to which FeatureX is really *important* (as opposed to just fluff) ... unless you work for the type who says "I don't care how much it takes, just get it done" ... but that's a whole different realm of dysfunctionalia.
BTW ++ on this whole thread and especially the funniest node I've seen all year.. stvn++
(note: not to make light of folks who work for *whatever* kind of site ... )
| [reply] |
|
|
This is all valid and good advise, but there's another option, too, which should not be overlooked. That is to cut scope creep off at the pass. Hit it as early as possible, before expectations are set and estimates are made. The way to do that is to deeply understand your client (internal or external, whatever) and your client's goals. Don't let someone hand you a spec or a list of feature requirements without understanding what is behind them. This is an incredibly important and worthwhile investment of time.
If you understand what your client is ultimately wanting to achieving, you will see (much of) the scope creep before they do. Also, and perhaps more importantly, if you cannot understand what they ultimately want (not what software or features they want, but what results they want), then there are several potential problems awaiting you. Not the least of which is potential miscommunication and the need for late course correction (which often programmers incorrectly call "scope creep", but is frankly their own misunderstandings coming out late). But perhaps the greatest danger of failing to understand the ultimate needs of your clients is this: If you do not really understand what they ultimately want out of the project, then you don't know whether they really understand what they want. And a client who doesn't really understand why (s)he wants something is one of the surest ways to an unsuccessful project and tons of scope creep.
But definitely not a contradiction to your points, just an addition for the record.
------------
:Wq
Not an editor command: Wq
| [reply]
[d/l] |
|
|
If you understand what your client is ultimately wanting to achieving, you will see (much of) the scope creep before they do.
When you start thinking that you're smarter than your client, and that you can know what they want before they do, you're on very dangerous ground. You may be right much of the time, but when you're wrong you can find yourself down a deep hole.
If you do not really understand what they ultimately want out of the project, then you don't know whether they really understand what they want.
You avoid this trap by showing your client working software at frequent intervals, and by asking "Is this right? Is this what you meant?", letting them clarify, change their minds, let you know about new requirements, or smile and nod. You both gain understanding and trust incrementally.
Scott Ambler has a talk titled Are You Agile, or Are You Fragile that touches on this problem.
| [reply] |
|
|
|
|
|
|
Just as an add-on to this scope-creap discussion ...
I think etcshadow (and tye too) you are right, if you have done all your analysis right, and have been in this business for long enough, you should surely be able too see the scope creap coming. This in no way implies anyone is smarter than the other, just that you have deep battle scars :)
Now one point which has not been touched on here is the politics of scope creep. I work for a small consultancy (we are down to 3 full time and a number of regular freelancers), and we do the majority of our work for one client, with whom we have had a relationship with for almost 10 years (predating the formation of the company actually). Our relationship with them is more along the lines of a partnership, rather than a contractor-contractee relationship. This basically implies much more give and take, since we want long term, not short term business from them.
I have found many times when small-to-medium-small scope creep comes up early in the project (after the coding has started, but before the "point of no return"). It is politically best to let it happen, all the while making sure they know that it is scope creep, and that you are willing to let it happen. The reason I say this is two-fold.
- First, we as developers need to be flexible. In this modern era, users demand flexible and feature-full applications which can not only meet their current needs, but anticipate and meet their future needs. Now, nine times out of ten, that is impossible to do, but the best we can do is be flexible during the early stages, since the "design and discovery" phase is likely not not catch everything. If the client perceives you as being flexible and accomidating (but not just being a doormat), then you are that much more likely to get a call from them for the next project.
- Second, like a squirrel storing up nuts for the winter, it is useful to build up some political clout early on in the project, as you might just need it later on down the road. Again, I do not in any way advodate abusing situations for political gain *. A client which perceives you to be flexible early on, will know that when you are waving your contract and saying "scope creep" later on, it is not because you are stubborn or a nay-sayer. That early flexibility will illustrate your commitment to the success of the project, and give you a platform from which to talk about adjusting priorities.
And of course, if your client is not being reasonable, and are pushing you to "just do it". They are clearly trying to take advantage of you, and you should act appropriately. And no matter how many times they bought you a beer when you were hanging out after work, or how many times you compared stories about your kids over lunch, when it comes to business, they are not and cannot be your friends. Business is business, and that is just how it has to be. If they try to drag friendship into it, then be wary.
* - I spent many a year working in the advertsing business where back-stabbing politics is just how things work, and I absolutely despised it. But, politics are there, they cannot and should not be ignored (even as a contractor, they may not directly affect you, but you need to be aware of their impact on your work).
| [reply] |
|
|
This is all valid and good advise, but there's another option, too, which should not be overlooked. That is to cut scope creep off at the pass.
And when that scope creep comes from a federal bureaucracy regulation which requires you to do whatever a career bureaucrat with full power and no responsibility decides? And that decision changes without warning (and even notice) at rapid and irregular intervals?
Don't get me wrong, I agree with what you say, but when the first step of a process is random ravings of a bureaucratic mind, it's brown trouser time.
--
tbone1, YAPS (Yet Another Perl Schlub)
And remember, if he succeeds, so what.
- Chick McGee
| [reply] |
|
|
