views:

212

answers:

7

My company requires that we achieve our estimates to within 30% of forecast. Typically, clients (any my business is no different) expect that they'll get their product as soon as possible for the lowest cost ("I want all the features delivered yesterday for free").

As part of my team's development iterations, we are required to estimate on new features that might have a number of possible approaches. While I would like to explore new and better ways to tackle a given problem, usually it is very hard to justify what might appear as simply playing around to a project manager.

Do you allow for R&D in your development estimate and if so, how to you allocate that time?

Do you explicitly provide for it or do you wrap it up (i.e. obfuscate it) in your overall development time?

+3  A: 

I generally hide it as Design or some form of Requirement Analysis. When I've tried to be honest/explicit about it at my organization, I received all kinds of warning signs from management who seemed to think Research = Unbounded Cost. I can only assume they'd been burned by less scrupulous devs in the past. shrug

Greg D
Yeah, that's a good approach. Spread research costs into other line items.
BobbyShaftoe
Phil.Wheeler
@Phil: I agree. That's why I tried to be explicit about it, initially. I only stopped as a result of some significant negative feedback from mgm't at my particular organization.
Greg D
+2  A: 

Yes of course, that is what you doing most of your time. A manager might think that is playing around but that person wouldn't know what he or she is talking about. Now, with that, you need to be somewhat responsibe. The tighter the budget constraints the less you will have to work with in terms of finding an optimal solution; you may need to stick closer to sub-optimal but known-to-work solutions in those cases. However, if you doing those kinds of deals then the margin there may not be worth doing in the first place. This is just my two cents.

BobbyShaftoe
Ah! Now, you've hit upon an excellent point. "Budget constraints" are very often used as the catch-all excuse for "just build it fast, cheap and plain". No scope to ensure that you're taking the best approach; often no scope to ensure that you're even turning out a high-quality product. Having said that, I agree entirely that there should be an expectation of responsibility.
Phil.Wheeler
A: 

Development you do anyway - and are charging for (I assume).

You have to either budget for research in the overheads, or call it out as an item, or hide it in a vague term like 'requirements analysis'.

Jonathan Leffler
A: 

We add 15% to every task/project over 50 hours for research/learning/optimization.

Does your client / company endorse this approach? Do your clients ever resist incurring that cost?
Phil.Wheeler
A: 

I always include R&D in estimates as I find it a very important piece of software development. Creating a model for an application always includes some sort of research to help familiarize yourself with the problem domain. Also, it is becoming very popular to use third party tools and libraries and there is usually some time needed to ramp up on these. With all that, I easily account 10% of my estimate for R&D.

Mr. Will
+2  A: 

If there's a problem that's going to require a novel solution then you owe it to yourself and your fellow developers, your manager and your client to be explicit about the R&D required to implement this feature.

This means that:

a) you're not padding the schedule for the straightforward features.

b) your manager and client can make a sensible decision about whether this feature is actually worth the effort that's going to be expended in implementing it.

ChrisF
+1  A: 

The majority of our programming work is R&D, so it would be pretty difficult to hide, not to mention disingenuous. I mean, the D stands for development and that's what we do!

Instead, we declare it up front and claim the R&D federal tax credit. This turns the computation on its head: the more work we can report as R&D, the greater our tax savings.

Crashworks

related questions