Posted on June - 09 - 2009

Software Estimation and Controlled Risk

I’ve written before on the predictive nature of estimation software. Using software estimation products as project management software can help show you aspects of your project which you haven’t accounted for, particularly things like risk.

You can't take that leap back

You can't take that leap back

However, software estimation products can do more than highlight areas which you haven’t seen, they can also peer around the corner and show that which you haven’t done yet. Through the software’s rather developed, and mathematically sound, understanding of your project, that understanding can be leveraged towards making theoretical changes.

Think about it this way, software estimation project management software allows you, the project manager to play the “What if…” game. What if I doubled my workforce? What if I reduced everyone’s workload by 10%? What if deadlines were all extended by 10%? What if I assigned every part of the project to just one person?

The questions can seem trivial, even comical, however they point to a very interesting application for such software – they ability to control, limit, and even potentially mitigate risk. The questions I just posed all center around one significant area – the sharing of a workload to make a project easier on employees.

How does making project members work easier help to control risk? Well, for one thing, for projects which are heavily dependent on multiple deadlines all being satisfied in a particular order, specifically where one group is waiting on the work of another, each deadline represents a potential point of failure. By making deadlines easier to achieve, the risk of failure is thus avoided.

Of course, deadlines represent just one area of risk. I like to use them as an example because hard deadlines seem to exist in every area from newspapers to software companies to automobile manufactures. The flexibility of project management software which employees these estimation techniques means that project managers can juggle all sorts of variables in a project finding the optimal mix. In the end, such juggling helps to control the risk of uncertainty.

Posted on June - 01 - 2009

A Tale of Two Mirrors

This is a blog post by none-other than Dan Galorath, the Chief Architect for the SEER-SEM software. He talks about the difference between the types of project management software and sheds some light on not only the various differences that exist, but also where the two different types of software can be useful.

One of the desired end results of any project is producing a seamless product. Said project could be a company manual, a piece of software, or an automobile, in the end the product should be perceived a single, cohesive entity. The entirety of your project should feel as if it were birthed whole and flawless, crafted with one brush in a single masterstroke. mirror

Reality, however, has you painting a much different picture. Large projects take large groups of people. Large groups of people are broken down into several smaller teams. Even teams themselves can be further divided. Responsibilities trickle down through the ranks and deadlines are attached. Pieces of the project start to rely on each other as deadlines overlap and dependencies are built. A holdup in one team can literally delay an entire project. The larger the project, the more your single masterstroke starts to look a lot more like Chaos.

In an attempt to make things easier, many project managers turn towards some sort of project management software. The logic is fairly simple – obtain a single piece of software which can keep track of all the pieces of a project simultaneously. The ideal piece of software is busy monitoring deadlines and progress while doling out further responsibilities, all the while ensuring the desired end result.

Active Versus Passive Project Management

Problems arise when we think that all project management systems are created equal. The fact is that software systems can be broken down into two primary categories – passive and active. Passive systems reflect exactly what you put into them, in essence telling you what you already know, albeit in an organized and open manner. Active project management systems, often called estimation software, are able to make projections based on various algorithms and complex models. The difference between the two can be rather severe. If passive project management software reflects what you know, like a mirror, than active project management software reflects what you want to know, like a magic mirror.

Both types of software start at the same point, with the users supplying what is currently known. Both types then organize what is known and keep track of it. For large projects this typically takes into account a host of items such as individual employees, individual pieces of a project, and time allotments. Whether using passive or active project management software, the collection of this information creates an important foundation for any project.

The difference between active and passive software comes into play after this foundation is laid. With passive software, the user builds on that foundation, establishing milestones and to-do list items, creating the framework for the entire project based on the manager’s own understanding of his or her employees and their individual skill sets. The duty of then updating that software falls on either the project manager or users further down the pipeline. The software might take some proactive steps, such as emailing those with looming deadlines, but for the most part such project management software relied heavily on users to keep it updated.

With estimation software, however, the program itself starts to bear a fair amount of the management burden. Prime examples of good estimation software are able to calculate project requirements not just on the known quantities such as those involved, but also on the harder to measure areas like project complexity, available technologies, and the immeasurable factor: uncertainty. Active project management software thus builds a more complete idea of a project. From that idea, the software is able to extrapolate a mathematical understanding of a project. This grounding in math creates measurable and comparative results which are more easily justified than obtuse human guesswork.

The active aspect of this type of project management software comes from what the program can tell users about the future. Because of the amount of data implemented as a project’s foundation in these management tools, solid software estimation programs will account for time, effort, quality, and risk. From that, theoretical changes can be made within the software, reflecting the results without having to actually enact them. This grants project managers the ability to play with trial and error solutions without risking real life resources.

The need for project management software obviously differs based on the project at hand. For some projects, particularly those which have repeating and regular deadlines, a passive project manager might be ideal. For projects with multiple parts which are leading towards a single cohesive product, a more active piece of project management software might be in order. In such instances, much will obviously be gained from understanding the exact situation at hand. The determining factor is whether you want your resources checking in with a mirror which reflects what’s currently known, or if you want a mirror which can help you accomplish your goals by telling you what you don’t yet know.

Posted on April - 20 - 2009

Applying Earned Value Management to Software Intensive Programs

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 »

Posted on September - 05 - 2008

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.