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.

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. At Heuristic Solutions, we call that the “management reserve,” which I’ve written about elsewhere. 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.

The Vision Gap with a less consistent vision.

How would you draw your experience with this?

A term that was new to me in this context was the word “adopt” to designate acquiring software without performing modifications to it. I like this terms because it implies you aren’t doing anything to the original. The paradigm for this acquisition strategy is to purchase something like QuickBooks that possesses a built-in business process that organizations are unlikely to modify.

In the continuum of adopt vs build, we identified several points:

• Adopt and do nothing (e.g., Microsoft Word, PowerPoint)
• Adopt and configure to suit business practices within the application (e.g., Salesforce)
• Adopt and configure to suit using consultants (e.g., Microsoft CRM)
• Acquire commercial software and customize (e.g., SharePoint, Raiser’s Edge, most association management systems)
• Acquire open source software and customize (e.g., Moogle, Drupal)
• Build using an application server to accelerate development (e.g., Cold Fusion)
• Build using proprietary or open source components to accelerate development (e.g., corporate class libraries)
• Build from scratch using class libraries and design patterns (e.g., Microsoft MVC, factory patterns, AJAX libraries)
• Build from scratch using core libraries (e.g., develop unique base patterns)

These examples are archetypes which won’t hold up under the closest scrutiny. Microsoft Word, for instance, has extensive capabilities to customize and configure. That being said, I believe most people who purchase Word do so to gain its innate capabilities, not because of its ability to support macros and .NET development.

In working towards a set of criteria to make this choice, let’s remember the fundamental goal: what is the most cost effective means to achieve a business end?

The answer to that question is too big for any single entry, but here are some of the factors that can go into answering the question:

• At what level does the functionality you seek exist already?
• What is the cost to implement existing functionality?
• What is the cost to modify functionality to match yours?
• To what extent are your business practices a strategically valuable differentiator?

The answer to these questions? The process of real examination of business practices, both existing and desired, in-depth requirements analysis, attention to, but not limitations of existing skill sets, and, above all, razor-sharp focus on strategic outcomes. It’s easy to get lost in the weeds of a decision like this. Let’s just make sure when it comes to making this decision, we don’t lose sight of what we are trying to accomplish.

There’s more to come. . .

Have you developed any rules of thumb for software acquisition? Let me know your stories!

For more information on the ASAE Tech Swaps, check out the ASAE Calendar of Events: http://www.asaecenter.org/programsevents/calendar.cfm?CalendarID=15482&navItemNumber=14535&navItemNumber=24387

Also, put the ASAE 2010 Technology Conference on your calendar for February 10-12 here at the Washington Convention Center. There is more information at ASAE: http://www.asaecenter.org/ProgramsEvents/EventDetail.cfm?EventID=675695

As many of you know who follow my thinking, they key to successful projects is resilience: how well a project adapts to change. The implication of this line of reasoning is that success or failure has nothing to do with the software and everything to do with how the software is built. In short, not the end, but the means to the end.

The reason successful software projects are miraculous is that they require such an incredible combination of factors to succeed:

• The idea for the software has to be good in the first place
• The expression of the idea for the software has to be well articulated
• The understanding of the idea from those listening has to be accurate
• The translation of the idea into an action plan has to be successful
• The execution of the action plan has to be successful
• The darn code in the software has to be accurate
• The testers figuring out whether the software is accurate need to do their job well
• The people using the software need to know what the software is supposed to do
• The people using the software need to use it properly
• The problem you built software for still have the same problem when it’s done

And all of this in an environment in which every day things will change: the workplace, the technology, the people building the thing, the people using it and the reality of having even more good ideas as we go (plus a lot of bad ones).

How hard is that?

Well, 25% hard.

Under those circumstances, I would offer that the 25% success rate is nothing short of miraculous.

Now don’t get me wrong. Those of us in the business are not stepping back attributing success to a higher power (although that might have a role here, as well). Instead, we are constantly working on the factors that lead to success.

Microsoft has an article out that has some very good insight into the characteristics of successful software teams: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx. This article is particularly useful if you are in a position of either managing a development effort or managing a vendor relationship. There are a variety of sources that can help you determine whether you are going to achieve a level of productivity and quality in the process.

In addition to all the factors they cite, I’m going to offer this as part of the miracle of success: successful, resilient projects need all of that and resilient people. People who themselves are willing to look at the situation half full and with a prospect of success (thanks to Seth on the Heuristics team for pointing that out).

So I wonder: if we think of successful projects as miraculous, will we have more of them? I’d say anecdotally, yes!

What do you think?

Many thinkers are coming to the conclusion that we simply can’t prevent bad things from happening, so let’s focus on making sure that when (not if) they happen, our work can go on. I’ve had a number of conversations with people in a variety of fields that suggest this is an ascendant concept. You heard it here first, folks!

Here are some of the disciplines that seem to be embracing resilience as a value:

• Urban planning: communities can examine how they will continue to prosper under different circumstances. Communities built around single industries (e.g., steel or manufacturing) or transportation choices (e.g., cars) may have a more difficult time adjusting to change.
• Mental health: resilience is a trait in individuals that allows them to maintain a positive attitude even during times of stress and change. Resilience is about looking at the “glass half full” and looking forward rather than backward.
• Responses to terrorism: if we can’t keep people from blowing themselves up (not that we should try), let’s make sure when (not if) it happens, the walls don’t crumble around us

For software project and IT governance, resilience is about responding to the inevitable changes that occur in projects. As clear as our vision might be when we start an initiative, we inevitable learn something during the project that causes us to change direction. A resilient project will have the characteristics to embrace change and stay on course to core goals. I’ve already written a couple of posts about how projects can be more resilient with concepts like the management reserve and  Predictability as a promise (Part I)  and Part II that give some bounds around setting expectations for change.

Don’t get me wrong: let’s not stop trying to “get it right the first time.”  Resilience isn’t about promoting change! Change is always expensive. So the key becomes something like helping the business make the right decisions at the right time. Decisions made too early or too late risk loss of productivity. Good decisions made whey are needed keep us moving forward.

How do we make sure good decisions are made at the right time? We have a few tools like Agile methodologies that at least spread out the decisions, but, like any tool, Agile is not an answer in and of itself. Agile just tells us we don’t have to make all of our decisions up front and expect them to be fixed. Instead, iterative processes just force us to recognize that we can’t get everything right the first time, so we might as well change in small increments instead of big ones. I have a few more thoughts coming on “how to decide when to decide,” but you’ll have to wait.

What’s your definition of a “resilient” project?

As hazardous as it is to undertake any ambitious software development project, systems conversions can be especially dangerous. On the one hand, rebuilding a system offers a promise of skipping some of the growth pains that occurred as the original system was deployed. On the other, if expectations about the new system are not managed carefully, the new system is likely to be even more problematic than the original roll-out. Even if the process is smoother than the original, people’s selective memory is likely to raise the stakes.

 Here are some thoughts to achieve Predictability and Understanding in a system conversion.

Step 1: Right thinking

Before you take any steps, get your head on straight. The functioning system is only a representation of what the system will be. It is not the full picture of what needs to be done. One person’s experience of the system will not be the same as another’s, so you need to do as much work to understand what goes on outside the system as you would have to build the system originally. You may know what the “system does” just by looking at it, but you don’t know “how people use the system.” The principle of Understanding in this case is that it is more important to understand the people than it is to understand the system.

One way to think of the existing system is as a functional prototype. It provides invaluable information about system behaviors, but it does not tell you anything about human behaviors. You still need other kinds of supporting documentation to understand those human behaviors.

Step 2: Take the right steps

If you think of a system conversion as any other system development project that has the advantage of a working prototype, you have a head start on Understanding, but you are a long way from being done. You still need to complete all the other tasks you would on any other system to achieve common Understanding:

• Involve executive stakeholders to determine the priority of existing functionality;
• Establish a defined list of features that will be converted;
• Involve end users to understand how they use the system. You don’t need wireframes, but you will need use cases;
• Make sure people understand that if a task doesn’t make it into a use case, it won’t end up in the new system; it is the end user’s responsibility to validate that the feature list is complete; and
• Involve technical stakeholders in the requirements process, including architects, programmers, and quality assurance personnel.

Step 3: Negotiate and set expectations

Predictability dictates that an enormous amount of details will need to be negotiated before any development commences. As requirements are being gathered, it is critical to know and manage expectations with regard to the new system. Some of the details to work out are:

• Does the graphical user interface need to be an exact match?
• If the graphical user interface doesn’t need to be an exact match, are there specific areas that do?
• Does the functionality need to be exact, or is it possible to introduce innovations to reduce the number of steps for a process?
• If the functionality does not need to be an exact match across the board, are there specific areas that people are more sensitive to?
• What do we do with existing system defects? Do we fix them? Do we log them for later resolution?

You’ll achieve a measure of predictability if you firm up these answers before you start.

Step 5: Plan releases with use cases in mind

In planning release cycles, make sure to prioritize development efforts to anticipate dependencies. Studying use cases carefully will help avoid scenarios in which areas of functionality are completed but cannot be released because dependencies have not been completed.

Step 4: Proceed “Agilly”

As with all system development projects, expect change. The principle of Predictability is not to see the future, but to make sure we are prepared to make decisions when we need to. Make sure you have project infrastructure to identify change and adapt. Deploy these strategies to keep teams in alignment:

• Show converted functionality early and highlight areas of difference. Doing this early will help teams modulate expectations.
• Build the system iteratively so that the impact of change can be assessed in small increments instead of large ones.

Step 5: Plan your roll-out strategy

The test of Predictability will happen during the system roll-out. As with other systems, it is helpful to have a pilot group that is more savvy and tolerant to help with initial release. There are always surprises, so make sure your first audience can appreciate them.

Expect some additional challenges to your roll-out, including:

• Resistance to change: in general, change is “bad,” so expect people to be unhappy just because something is different; make sure you give your audience enough time to become familiar with the system before letting them reject it.
• Missing functionality: Most likely, there will be areas of the new system that were missed in the original specifications. Usually, these are alternate paths, boundary conditions, or work-arounds that people have become familiar with but could articulate in their use cases. Prepare your audience for this likelihood and plan to make modifications as issues arise.
• Defects: As well as a system can be tested, there will be defects in the system that were not present in the old system. Set expectations around this regarding the number of defects that is “acceptable.” You can use calculations regarding Mean Time to Defect to project an acceptable level of error. If fewer defects were reported than the threshold, you can be a hero. If there are more, the reaction will still be more favorable than if the expectation is “zero.”

To summarize: don’t shortcut the software development lifecycle just because you have an existing system. Make use of the existing system to clarify expectations, but make sure you capture requirements like any other system. Involve your stakeholders and set good expectations, and you’ll achieve great success. Who knows: people might actually WANT to remember this one! 

I’d love to hear from you what lessons you’ve learned to help succeed at system conversions.

The principle of a management reserve is to allocate funds to accommodate change as it arises. This is different from a buffer, in which we recognize that tasks most likely take longer than we think they will. Instead, it is a margin that we define in advance that has no purpose other than to be allocated to managing change. It allows us to have a fixed cost contract while providing a framework in which to evaluate and accommodate change.

I’m a big fan of fixed cost contracts: figure out how much you want to spend on something and then share the risk and reward with the people building it. The service provider bears the risk of the project costing more and the reward of completing early.

The problem is, by itself, a fixed-cost contract does not provide the tools to manage either risk or reward. While it provides a budgetary number, it does not provide a framework for change management.

The fixed-cost contracts we have worked with have tended towards one of these options:

• Cap with justification: we start with a number and know it won’t change unless we need it to change; or
• Zero-sum: start with a number and as new tasks come up, chop off low-priority items

Neither of these accounts for change in a manner to preserve either Predictability or Productivity.

Cap with Justification attempts to achieve Predictability by setting a cap on effort. The problem with this, is that if you don’t know what your true cost threshold is, you really don’t have a budget. You just have a starting point. The reality of the starting point, is that those who write the checks will see it as a budget. When change arises, you know you will need to go back to the well, and the degree to which you need to fight for new funds depends upon circumstances beyond your control. If justifying the change requires considerable impact analysis and negotiation with sponsors, you can lose significant Productivity. So Cap with Justification fails to be Predictable because you don’t know what your real cost threshold is, and it fails to be Productive because you have to spend a lot of time in change management.

As much as the problems with Cap with Justification have on Predictability and Productivity, the Zero-Sum model is worse. The Zero Sum model proposes that for every new item or change, something needs to be removed. The problem with this model is that under any real circumstances, you will get LESS than you originally decided you needed. Change will not just off-set previously defined functionality. You will also have wasted the time to analyze and specify the original functionality. You will lose additional functionality in the process of performing impact analysis.

The Solution: Management Reserve

With a management reserve, sponsoring organizations are able to be responsive to change. They know they have both an initial budget and a reserve, and they have the means to make decisions for an application to grow into the management reserve. Service providers make use of management reserve to make specific investments in productivity. Combined, the teams can enter into a contractual relationship with the tools to manage change without losing productivity.

As with most tools, the concept of a management reserve is also not a solution in and of itself. Organizations need to have robust change control models, and they need to have a means of allocating the right amount of funds to the reserve.

Look for more thoughts on how much management reserve to allocate and how to make decisions to allocate it to your projects.

How do you manage change?

While she said it as a joke, as with most jokes, there is an element of truth. Most of us are so focused on solving immediate problems that if they went away, we wouldn’t know what to do.

So what to do when you don’t know what to do? Plan!

As enviable as this person’s predicament might seem, don’t be so sure that you would know what to do yourself. Without a strong framework for planning and without clear strategic objectives, we are left with a sense that we are sitting on a peak and the only option we have is to fall down.

So how do you develop a plan? My recommendation is to organize your goals in two categories: mission-oriented goals and effectiveness-oriented goals. Mission-oriented goals assume that you are enabling others to pursue the mission of the organization while effectiveness-oriented goals relate to your internal measures for success. I recommend thinking about these along the lines of Predictability, Understanding, Productivity, and Quality, as you can see in some of my other posts. 

It is much easier to develop mission-oriented goals if you have a strategic plan. To some extent, this can be an intellectual exercise of breaking everything down along the mission-strategy-goal-tactic model. From there, you can meet with other departments to determine how you can support their pursuit of mission.

Without a strategic plan, the task can be a little trickier, but your task still involves learning what departments are trying to accomplish. Their tasks may not be clearly aligned with mission, but at least if you are aligned with them, you will assist overall organizational effectiveness.

Some of the criteria to incorporate are those in the “CIO Code,” which proposes that everything you do have a measurable outcome. The planning process gives you the ability to determine how you are going to measure success before you complete a task.

So for those of you who aspire to being able to plan, Get Ready! You’ll get there, and it won’t be easy once you are there. Just keep focused on the discipline of defining priorities and outcomes, and your plans will make sure to keep the fires out.

What have you found helpful when constructing a plan?

In a business environment that shuns strategic planning, we can’t succeed by focusing solely on tactical matters. We also can’t succeed if we don’t put out the fires. By differentiating tactical and strategic matters, we can craft an “emergent” strategy that helps us address immediate concerns without losing sight of the big picture.

Here are some steps to help create an emergent strategy.

Step One: Know that you have a problem!

Like any 12-step program, knowing you have a problem is the only way to solve it. So know this: strategic problems never go away and if they aren’t resolved, your tactical issues won’t either.

Step Two: Ask the question: strategic or tactical?

When establishing an agenda for a meeting or defining scope for a task, determine which it is: is the outcome a solution or is the outcome clarity of purpose?

I’ve found these definitions helpful:

Tactical: This is an execution plan that has as its objective the resolution of a known issue. A is broken so let’s fix A. We’ll need to address B and C to address A, so let’s get those fixed. Tactical is all about troubleshooting and getting things done.

Strategic: This is the conceptual and goal-oriented conversation. This is a matter of determining why we are doing something and what criteria will guide our decision-making moving forward. This is all a process of moving from ambiguity and chaos to structure and predictability.

Step Three: Use a parking lot

Be true to your conversation: if you are trying to fix a systems error, stay focused on the error and its resolution. If, as you are examining the error, you realize that your processes led to the error or if in the course of resolving the defect you recognize a pattern, make sure you both: a) raise the strategic issue and b) don’t become distracted by it. It may be that adjusting your tactical approach to a more strategic one is feasible and it may not be, but don’t confuse the two.

Step Four: Schedule time to review strategic issues

Most of the issues you put inthe “Strategic” parking lot aren’t going to go away. Track them in a central repository and schedule a periodic meeting to review them. You’ll be amazed at how a weekly 30  minute conversation that prioritizes strategic issues can start knocking them off the list. You’ll find that you are much more likely to recognize patterns and anticipate problems with even a modicum of attention. Knowing what needs to be done and why helps turn some of the strategic initiatives into tactical projects that make a profound difference.

Step five: I’m stopping here! (we don’t need 12 steps, do we?)

One of the profound outcomes of maintaining a strategic parking lot, is that it gives you a terrific starting point from which to request additional resources. By definition, strategic issues are those whose impact will be far reaching. Knowing what they are will help you prioritize and assess impact. 

Evaluating and prioritizing issues belongs in a separate post, but you can imagine the teasers: how does the issue relate to organizational mission? how will the issue improve Predictability, Understanding, Productivity, or Quality?

So, how do you craft an emergent strategic plan? If you can’t do it up front, do it as you go. You not only might make progress on your strategic goals, you might even find that strategic planning is more effective when done in the context of your real life.

Here’s one for you: how do you address strategy when you are buried in the day-to-day?

Knowing that change will happen, the hardest part of managing a software project is often recognizing that a change has happened. It is so difficult to define a project carefully enough to recognize all of the details, that most often when something changes, it is invisible to all parties until the project goals are at risk. That is why so often the news of a late delivery comes late: something changed, no one said anything about it, and all of a sudden we are going to miss a deadline. This is also why models such as the Capability Maturity Model are so helpful at improving predictability. If we have a way to recognize change, we have a way of managing it.

Keeping a promise is more than project management, but project management is the key discipline to keep parties on a project aligned. I am a strong proponent of the Project Management Institute (PMI) Project Management Professional (PMP) certification, and insist that any project manager I work with is certified. We are aiming for predictability, after all, so it makes sense that project managers implement projects to a defined standard.

This is not a blog about project management, so I won’t delive into the details of each artifact of the PMI Body of Knowledge (PMBOK). However, I do want to highlight the deliverables and their objectives that have proven themselves useful at maintaining predictability.

In general, each of these artifacts is designed to: a) create a baseline of expectations; and b) manage the impact of changes to expectations. The artifacts I find especially helpful include:

• A Project Charter: this document defines an initiative so that we understand what we are trying to accomplish. The purpose of this document is to have a common reference point to the assumptions we made early in the project. Some of these are bound to change, and, if they do, the changes will need to be analyzed to determine if they have an impact on the project. Some of the details to capture are:
  • Objectives
  • Outcomes
  • Stakeholders
  • Sponsors
  • Budget
  • Time line
  • Risks
  • Constraints
• Project Plan: The purpose of this document is for people to understand the dependencies among tasks so that as change happens, we understand the implications. The purpose of this document is NOT to move bars on a Gantt chart from 0% to 100%. We know that change will happen over the course of a project. The tough part is knowing what happens to everything else if something new comes up.
• Requirements documentation: The requirements document captures the details of what we are going to build. The key challenge is producing documentation that is illuminating for all stakeholders. If it is too technical, you’ll lose the subject matter audience; if you make it too business-oriented, you’ll miss the technical implications of the system. The approach I have found to represent the best balance among these is one of Use Cases, which provide discrete, goal-oriented, tasks for the system. I’m sure I’ll get into this more somewhere else.
• Change management protocol: We know change is going to happen, so we need a way to raise changes and respond to them. We need to know who can provide the information to evaluate a change and we need to know the impact of the change on the whole project.
• Frequent cross-team meetings: I am a big fan of the Agile approach to daily standups, in which the entire team convenes for 15 minutes to assess risks and obstacles. The more frequently we discuss issues of substance, the more minor corrections we can make to the project to help it achieve its objectives.

There are countless other tools that can help baseline a project and manage change, but these represent some of the minimal artifacts and processes that work in any environment. Regardless of whether you are a developer or a sponsor, careful scrutiny of the tools used to manage change will be a strong indicator of project success.

As I mentioned in Part I, you need a good promise to execute from, but without the tools and discipline, the promise is only as good as the execution. You can be certain that when the promise is broken during execution, we are no less likely to be profoundly disappointed.

What tools have you found particularly useful? What have you found not to be useful?

I’ve been talking to a lot of people recently about “brand promise.” The idea being that when someone hires you to do something, they are hiring your organization because your organization promises to do something. It’s different from a contract, because that is spelled out very carefully. Instead, the brand promise is catchier and yet, in many ways, no less binding than a contract. A brand promise is something closer to Miller Lite’s “Tastes Great, Less Filling” tag line, or Budweiser’s “Drinkability” campaign. If the product doesn’t live up to the tag line, theoretically, people stop buying the product.

I like the notion of a promise in the context of the principle of Predictability, because when we enter into a work agreement, all of the emotional factors of a promise enter into the equation. When we fail to deliver something according to an agreement, the reality is rarely free of emotion. People feel personally let down, disappointed, and even angry.

If we focus on the dynamics of a promise, we can differentiate two “points of failure:” the promise itself and the execution of the promise. Promises can fail for a variety of reasons, but it can be helpful to differentiate whether it is the initial promise that is to blame or the way the promise was acted upon. 

Let’s look at how promises can be wrong:

• Bad intent: obviously there is always the possibility that when someone makes a promise to you, there is an explicit intent to mislead. My experience is that this is rare. A more common scenario is that people are so desparate to make a sale or take a job that their intention simply exceeds their knowledge or skill and overwhelms the rest of the variables.
• Bad information: people can make a promise based on faulty information. This is much more often the case in bad vendor relationships. People make promises based on what they know, and the information they base their promise on is just inadequate to the task. Since we almost always need to make promises without all the information we need, bad information is just solved with a good “definition.”
• Bad expertise: it is very common for people to make bad promises based on bad information not just because the information itself was bad, but because the questions asked to obtain the information were themselves flawed. If the person asking the questions doesn’t know enough to obtain the right information, the promise is doomed from the start. This also can be mitigated by “definition,” but we are less likely to see a good definition from someone without the expertise to define.
• Bad definition: Poor definition is both a cause and a result of bad information and bad expertise. With the right expertise, you are likely to see good questions, good definitions of what is to be done, and a host of exclusions and assumptions that govern expectations. The right definition will draw attention to unknowns and risks so that as new information unfolds, expectations can be amended.

So why does this matter? It matters because we want to be in relationships in which promises are kept. When evaluating a vendor, we can focus on some of the key variables that we know are going to impact their ability to deliver what they promise: Are they asking good questions? When they make a proposal, do they qualify based on their knowledge? We are almost never going to know if someone is lying to us to get our business, but by examining definitions carefully and reviewing the information that has been shared, we’ll have a much better sense of what the outcome of a project is going to be.

So what is the key to predictability? Start with making sure you’ve made a good promise. Then let’s move on to execution. Stay tuned for Part II.

What do you think?