I don't exactly have a corner office. We just recently moved to a new space and I sit at a window along a row of desks at the western side of the room. Our arrangement along the western side is nice and intimate, and I have the pleasure of being just a couple feet away from a very nice woman who is also our most senior salesperson. Because we sit so close to each other, I've also had the opportunity of listening in on some of her sales calls. This has been both entertaining, exciting, and sometimes totally frightening. Just last week I overheard a call with a potential new client and was not only glad I was sitting down, but happy my lunch had already digested. Here's why:

She said (not exact quotes, but hopefully enough to get the idea), "Yes, we can definitely set you up with a new website, we just completed a project for another client in the same field as yours, took about 8 weeks to turn around so will probably be the same for you."

I cringed, and I thought "What??! How can we make any estimate of schedule when we have absolutely no idea what the project will entail or what technologies we will be using, what specific needs they will have, etc. We aren't even approaching the beginning of the Cone of Uncertainty, so to make any kind of estimate at this stage is complete project suicide!"

Then she said, "We used a new Content Management System (CMS) to integrate the content of our other client's old site to new, and I'm sure we'll be able to help you in the same way."

I glared at her and almost grabbed the phone out of her hand, and thought "Wait!! We don't know enough to make a commitment to this person about using a new CMS for their site! There are still too many unknowns and a good deal of risk associated with using this technology. The best we can do is offer to research the idea and go back to them with an analysis of the benefits and risks of venturing into the project with this new CMS, and make sure it's clear with the impact on schedule and budget would be if we hit any complications."

Then she said "I understand that you're on a tight schedule, we'll corral our people and make sure we can get this out the door by August 1"

My heart skipped a beat as I thought, "How can you make any promises of schedule when you don't know what the availability of our resources are, people's vacation schedules, our key production person is out this week, etc."

Then I realized why I'm not a salesperson. A salesperson has to be a "can do" person all of the time, because she is going to bring in our next deal and she's going to make sure there's plenty of dollars around for my next bonus (that's just a hint there for someone, you know who you are). So, it's her job to raise the energy level and get this potential new client excited about the prospect of working with us, whatever that might mean. And, she's good at it, too. She's brought in a lot of new projects in her time here.

As a project manager, it's my job to make sure the new work that's brought in is done well, on schedule, within budget, and meets the client's needs. Is it possible to reach all of those goals in every project? That's the subject of many other posts, but it's definitely the goal we strive for at Flightpath. But, a project manager also sometimes needs to be a "can't do" person. A PM needs to be a leader and keep the team energized, organized and informed, but also attuned to the reality of the tasks we are undertaking and the risks involved, the uncertainties at each stage of the project and it's affect on schedule, etc. When a project is done well and the client is happy, the saleswoman's job is easier because the client will ask us to do more work.

So, for a minute I imagine what the sales call might go like if I was doing the pitch:

"Well, we did do a somewhat similar project in the past with another client, but without taking a closer look at your site and the technologies that run it, I couldn't even make a ballpark estimate of time that it would take to complete the project. Let me call a meeting with our programmers and look through your site and we'll get back to you in a few days."

"click!"

Ok, so I don't think we're going to get that deal.

The reality is that many times we are challenged with urgent scheduling demands, new technologies that we might not be familiar with or uncertainties of scope, details, etc. The advantage of being at smaller company is that it's possible to shift resources around to get the work done, even when some of the details don't get ironed out until later on. Working with a new technology can be a daunting task sometimes, but can also be very exciting and challenging, and bring us higher up on the escalator of risk.

So, I'm going to continue to do my job and she will continue to do hers. I'll continue to be entertained by her sales calls and know that together we'll keep things busy at Flightpath.

Early in a project, so many of the specific details of the nature of the software being built, specific requirements, project plan and staffing details are all very unclear. Because there are so many variables early on in the project, it is crucial to include a large degree of uncertainty or variability in the project estimate. This is not about being purposely misleading or avoiding commitment to an exact number with your stakeholders, this is about accepting the reality of software projects that leave so much to be defined early on. To commit to an exact number at the very beginning would be misleading yourself and your stakeholders and presenting a false sense of confidence in something that still has so much yet to be defined.

Steve McConnell, CEO and Chief Software Engineer at Construx Software, presents the idea of a “Cone of Uncertainty” in his book “Software Estimation: Demystifying the Black Art (2006)”.

The horizontal axis shows significant project milestones. The vertical axis shows the degree of error that has been found in estimates created by skilled estimators at various points in the project. What is obvious from the diagram is that estimates created early on in the project are subject to a high degree of error (from .25x lower to 4x higher). As the details of the project become defined and understood, the cone narrows. Obviously the most accurate estimate is made at the very end of the project development, but the challenge in the software world is to find somewhere in between where we know enough about the project to make the best estimate possible while still allowing major stakeholders to plan financially. More about the Cone of Uncertainty, and other estimation resources can be found here:
http://www.construx.com/Page.aspx?hid=1648

In his book Steve McConnell explains several different techniques used in making software estimates. He also made a very interesting and entertaining blog post recently, where he shared similarities between building a fort in his backyard and problems people run into with software estimates. The general idea here, and very humorously explained, is that in the beginning of a project it’s easy for us to assume that everything will go as planned and the project will proceed smoothly and in a timely manner, but it’s very common for things to take longer than expected. In his case, it was the little construction project in his backyard.

I haven’t built any forts lately, but I’ve managed many projects at Flightpath, and some that have taken longer than the original estimate, for one reason or another. But I also see this concept clearly illustrated in my day to day life outside of Flightpath. I find that it’s almost impossible to make any type of time or schedule commitment when a toddler is involved. I’m fortunate to be the mother (or project manager) of two little girls, and have the pleasure of bringing the older one to preschool every morning. What should take only 15 minutes, can sometimes take up to 40…and this is why:

1. The 2nd and 3rd bowl of cereal (6 mins)
2. Trip to the potty before leaving home, which can sometimes include the mandatory reading of the Dr. Seuss book while waiting for the potty business to complete. (8 mins)
3. Sneakers that get taken off and put back on again, only to get taken off one more time (and of course put back on again) before the final trip out the door. (2 mins)
4. Unexpected meltdown about which jacket to wear, and wanting to wear rain boots and bring umbrella on a perfectly sunny day. (6 mins)

You catch my drift…

So, I’m learning more about how to properly include uncertainty in my estimates at the appropriate times in the project development, both in the projects I manage at Flightpath and the mini-projects I manage at home every morning. It’s a good thing that our preschool allows us a 30 minute window for morning dropping off!