Software Estimation BlogInformation on Cost Estimation & Software Estimating

By Robert P Hunt (Galorath Incorporated), Paul J. Solomon (Performance-Based Earned Value), and Dan Galorath (Galorath Incorporated)

Often, traditional earned value approaches do not deal sufficiently with the idiosyncrasies of software intensive programs.  However, successful management of software intensive programs can be achieved by focusing on establishing the requirements, developing a reliable baseline estimate for cost and schedule, selecting effective software metrics, applying Performance-Based Earned Value® (PBEV), and using analytic processes to project cost and schedule based on actual performance.

Introduction

The Department of Defense estimates that software now accounts for 40% of all research, development, test and evaluation (RDT&E) spending[i].  Software intensive projects that achieve their original cost and schedule projections are rare.  Many information technology projects have been declared a disaster area by commercial and government managers.  These projects have been too costly, too late, and often don’t work right.  Applying appropriate technical and management techniques can significantly improve the current situation.

Inaccurate estimates can threaten project success causing poor project implementations, shortcutting critical processes, and emergency staffing to recover schedule.   The lack of well defined project requirements and specifications may result in significant growth in cost and schedule.   Symptoms of this growth may include constantly changing project goals, frustration, customer dissatisfaction, cost overruns, missed schedules, and the failure of a project to meet its objectives.

PMI published an analysis of several government defense and intelligence agency large-scale acquisition programs that experienced significant cost and schedule growth.  This analysis shows that several critical factors need to be addressed in the pre-acquisition phase of the acquisition cycle.  The principal causes of growth on these large-scale programs can be traced to several causes related to overzealous advocacy, immature technology, lack of corporate technology roadmaps, requirements instability, ineffective acquisition strategy, unrealistic program baselines, inadequate systems engineering, and work-force issues.[ii] This paper will discuss some key elements associated with:

• Establishing a process for requirements definition and developing the cost and schedule baseline
• Developing a reliable cost and schedule baseline,
• Identifying critical software management metrics,
• Applying Performance-Based Earned Value (PBEV), and
• Using an analytic process (such as SEER Control;) to project cost and schedule based on actual performance.

Read the rest of this entry »

Packaged Applications – The Hidden Costs of Snake-Oil

By David DeWitt

Most of us remember the dubious “doctor” in Huckleberry Finn who proclaims to have the cure for any malady.  From the back of the crowd his shill would loudly proclaim that he himself had been healed by the magical elixir.   Oh my, but the quantity of snake oil they sold before the townsfolk discovered they had been duped – and the doctor long gone.   From the tone of many internet blogs it seems the same buyer’s remorse is lingering in the “Packaged Application” world.

Before we get into the discussion of packaged applications let’s take a step back and remember how these wonder cures manifested.   In the late 1980’s – (when disco was dying) manufacturing companies wanted to shape supply chain management and enterprise resource planning.  In short, they wanted to encourage the concept of a “process in a box.” (my quotes).  Somehow over the last ten years the industry has forgotten that part about the need for the organizational “process” to change; and as we shall see, that is a key cause of hidden costs.

To belabor the point of “snake oil” for just a moment longer – what exactly is a packaged application?

1.       You can’t see the ingredients (What is the quality of the code?)

2.       You don’t know the recipe (How was it developed?)

3.       You don’t know how it’s to be served (Is it designed for my architecture?)

4.       When done – you hope it won’t upset your stomach (Will it run on or corrupt my databases?)

But it heals the sick and will bring peace and joy to the world … if it’s configured just right!

The top ten hidden costs are – in no specific order:

Read the rest of this entry »

Keeping up with the idea that we’re doing software estimating to create a software package, let’s go ahead and give a long look at our intended project. The first question you’re going to have to ask yourself is how big is this project going to be?

If this is code, how much is necessary? How much can be recycled?

If you’re writing new software, one of the key determining factors for all other estimates is going to be the sheer size of the project as measured in Source Lines of Code (SLOC). This sounds like an obvious place to start, but whether your under the influence of inspiration or the crush of deadlines, a project can easily bloat out of control.

Though you’re likely going to want to restrain your SLOC to the lowest number of lines possible, you’re going to want to give yourself a cushion in your initial SLOC estimate. One popular estimation method is to draw up three numbers, the least possible number of lines, the probable or likely number, and the outside largest number.

Once you know the likely sizes of your project, you can then start to whittle down the involved labor. Is there Commercial-off-the-shelf  (COTS) software that can be incorporated to help achieve the desired solution? Have you developed prior pieces of code, modules that can be incorporated? These pre-existing solutions will have an impact on your SLOC, but also the cost and time of the project, proving that while SLOC might grow or contract, the relationship between SLOC and the total cost of the software is not a solely dependent relationship.

Coming up with these answers ahead of time helps to prepare the overall software estimate by providing a more complete picture of the desired project. Understanding the source before you start it, and determining the best courses of action regarding COTS, FOSS, and pre-existing code solutions is a good method for creating shortcuts and cost savings well ahead of when they’ll actually be needed. Doing so is a lot like plotting a vacation on a map before you start the trip. Even though you have never been where you’re going, you’ll have a fleshed out idea of where you’re going, how long the trip is going to take, and whether anyone has been nice enough to already build bridges for you.

And, once you have that knowledge, you’re much better suited to answer the proverbial question, “Are we there yet?”