« Corporate Social Responsibility (CSR) And Project Management
Coaching for Project Success »

Project Vision, Requirements, and Estimation

January 12, 2010 | Author: PM Hut | Filed under: Requirements Management, Scheduling

Project Vision, Requirements, and Estimation
By Christopher Butcher

I’ve been thinking about how hard it is to align expectations between business and technical teams for awhile–like, every time someone says “exactly!” or “what were you thinking?!” when my team delivers software.

I’ve been trying to come up with a model that isolates the parts: what the customer envisions, what the customer asks for, and what the technical team estimates. There is a great cartoon circulating that I hope you’ve seen, with a swing seen by different stakeholders…everything from three swings on top of each other to a tire on a rope. My hope is that by isolating the dimensions of vision and requirement, we’ll be better able to manage expectations and risk. Hopefully the visuals will help those visual thinkers show how naturally we end up in different places.

Estimation Circle

Figure 1: Vision and requirements

So here’s how it works: The outer blue circle represents what the business wants. They have come up with a great idea that will help them and they are ready to have something done. The little black dots represent the information they share with the technical team that become requirements. They may be exhaustive and explicit in laying out the vision, but, ultimately, the data points are what are documented and reflected back to the business.

This is where it gets tricky. When the business sees the data points, they impart their vision onto the image and extrapolate from those points to their encompassing vision. To them, the data points mean “they got it!” If you build a system that addresses those points, we’ll be successful.

Meanwhile, the technical team is thinking: “OK. I’ve got four points. That’s a square.” Or what I’m calling the “Vision Gap.” The difference between what a customer is envisioning and what is going to be built for them.

To make matters worse, when the technical team sits down to estimate the development time for the task, they inevitably miss the mark. They can estimate all the tasks they know need to be completed, but inevitably there are challenges that can’t be anticipated. I call this the Estimation Gap. It’s just the difference between what an estimator estimates and what actually needs to happen.

Knowing that there is always that gap, though, teams that perform together consistently can apply metrics from prior projects to arrive at an estimation of the gap between requirements and actual work. I’ve earlier referred to that as “management reserve”. This is time and budget that probably will need to be spent to close the gap between requirements and estimations. All of that, of course, is the responsibility of the technical team. If they get that wrong, they pay for it.

The more problematic side, of course, is the gap between the “circular” customer vision and the “square” set of requirements. There is not much to do about that after the fact, so we have to do a lot more work on expectations up front:

  • Make sure the business knows that it is possible to have many interpretations of the requirements and that there will be refinement along the way.
  • Make sure the business knows that they won’t get anything that isn’t in the requirements. Just because you talked about it in a meeting one time doesn’t mean it’s going to happen. If it’s not written down, it’s not going to happen.
  • Make sure the business has contingency funding of their own so that as vision is clarified, it can grow to meet their vision.

The right side of the diagram shows how we close the gap when we gather more information. More time and effort will yield more data points that align with the customer vision. Tools such as use cases and wire frames provide additional data to close the gap between vision, requirements, and estimations.

It’s not exactly news to say that the more we invest in requirements and design up front, the more aligned we will be. That being said, there are diminishing returns to the requirements and design process. Does everything need to be designed to the most finite level? Absolutely not. In most cases, projects can tolerate differences between vision and execution. Few organizations can afford to analyze problems so thoroughly that there is no variation, and frankly, a lot of the time would be wasted.

What this diagram shows, I hope, is not just that we achieve greater alignment by gathering more data, but that when we choose an arbitrary cut-off point, there will be a gap. As long as we have some sense of the gap and contingency planning to handle it when we confront it, we’ll achieve the right measure of resilience to help us succeed.

I’ve tried another diagram with an oval to illustrate that while circles are nice and symmetrical, the other dynamic in all of this is that the gap between analysis and vision is not going to be uniform. There will be some parts of the vision that can be intuited and others that can’t. We take a risk when we need to intuit. Doing so can yield remarkable efficiencies, but can also lead to unexpected gaps. Knowing the risk, we’ll be in a position to close the gap when we need to.

Estimation Oval

Figure 2: The vision gap with a less consistent vision.

How would you draw your experience with this?

Christopher Butcher is Principal and Chief Technology Officer at Heuristic Solutions, a software consulting firm in Arlington, Virginia. In addition to leading the technical direction at Heuristic Solutions, Mr. Butcher serves as a virtual chief information officer (vCIO) at a variety of organizations. His focus has been on aligning information technology projects to the strategic objectives of organizations. Mr. Butcher maintains a professional blog about information technology governance, the CIO Code.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Tuesday, January 12th, 2010 and is filed under Requirements Management, Scheduling. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories