|
in reply to Re: Improving Your Ability to Estimate
in thread Improving Your Ability to Estimate
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.
|
Re^3: Improving Your Ability to Estimate
by stvn (Monsignor) on Feb 12, 2005 at 22:30 UTC
|
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] |
Re^3: Improving Your Ability to Estimate
by etcshadow (Priest) on Feb 14, 2005 at 06:29 UTC
|
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] |
|
|
I'm rather shocked at how rarely I see one phase of software development that I was taught: Needs analysis. If I'm working on an important project, I don't just take a spec that is handed to me; I study the needs of the client / customer and analyse them. The needs often start out as a spec. But, in my experience, if the client is savvy enough to get the spec right, then they don't usually go contracting the work out.
Most of the mistakes I've made in contracts is when I've let the client dictate what was to be done without analysing whether that really made sense and pushing back quite hard with what my analysis says should be done. If the client disagrees, then I need to work to find out whether I'm missing part of the picture or the client is.
There can be differences of opinion as to how to do something, and often the client gets to dictate those since they are paying (but sometimes I get to dictate them since I'm the expert being hired and so should know what I'm doing). But if there is a disconnect as to what is needed, then the project is going to go quite badly.
And the most common way I've seen for the needs analysis to be done wrong (other than "not at all") is for the person doing the design to not talk to the ultimate consumers of the proposed work. Talking to the boss who is going to pay you is just the first step. You need to talk to the peons doing the work and see how they really do things and discuss how they'd use what you are considering writing.
So, yes, I usually know what the client needs better than any one of them does once I've taken on a project. I may not know what they want better than they do, but I don't care as much about that so long as the paperwork is clear -- since I've experienced giving them what they want but didn't need and found that to be much worse for all involved than giving them what they need but didn't think they wanted that was also what was spelled out in the contract (which prevents them from easily dismissing the work which gives them time to realize that they did need it -- usually soon after they give it to their peons).
Of course, I make an effort to understand what they want and to explain what they'll be getting. Proper expectations make things go so much more smoothly. But wants are harder to pin down than needs and specifications, so I try harder to make sure the latter line up. You can do a lot to verify needs and specifications but for "wants" you are stuck with how well they can communicate what is in their head.
If I ever ask a client "Is this what you meant?" that's a red flag that I'm nearly driving blind.
| [reply] |
|
|
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.
Well, that's not what I said. You're right: it's dangerous (and basically always wrong, for all intents and purposes) to think that you are smarter than your clients. But that doesn't mean you should assume that they are smarter than you. What I meant to describe was more of a partnership. They are going to know the subject matter better than you. That's basically a given. You are going to know how to develop software better than them. That is also a given.
That's the point, really... if you get into the business of letting your clients design your (as in your and theirs, remember: it's a partnership) software, alone, with you as a passive requirements-to-code translator, that's where the problems start. When saying that you will see the scope creep coming before they do, what I mean is: you have experience developing software, and they don't. If you really understand what the client wants, and you have any experience with similar situations, then this will give you a heads-up to potential issues. Use that forewarning of danger as an opportunity to avoid it. When you encounter those watch-signs, ask questions that the client never bothered to give you the answers for in advance (because they, lacking your experience at software development, will not have thought of all the potential issues).
------------
:Wq
Not an editor command: Wq
| [reply]
[d/l] |
|
|
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] |
|
|
