Artful Estimation

In the corporate world it's hard to get any significant work assigned to you unless you can arrive at the correct mix of accurate and acceptable estimations.

The method that works best for estimating depends to a great extent on the size and scope of what you are developing. Not that surprisingly the magnitude of error in your estimation also increases in parallel to the size of the project. Small projects such as one shot utility programs are best estimated by your gut feeling from experience. Such tasks rarely last more than a couple of man days.

Adding a bit of functionality to an existing system can be adequately estimated by breaking the project into component estimates. Say one day for database design, a day for user interface, a day for testing, tweaking, and modifications. More or less depending on your development environment.

If you are fortunate enough to be developing a middle sized complete system from scratch, then you can use a standard project management tool, fill out tasks and estimates, then resource leveling, addition of slack, and then add an additional 15% for each resource assigned to the project.

Somewhat counter intuitively estimation for exceedingly large projects works better if you don't go through the effort of summing up the cost of individual component tasks. Very large projects are dominated by the costs associated with inter personal and inter system communication, plus the overhead of change control. For that reason a tool based on the well researched interplay of these factors, such as Cocomo, gives the best results.

Estimation is an art that you develop mostly from experience. Remember to use the method that is appropriate for the overall size of your project.

Artistic Reality

Sometimes when you are dealing with the high politics of a system that might have major impact on an industry, you may run into a wall of confusing interests. How did the status quo come about, what are all the vested interests, if you change a practice what else might be affected? I find that when I have allowed my hips to be buried in the muck, first I doodle for about fifteen minutes, and then I set myself down and draw a Reality diagram. This is a concise way to describe, on a single sheet of paper, all the psychics impinging on a project. It is comprised of five quick sketches, each a slightly different flavor, describing various elements and relationships surrounding the projects "reality."


The first diagram of Physical space, shows a hypothetical activity that encapsulates a typical event ranging across a variety of actors. Man A stabs man B, who seeks help from doctor C. Okay relax it was an accident. B works at factory D.


The second diagram shows Ethical Space, basically who has spiritual "claims" on others for their actions (or omissions).


The third diagram shows Contractual Space: the understandings, paper, and legal relationships between the parties.


This fourth diagram is more of a list, a high level classification of the types of information each party keeps that are relevant to your system.


The last chart shows Financial space: simply how the money flows between the parties. So now you've got a piece of paper in front of you that succinctly summarizes the entire Reality surrounding your project. Does this solve anything? No. Does this tell you what to do next or make your life any easier? Probably not.

Yet I have found that this diagramming is an invaluable tool, because it shows you why things are the way that they are, the nature of their balance, and the interplay of the forces between them. It frees you from the muck because it shows you the difference between the hard and the soft limits. So unstick yourself: get real!

Artistic Meta

With marching orders and a vague foggy vision of where you are headed, you are ready to create the Meta-Project. Not the project itself, the Meta-Project enwraps the actual project creating an environment for it to succeed. The Meta-Project is more of a thought process, something you keep to yourself, in your heart, to guide you to a successful completion. In an earlier post I described how to resolve the utility-cost-speed triad; this is the other half of the mental preparations required to launch a project.

To start you need to create the tone, the environment under which your project will proceed. Sometimes you will need to be methodical and professional, moving slowly with each step well-documented. You may need to get management reaffirmation and written approval all along the way. At other times you may need to create a blender, a whir of activity that juggles six balls at once. You may need to generate enough excitement that your coworkers get overwhelmed with enthusiasm and complete the project for you. I can not give you guidance as to the appropriate tone for you to succeed in your project -- you need to use your intuition, foresight, and knowledge of the culture at your company to determine what will work in your environment.

I usually find it helpful at this point to sketch out figures of my thoughts. One such drawing is a graph of "risk space" -- along one axis I label Risk, and along the other I label Volatility. I then draw circular regions that indicate representations of where each design option would land. Some projects are risky because they have a high probability of technical failure: this may be due to an increased complexity brought about by the interaction of multiple layers of software, or perhaps because the development language itself presents certain challenges of learning and implementation.

Some projects are risky for political reasons: they might for example shed light on why certain business units of a company are performing poorly, or the software may replace the functions of another system that already keeps several staff members gainfully employed. Some projects may be risky because the goals are ill-defined, or no single person has enough authority to assure completion, or the people in authority are themselves insecure and may not be around at the end of the project for support when you need them.

Volatility is intended as an estimation hedge. The risk for any one implementation may run from low to high: if all the factors are well known then the volatility should be low. On some projects you will get the gut feeling that you are in for a barrel of surprises however, where most of the problems will surface during development or after implementation. In this case the volatility is high. "Type 3" projects tend to be volatile, because you can expect to incorporate new technologies and deal with new staff as the project develops. Some small projects can be surprisingly volatile, not for anything inherent in the design process itself, but because of business uncertainty. If the corporation is undergoing severe changes, then smaller projects tend to get swept under the rugs and scrapped easily.

By preparing yourself thoroughly mentally before a project gets under way you will glide through all of the challenges that it presents.