Posted on June - 19 - 2009

Searching For A Layman’s Explanation of Parametric Modeling

Professor Charlie Eppes, solving crime no doubt

Professor Charlie Eppes, solving crime no doubt

For a few years, CBS has been running a television show called Numb3rs. The premise is the standard take off on the brothers-solving-mysteries cliché that has been around since at least the Hardy Boys. Granted, Numbers has a couple of differences – the boys are older and employed. Don Eppes, the older of the pair, runs a team of FBI agents based in Los Angeles – a fair step above the amateur sleuthing of the Hardy boys. Charlie Eppes, the younger brother, is a math genius and a professor at the fictional “Cal Sci”.

Each week, Don and his street-savvy FBI team encounter a problem, usually a time sensitive one, which is just too tough to figure out through traditional police work. Like clockwork, Professor Charlie Eppes and his team of socially-awkward yet brilliant mathematicians are able to use some form of advanced mathematics to accomplish a whole list of things from predicting where a kidnapping will happen next to the contents of boxes.

And while a great deal of that is Hollywood magic, taking lab theory and shoehorning it into unrealistic time periods with even less realistic amounts of data, there is one part of the show that I always admire. At some point, the young Professor Eppes must explain a complex, doctoral-level mathematical system in terms that team of FBI agents can understand. This happens every single episode with such predictability that the character in the show have started to expect it, even making jokes and attempting to give their own explanations.

Charlie’s explanations are clearly a plot device to convince the audience that his brilliant mathematical insights aren’t simply a weekly deus ex machine. However, just as Charlie has to explain how his math models the real world, the use of software estimation can often seem just as improbable. True, you can sit back and say “Well, the program relies on parametric modeling of our current situation,” but that look is far more likely to generate blank stares than anything else.

To that end, I’m currently working on a good lay definition of parametric modeling and a few handy examples. Stay tuned for those.

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 »