This article is about getting started on a development project. In a way, it is about problem finding. In particular, it is about deciding what is of concern and what is not, and what aspects of policy are important in setting a course toward a plan.
But before I get into that, I have to get something off my chest. It is becoming a real peeve, but it is highly relevant to this article and so worth talking about up front.
Issues vs Problems
The peeve is about the misuse of the word “issue”. Issues are not problems, but in today’s casual use of language, we hear everywhere–from ordinary street conversations to erudite news pronouncements–about people “having issues”, “solving issues”, “suffering from issues” and routinely treating the words issue and problem as interchangeable. Problems are not issues, and we lose an important distinction when we treat them as if they were.
A problem is an obstacle, an impediment, something to avoid, solve, eliminate or otherwise remove on the way to achieving a goal. Problems are uniformly “bad” in that they confront us with something we want to overcome.
Issues are more neutral. They are like forks in the road where a decision must be made that will take the decision maker one way or another. Issues usually are at a deeper level than problems. “Taking a position” on an issue establishes policy that will determine which problems at a shallower level will appear and how they will be solved. We “take issue” with policy when we think that it reflects a wrong turn on an underlying issue. We look for the way to express “questions at issue” most appropriately when we are trying to pin down the fundamental concerns of a project.
To raise problems to the level of issues is to risk failing to address high-level concerns at the critical early phases of a project. Issues should be sought out as policy guide posts, considered thoughtfully for the alternative paths they present, and recognized for the high-level contributions they make to the form the plan ultimately will take. Taking positions on issues is one of the first acts of planning. Deciding to go one way rather than another begins the design process.
Issue-based Project Definition
Issues as a focus in project definition has strong foundations in work done at Berkeley, California and Heidelberg, Germany in the 1970’s. Under Prof. Horst Rittel of U.C. Berkeley and Werner Kunz of Studiengruppe fur Systemforschung, the concept of IBIS (Issue Based Information Systems) was developed as a means for interactively studying differences and evolving views among stakeholders in a project. From their work, Structured Planning adopts the concept of issues as fruitful subjects of research and study at the earliest stages of a project.
From a Charter initiating a project (usually formulated by those with the authority to assemble resources–perhaps, a Metaplanning department or group as discussed in my article “Reforming the Development Process”), a planning team obtains background, goals, initial direction, methodology and some of the key issues to be considered immediately.
Issues are expressed as a topic and a “question at issue”. Over many projects, we have found that anything less produces questions anyway; a topic only isolates a potentially troublesome area–it doesn’t suggest where the trouble may be. For example, on a project we did for NASA before the Challenger disaster, cost was the topic of an issue. Without further information, there was little to go on. Obviously, cost should be minimized, or so it would seem; Congress was not in a spending mood. In fact, that interpretation would have been shallow to the point of incompetence. A Question at Issue was added: “How should the cost of the space station be treated in terms of its impact on design strategy?” Over the course of investigation, that question led to a Position on the issue: “Cost must be treated as total cost (rather than initial cost) in order to accommodate planning for unforeseen problems and opportunities”. In the process of argument and discussion, it became very clear that a low initial-cost approach (to the stage where space station would be operable) would save money initially, but cost more in the long run as space station had to be modified and refit for uses unplanned decades earlier. A design strategy that maximized adaptability would cost more initially, but save money substantially over the life of the space station.
Defining Statements
Issue-based project definition has evolved in Structured Planning to the use of single-page Defining Statement documents to highlight important issues, lay out plausible positions, argue their merits and make the cases for the positions to be taken. In their self-contained form, Defining Statements become little “white papers”, concise, to the point, and easy to grasp. A sample Defining Statement (the cost example for NASA) is shown in the figure.
Figure 1
Among the subtleties of wording and semantics that have emerged, is a convention that has special value for thinking about policy and goals. Most projects have in their formulations some expression of goals or objectives. Often these are a mix of a few well-focused statements targeting desired goals and boiler-plate statements that reaffirm the organization’s commitment to good works. If the goal statements get close to touchy subjects, they may become casualties to the difficulty of negotiating agreement between management (as project initiator) and planning team on sensitive subjects. In that case, goals may become weak compromises or even no-shows–no one wants to commit to a goal that may be difficult or impossible to achieve.
There are also goals (usually held by the planning team) that fit under the “hidden agenda” category–biases or styles of solution that are unexpressed personal preferences of one or more planning team members. A not-so-hidden, directly observable example of this “personal preference” is often seen in architectural planning, where the architectural firm has a strong, highly visible style. The firms of Mies van der Rohe or Frank Gehry are good examples. In these cases, the “bias” goal for a particular visual style is aboveboard, expressed in the long record of buildings the companies have produced. You wouldn’t go to either of those firms if you did not want their biased style as an expressed goal. The problem comes when the biases are not so readily visible and not put on the table. Such biases may take many forms.
In either of these cases, goal statements are likely to be watered down, vague, misleading or simply missing, and the project will suffer from the beginning with a failure of trust that may lead to further failures, most especially if results do not measure up to expectations through misunderstanding and the surprises of hidden agendas
In the Defining Statement document, goal statements are differentiated in three categories to deal with these problems. Each category has its own form of expression with an imperative verb or verb phrase to distinguish it from the others and a “force” of compliance agreed upon by definition.
At the top of the force scale is the Constraint. By agreement, a Constraint is a goal that must be achieved at all reasonable cost. The word must implies as much and is the operable imperative verb. Goals given as constraints must, by mutual agreement, be achieved if at all possible.
Next in force is the Objective. Here, the operable verb is should and the force is less. Having a statement type with this agreed upon force makes it possible for a planning team to “shoot for the moon” but be happy to at least make orbit. The majority of goal statements will be objectives; as an agreed-upon type, the objective brings goals out of the closet. It becomes possible to state that a goal is desirable even though it may be difficult to achieve. This clears the air and builds trust between authority and planning team. Everyone knows that the planning team will attempt the goal, but it won’t be held against them if the achievement is less than complete.
Finally, at a relative low level of force is the Directive. The Directive exists to bring biases and special agendas to the surface. Its operable verb phrase is ought to, a phrase with almost moral or ethical authority, appropriate for expressing a goal that may not be necessary in the sense that a Constraint expresses, but is desirable from an individual or group point of view. Biases, once on the table, become less personal and far less formidable. They can often be accepted or modified into genuinely valuable strategies agreeable to all.
The Position on the issue, of course, is the essence of the Defining Statement. It lays down the direction to be taken on the issue and, with the other positions on issues, actually begins the planning/design process. But there is more. The format of Defining Statements as documents allows the “rest of the story” to be told with the Alternative Positions that were considered (but not selected) and the reasoning–often insightful–that led to the selection. In sum, the Defining Statement documents become the first contributions to a project “knowledge base” that will make the project historically transparent and of value to future projects that might cover similar ground.
At the end of a Project Definition phase, a planning team may have assembled a surprising number of Defining Statements. Twenty to thirty are not uncommon, but we have seen over fifty on some projects. Because they deal with issues, they are properly at the front of the planning process. Because they bring refined understanding of the project’s goals, they are excellent subjects for review at the first gateway, when the initiating authority needs assurance that the project is on track and that there is understanding and agreement concerning intentions.
