Goals and Definition

Author(s)

Business Relationship Manager - Product Lifecycle Management, Chevron Corporation

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 1Figure 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.

Similar Resources

Enhancing Your Team’s BPM Capabilities: The Value of External Expertise

Enhancing Your Team’s BPM Capabilities: The Value of External Expertise

Author(s):

Editor & Founder, BPMInstitute.org, BAInstitute.org and DBIZInstitute.org

Enhancing Your Team's BPM Capabilities: The Value of External Expertise In today’s dynamic business environment, managing and improving business processes is critical for any organization aiming to maintain a competitive edge. Many companies consider handling Business...

Exploring Shared Data Model and Notation (SDMN) and Its Role in BPM+

Exploring Shared Data Model and Notation (SDMN) and Its Role in BPM+

Author(s):

Editor & Founder, BPMInstitute.org, BAInstitute.org and DBIZInstitute.org

Exploring Shared Data Model and Notation (SDMN) and Its Role in BPM+ Introduction In the evolving landscape of Business Process Management (BPM), the introduction of Shared Data Model Notation (SDMN) marks a significant advancement. As businesses increasingly seek to...

Article: Embracing the Future: Low-Code and No-Code Platforms in BPM+

Article: Embracing the Future: Low-Code and No-Code Platforms in BPM+

Author(s):

Editor & Founder, BPMInstitute.org, BAInstitute.org and DBIZInstitute.org

Article: Embracing the Future: Low-Code and No-Code Platforms in BPM+ Introduction In the realm of business process management (BPM), low-code and no-code platforms have emerged as transformative tools, reshaping how organizations develop applications and manage...

Featured Certificate: BPM Specialist

Everyone starts here.

You're looking for a way to improve your process improvement skills, but you're not sure where to start.

Earning your Business Process Management Specialist (BPMS) Certificate will give you the competitive advantage you need in today's world. Our courses help you deliver faster and makes projects easier.

Your skills will include building hierarchical process models, using tools to analyze and assess process performance, defining critical process metrics, using best practice principles to redesign processes, developing process improvement project plans, building a center of excellence, and establishing process governance.

The BPMS Certificate is the perfect way to show employers that you are serious about business process management. With in-depth knowledge of process improvement and management, you'll be able to take your business career to the next level.

Learn more about the BPM Specialist Certificate

Courses

  •  

 

Certificates

  • Business Process Management Specialist
  • Earning your Business Process Management Specialist (BPMS) Certificate will provide you with a distinct competitive advantage in today’s rapidly evolving business landscape. With in-depth knowledge of process improvement and management, you’ll be able to take your business career to the next level.
  • BPM Professional Certificate
    Business Process Management Professional
  • Earning your Business Process Management Professional (BPMP) Certificate will elevate your expertise and professional standing in the field of business process management. Our BPMP Certificate is a tangible symbol of your achievement, demonstrating your in-depth knowledge of process improvement and management.

Certification

BPM Certification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Process Management Certification from the industry's top BPM educational organization.

Courses

 

Certificates

  • Operational Excellence Specialist
  • Earning your Operational Excellence Specialist Certificate will provide you with a distinct advantage in driving organizational excellence and achieving sustainable improvements in performance.
 

 

OpEx Professional Certificate

  • Operational Excellence Professional
  • Earn your Operational Excellence Professional Certificate and gain a competitive edge in driving organizational excellence and achieving sustainable improvements in performance.

Courses

Certificate
  •  

  • Agile BPM Specialist
  • Earn your Agile BPM Specialist Certificate and gain a competitive edge in driving business process management (BPM) with agile methodologies. You’ll gain a strong understanding of how to apply agile principles and concepts to business process management initiatives.  
 

Business Architecture

 

Certificates

  • Business Architecture Specialist
  • The Business Architecture Specialist (BAIS) Certificate is proof that you’ve begun your business architecture journey by committing to the industry’s most meaningful and credible business architecture training program.

  • Business Architecture Professional
  • When you earn your Business Architecture Professional (BAIP) Certificate, you will be able to design and implement a governance structure for your organization, develop and optimize business processes, and manage business information effectively.

BA CertificationCertification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Architecture Certification from the industry's top BPM educational organization.

Courses

 

Certificates

  • Digital Transformation Specialist
  • Earning your Digital Transformation Specialist Certificate will provide you with a distinct advantage in today’s rapidly evolving business landscape. 
 

 

  • Digital Transformation Professional
  • The Digital Transformation Professional Certificate is the first program in the industry to cover all the key pillars of Digital Transformation holistically with practical recommendations and exercises.

Courses

Certificate

  • Agile Business Analysis Specialist
  • Earning your Agile Business Analysis Specialist Certificate will provide you with a distinct advantage in the world of agile software development.

Courses

Certificate
  • DAS Certificate
  • Decision Automation Specialist
  • Earning your Decision Automation Certificate will empower you to excel in the dynamic field of automated decision-making, where data-driven insights are pivotal to driving business innovation and efficiency.