Entries Tagged ‘Budgets’

What tips do you have for estimating/budgeting?

Wednesday, November 2nd, 2011 by Robert Cravotta

Many years ago, during a visit to my doctor, he pointed out to me that I had visited him around the same time each year for the past few years for roughly the same symptoms – which were all stress related. It was at that moment when it finally dawned on me how stressful year-end budgeting activities were on me. It was also the moment when I understood how to focus my energy to minimize the amount of stress that this time of the year had on me by approaching the year-end budgeting activities from a different perspective.

I do not recall who I heard the expression “water off a duck’s back” from, but it probably has been a life saver for getting me successfully through many stressful events, including year-end budgeting. The expression brings images of ducks popping up to the surface of the water after diving under the water to eat. Remarkably, the water all rolls off the duck’s back and they are dry immediately after surfacing. I had a friend who had hair like that, but the expression “water off Paul’s head” is not quite as visually effective.

The stress of needing to take an accurate assessment of my project or department’s current condition coupled with having to project and negotiate for those resources we would need to accomplish our goals for the next planning period was much easier to handle if I could imagine the stress falling off me. Equally important in handling the extra stress of this time of year was realizing which goals were real and which goals were what we called management BHAGs (big hairy-a** goals).

My management at the time thought it was a good idea to purposefully create goals that they knew probably could not be attained in the hope that we might complete a significant portion of them with far fewer resources than we might otherwise expect to need. I’m not convinced that the BHAG approach works if you overuse it. If you have too many of them, or they are just too large of a leap, there is a huge temptation by the team to just write off the goal and internally adopt a more realistic goal anyway.

Going over earlier budgeting proposals and comparing them to what actually happened proved to be a helpful exercise. First, it provides a loose baseline for the new budget proposal. Second, it can provide a mechanism for improving your budgeting accuracy because you might notice a pattern in your budget versus actuals. For example, are the proposed budgets even close to the actuals? Are they too high or too low? Do the budgets/actuals trend in any direction? My experience showed that our tend line was fairly constant year over year, but that allocating a portion of the budget to acquiring and updating tools each year was an important part of keeping that cost line from trending upward as project complexities increased.

Do you know any useful tips to share about how to be more effective at estimating projects and performing planning and budgeting activities? Does any type of tool, including spreadsheets, prove especially useful in tracking past, present, and future projects and actuals? What are the types of information you find most valuable in developing a budget and schedule? How important is having a specific person, skill set, or tool set available to making projections that you can meet?

Which is better: faster- or quality-to-market?

Wednesday, March 23rd, 2011 by Robert Cravotta

There are at least two major schools of thought about the best way to release new products – especially products that contain software that can be updated by the user. The faster-to-market approach pushes designs through the development cycle as quickly as possible to release the new product to market before anyone else. A plausible tactic for faster-to-market products that have user-updatable software is to ship the product even while there are still major bugs in the system with the expectation that the development team can create a corrective software patch before the product actually ends up in the hands of the customer. In this scenario, the expectation is that the user will perform a software update before they can even use the product the first time.

The quality-to-market school of thought believes that products should work out of the box without requiring extra effort from the user such as downloading and applying software patches. This philosophy does not preclude the later use of software updates to add or improve features – rather, the out of the box experience is considered an important part of the product’s value.

An argument for the faster-to-market approach is that the user will be able to start benefiting from the product sooner – possibly months sooner because the development team is able to take advantage of the production lead time to bring the product to the desired level of performance. This argument often presumes that the development team would still be working on fixing bugs after shipping a finished product even under the quality-to-market approach. For this approach, the shorter term tactical advantage of using a capability sooner outweighs the probability that some expected features may not work properly.

Likewise, an argument for the quality-to-market approach is that the user will know for certain at the time of purchase what the product will and will not be able to perform. A presumption of this argument is that sometimes a faster-to-market product overpromises what the development team is able to deliver and this leads to customer dissatisfaction because of unmet expectations. For this approach, the longer term strategic advantage of always being able to use the features as-advertised outweighs the probability that a crippled version of the feature will cause you to lose future sales.

There are many companies that side with both of these schools of thought. Which is better? Is one always better or is there a condition when one approach is better than the other? How does your development cycle accommodate one or both of these approaches to releasing a product?

Do you have enough budget for your embedded project?

Wednesday, March 16th, 2011 by Robert Cravotta

The word on the street is that budgets for development projects have been shrinking for years – perhaps even decades. If this sentiment is true, how do so many embedded designs make it to production status each year? Is the design quality for these projects more compromised each year? If the projects are over budget each year, how do the companies that fund these projects realize a high enough return on investment to keep justifying starting new designs? I question the validity of the claim that budgets have been shrinking year-in and year-out for ever increasingly complex designs without some offset occurring somewhere.

Perhaps a development team has a smaller budget for developers, but is it done without an increase for the development tools? I have been watching the development tool industry for years to see where the big productivity gains are coming from. Most of what I have observed is incremental improvements in what tools can offload from developers. Also, I do believe companies have been slashing their training budgets, but somehow the projects still get done (maybe not optimally but well enough to justify doing the project in the first place).

Another way that projects might get by with smaller development budgets is through heavy reuse of earlier designs and/or licensed IP (intellectual property). A trend that I have seen increasing over the years is that semiconductor companies are providing more software with their silicon products so that development teams can concentrate their efforts on the value add features rather than the basic functions. In this case, the overall budget is not shrinking so much as it is being transferred to different development teams.

I do not expect that development teams have generous budgets. I do expect that the budgets routinely require creative thinking from the team members as to how to squeeze 10 to 20% more out of the budget to meet the project requirements – but that is the process by which continuous improvement occurs – I doubt it would occur any other way. Are your budgets sufficient or are they too tight to complete your projects? What would you change about your budgeting process if you had your way? Is it possible for budgets to shrink every year and still be able to produce ever more complex designs?