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 - 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.