Let's suppose that a manager request an estimate from a technical team. "Manager" in this sense is anyone who wants the estimate. It can be an upper-level manager or an account person or perhaps even the client if you're very cozy with them.
The technical team will look at the requested feature(s) and discuss the effort, risks, and experience levels required to do the work and offer an estimate. The estimate might be in the form of user story points if your team has an established velocity or it could be in days or hours if you have a reasonable work breakdown.
The trend I've noticed is that in response to the estimate, the managers will say something very strange. It'll usually go something like this, "Nope. That's too high." (If it were too low they'd pee their pants and be quiet.) "Too high! What are you talking about?" The manager will then respond with the damnedest comment, "Nope - too high. For us to get the work your estimate needs to be $X number of dollars and finish in Y number of days."
Technical teams are being asked for an estimate where what is wanted is a plan.
I'm sure that this practice is as old as project work itself but now it seems to be happening on every request. In "the olden times" - you know, the 2000s and 1990s - I would get actual requests for an estimate. But now it appears that "estimate" is code for "help me make a plan."
If you ask for an estimate but want a plan, the answers you get are likely to be way off base. Certainly the estimate will not be the plan you were expecting. Most plans include an estimate but they fulfill different goals.
To create a plan you would need to make decisions about many things not included in an estimate. Decisions would need to be made about how constrained you are on time and money. (See: Project Management Triangle )
An estimate is certainly a part of most plans but an estimate is just a piece. But so are resources. So is velocity. So is costs. So is schedule. So are technical risks. So are contracts and promises and client expectations - you know, the SLA.
I think a contributing factor is that a lot of managers still think in terms of command and control. Or perhaps there are NDA restrictions or confidentiality concerns if you spread around budget, contract, and timing issues. This does not mitigate the fact that you are seriously hindering your technical teams if you don't share the project constraints when making your request. Command and control gets you what you paid for.
If you find yourself being asked to provide an estimate for someone and you think what they really want is a plan then one technique that can help is to ask about the constraints when you get the request. Ask what's the maximum length they consider reasonable. What's the upper limit on the costs. What's the quickest they expect it to be done. How many people are they thinking of assigning to the project? When can work begin? What are the known deadlines? A lot of times these questions will make it clear from the beginning that a plan is needed, and not just an estimate.
A lot of projects are sold or divvied out with a "wink and a nod." The accounts person is "told" that these features would be great if they get them for $X number of dollars. This dollar amount then becomes the upper limit of the estimate. However, it also makes any estimating effort into a planning effort because now it's not just an estimate of the work that's needed, it's a plan to fit that much work into a known budget. Add to that a scheduling constraint and things can get downright ugly.
Of course, revealing the bid amount, and the estimate, makes the manager uncomfortable. Someone might then calculate profit and know what you're doing. Oh my gosh! It's also very common that the person that comes to the technical team is not privy to this information in the first place.
Many of these conversations go up and down the organization. Once the technical team has given their estimate and it goes up for review, the comments come back down with statements like, "you've got to trim this estimate by 50%" or "you've estimated that this work will be done in October but it needs to be live by the end of August." To which the technical team (at least internally) will say these two things: "if you want the estimate cut in half, then cut half the features" and "why in the hell didn't you tell us about 'end of August' when you asked for the estimate?" The answer is often that those asking didn't have the information.
Of course the efficient organization will minimize these things. If you are really good you can practice lean estimating. But almost all efforts to be more efficient require giving up command and control. So while this trend seems to be accelerating it's worth pointing out that the truly competitive organizations do away with this form of estimating altogether. It still exists because the largest profit margins still exists within the wink and a nod set. The clients have their own budgets and want to control them - costs be damned. So a wink and a nod it is. But this does cause some chaos and encourages command and control thinking.
If you want a plan, ask for a plan. If you want an estimate of the number of resources required to do some work, then ask for an estimate. It's important that you know which you're asking for.
No comments:
Post a Comment