Posted on April - 21 - 2011

Yes, but what IS it?

For some, the cocktail question is easy. Lawyers only need to specify their field. Doctors, construction workers, and teachers can all clearly explain exactly what they do in a just a few words, saving the listener from having their eyes glaze over in confusion. However, when you work in software estimation, the answer to the question “Oh, what do you do?” is a little more difficult than most.

Ah, the cocktail question

Ah, the cocktail question

The difficulty lies in two prime areas. The first is that even now as people are moving more and more of their lives online, software estimation still isn’t used in a lot of jobs. The idea itself is slowly starting to take off, but to put it one way I’ve actually heard a coworker say “If you need [software estimation] then you already know what it is. If you don’t know, then you probably don’t need it.” Granted, my coworker’s view was a bit cynical, software estimation is a growing field – Apple’s new iTunes Genius is a very simple version of software estimation – but he does have more than hint of truth in his statement. Software estimation is used to make decisions that are relatively complicated, and those decisions are usually reserved for larger companies for which risks are to be avoided if at all possible.

How complicated? Well, Microsoft’s book on software estimation refers to it as a “black art” which is a bit of a harsh misnomer that casts software estimation as perhaps something that is evil. I can assure you, software estimation is anything but. The term “art” is kind of an interesting fit for just what software estimation does – as no two products use the same process to get the same results.

And of course, none of these actually do explain what software estimation is, or what it does. To put it simply – software estimation is process that takes all these disparate pieces of data, pours them all into a pot, and then predicts the future. Of course, that’s not what I tell people. No, I tell them it’s that I work with fact-based crystal balls. That always seems to go over better.

Posted on April - 16 - 2011

Software Sizing, Software and Risk Management Book

Software Sizing, Software and Risk Management

Software Sizing, Estimation, and Risk Management is a practical, hands-on discussion of the software estimation, planning and control process. It addresses critical factors that affect estimates, methods for selecting and applying appropriate measures to projects, proper software sizing, processes to identify and manage risk, and best practices to avoid problems and develop successful project plans.

Authors Galorath and Evans draw on their expertise in sizing, estimation, process engineering and risk management to illuminate issues that make many estimates crumble.

The book offers insights not readily available elsewhere, enabling readers to recognize and avoid software project failures caused by poor estimates.

About Software Sizing, Software Estimation, and Risk Management:

“Shows how to use your estimation and project tracking data to improve your estimation accuracy and identify best investments for improving your software productivity and cycle time. Investing in acquiring this book and following its advice is highly likely to provide you with a robust return on your investment.”

Dr. Barry Boehm
Director of the Center for Software Engineering
University of Southern California (USC)

Order from Auerbach Publications and receive a 15% discount.
(Use promo code 682CC when you place your order.)

You can find out more about Galorath and their estimating software tools.

Posted on April - 16 - 2011

Misunderstanding Risk in Cost Estimates in Software Development

Total Cost of Ownership (TCO) has been popularized by Gartner for estimating all of the costs, both direct and indirect, which go into a project. Managing a software development and implementation project is exceptionally difficult: estimating initial costs is hard enough, but how do you accurately estimate the cost of software maintenance or the burden placed upon IT infrastructure and support? 

Many software projects result in total or partial project failure, indeed it can be said that many projects are planned to fail. Inaccurate initial cost assessments are compounded by increased uncertainty and misunderstanding over software maintenance and the true costs associated with support and operation. There is a serious risk of failing to understand the true project requirements combined with failing to adequately plan the project, which contributes to a loss of control once work commences.

In particular, there is a failure to appreciate the impact of two key variables – time for development and the true effort required. Frequently, estimates are produced using judgment and prior experience; however there is inherent failure built into a project at the planning stage when these two factors are not reassessed as the project takes shape. Project scope and size will change over time in the initial design and development phases; however, project size plays a key role in determining the amount of time and effort required. What is needed is a structured ability bound the uncertainty in early estimates then to make reiterations of the project parameters, especially project size, so that the key estimates of time and effort required are revised in line with project needs and deliverables.

The last twenty years have seen significant developments addressing the issue of estimation viability. To an extent, this has contributed to a false sense of security in initial estimates without understanding the underlying constraints on using them. It is fallacious to believe that uncertainty with estimation has been removed from the project management equation and in some instances, estimation tools are used in a subjective fashion to justify a course of action which is simply not warranted by the facts. A fundamental mistake which becomes all too apparent as a software project goes off track, over budget or fails to deliver the promised benefits.

It is imperative that managers understand that estimates add risk and uncertainty are part of the estimates themselves. In addition, there is a need for reiteration of estimates when the project changes or when more is known regarding the underlying assumptions. There is for manual estimation methods to underestimate software projects due to the misunderstanding of critical project inputs and functionality of the finished project, but even where these are well-understood, there is and will always be a fundamental attachment of some degree of uncertainty, i.e. risk.