January 6, 2006
On Tuesday, January 17th 2006, I’ll be giving this talk at the Boston SPIN. One theme is about what happens when you violate “Rifkin’s Laws” – just one of the dynamics described here (formerly Optimal Friction.com.) If you’d like to come, you can get directions here.
Excess Friction: How Fast Deadlines Can Slow You Down and Ruin Your Life
Description: For those of us in the software field, high-pressure deadlines are a fact of life. In this environment – to build more and more in less and less time – there is a never ending push for higher productivity and faster schedules. However, statistics show that there are, in fact, conditions where harsh deadlines actually cause lower productivity, longer schedules, and high conflict amongst a team – the exact opposite of what we’re trying to achieve.
In this talk, Michael Mah will talk about “the cult of speed” and how overcoming this challenge is critical to the modern-day IT organization. He will address how software managers can more effectively manage the high-tension pressures of work life in the Information Age, while maximizing chances for project success.
December 10, 2005
How to Select a Software Project Estimation Tool
Here’s a follow up to my earlier entry on Stan Rifkin’s wisdom. In Part 1, Stan basically said “Don’t plan beyond what you’re capable of delivering.” This might seem to be pure common sense, and that it is so obvious it’s almost insulting.
But if you consider this fact – projects that meet their deadlines and cost commitments do so by cutting out almost half of what they promise, then it follows to reason that most teams over-commit by a factor of two! Moreover, these overruns are frequently in the millions or tens of millions of dollars. One team that called me in for help in recent times was suffering an overrun of $11 million. When this happens between companies, they sue each other. My friend Ed Yourdon, an intellectual giant in the technology field, is now – almost exclusively – an expert witness for software-related lawsuits.
These things tell me that somewhere along the way, companies drastically lose sight of their estimates. (It’s my belief, as you’ve probably read on this blog, that a major cause is the blinding bias caused by the deadline.) Estimating is very very hard. Often you need a computer to help do it right. If you were to shop for a software project estimation tool, here is what Stan says to look for, in his words:
1) The underlying algorithm is published in the public domain. No surprises. If the duration=effort/resources formula is in the tool, I would reject it. The relationship among duration, effort and resources is not linear.
2) It accurately estimates completed projects. We use a few typical completed projects to see if the tool estimates them accurately in retrospect. If the tool cannot accurately estimate our type of work, we do not want to use it on real, future projects.
3) I don’t want to subjectively “guess” at the values of variables. I only want to work with items that I can objectively measure during the conduct of a project.
4) The assumptions of the tool mirror my realities. Estimates are application-area specific so we need to be sure that the candidate tool has been particularized for my application type.
5) The tool will not generate an impossible schedule. Clearly, there is a region or range of project values (duration, effort, rate of adding people, quality, and number of features) such that it is impossible to accomplish a project with that combination. I want to know that set of values so that I am sure to steer clear.
6) The tool takes into account the effects of schedule compression. In software projects we are commonly asked to produce the minimum duration estimate; i.e. what is the effort required for the stated requirements such that the project will finish in the shortest time? One of the reasons I like tools that model compression is that we are commonly given the delivery date during the commitment process, so I need to be able to ask and answer whether I can stand (manage) the compression in the dictated schedule.
7) I want a range, not a point, estimate and the probability of achieving it. We need to know the probability or risk for each feasible band of estimates. This way, we can adjust our input parameters in order to compute not only an answer about duration, effort, quality, and features, but also a risk level that the organization can tolerate.
December 7, 2005
My good friend Stan Rifkin (formerly a key member of Watts Humphrey’s team at the Carnegie Mellon Software Engineering Institute, and now principal of Master Systems Inc.) once penned the following criteria for software project estimation:
1) Commitments have to be based on work [scope] to be performed; therefore, there must be agreement on this.
2) Estimates have to be based on a) the work to be performed and b) historical records of performance.
3) Commitments must not exceed the capability to perform, or else there is no reason to estimate.
What Stan meant on bullet 1) has to do with the importance of the quantitiy of work products entering a negotiation discussion. The key words are commitment, and agreement. These work products can be number of features or requirements; later on during design they can also be the number of software elements like modules, programs, objects, or new/changed code.
Translating bullet 2) is about knowinging your capability. Most teams don’t keep good records of their most recent projects. It’s not hard to get, and I offer a roadmap in my article “Corporate Alzheimers and Deadline Management“.
Bullet 3) is most important. It means “don’t plan beyond your capacity.” Nearly everyone does it; hence the ever-present statistics on project failures over the years. But what I think Stan means when he uses the phrase, “else there is no reason to estimate”, is that you WILL start what is called a Yourdon Death March project, and you are doomed.
How does this pertain to software estimation tools, you might ask? The answer has to do with keeping these goal-line objectives in mind, and recognizing the importance of calibrating a tool based on your own completed projects, and explicitly solving the issue of software sizing. Easy to use templates should be the order of the day on both items. In the event that you may not have ready access to historical projects, the tool should be able to access records from an up-to-date industry database to get you started.
