Decomposing Goals

Name: Decomposing Goals
Type: Principles
Status: draft
Version: 2007-12-21
Source: D. Doerner ('The Logic of Failure'), own thoughts

Gist: to explain why - for a complex, dynamic, interrelated endeavour - it is paramount to decompose global, complex, vague goals into specific goals.

Also see: Specifying Goals, Courses of Action

Definitions:
A global goal is a goal which has only few (one) evaluation criteria.
A vague goal is a goal which has only few (none) measurable evaluation criteria.
A complex goal is one that can be decomposed in two or more goals that are more specific.
An implicit goal is one you're not conscious of now.
Note: Quite often it is possible to say "problem" for "goal", as a goal is a problem turned upside down.

P1: Using a single word for a goal seems to imply that there is one thing the word stands for. Example: "User-friendlyness" Looking closer, we find that there ist no such one thing, it is composed of several other things (subgoals), like "percieved performance", "nice GUI" etc.
Note: This decomposition is subjective.

P2: The subgoals may contradict each other, like "percieved performance" and "wealth of functions". This is why we need to decompose the goal: otherwise we have a single goal which is in itself contradictory. This makes people feel uncertain and insecure.
Note: Often people don't know why they feel uneasy when confronted with such a goal.

P3: Subgoals usually will be handled in one to three different ways:
- dissection of central and peripheral goals, to be able to focus on the central ones
- dissection of important and urgent goals, also to be able to focus, but dependent on outside constraints like "deadline"
- delegation of the goal, to get rid of the difficult goal

P4: Conflicting (sub)goals get handled in two ways:
- finding a balance in reaching these goals, i. e. compromise
- ignoring one of the goals completely for the good of the others
- eupemistically re-arrange the whole system of goals, for the contradictions to dissappear ("if we had 'new' citizens...")

P5: Implicit goals can be uncovered by asking "What do I want to keep?" while aiming at some change.

P6: Confronted with a complex, global, vague goal, we usually find a (wrong) subgoal either because it seems apparent or because we are able to solve it. After a while this makes us feel even more uncertain, because we seem to not get closer to the goal.
Note: An apparent goal may not be the important nor urgent, and may be perpheral.
Note: In the IT world, this behavior surfaces as the confusion of means and ends. E. g., people think gathering data is the end, while it is a means to empower decion making. We usually do so because we feel secure in what we do.

P7: Confronted with a complex, global, vague goal, we proceed "ad hoc" in the sense we don't care for future problems caused by our problem solving. More uncertainty.
Note: "Ad hoc" has its advantage, it's better than doing nothing. This of course also is dangerous if we feel pressed to do something.

P8: Confronted with a complex, global, vague goal, we proceed "ad hoc" in the sense we ignore implicit goals. More uncertainty.

P9: Ultimately, feeling really uncertain and unsecure, we tend to dive deep into one of the goals and ignore the rest. This goal is the new holy grail.

Course of Action

Name: Course of Action
Type: Process
Status: final
Version: 2007-12-20

Gist: to explain how to act upon a problem or complex, dynamic, invisible situation

S1: work out your goals see >Specifying Goals, to be used as guides and criteria for evaluation of your actions (see step 5).
S2: gather information about the situation and about how it changed over time in order to build a structural model of the problem
S3: build hypotheses about how the situation has changed and deduct how it will change
S4: plan your actions, decide on your actions, act (don't forget to think about doing nothing)
S5: check the effects (momentary facts AND tendences!) of your actions and refine your strategy with new evidence
Note: this is not a linear process. Trace back to any step whenever you feel you should.

Analysis Mechanisms for Eliciting Architecturally Significant Requirements

Name: Analysis Mechanisms for Eliciting Architecturally Significant Requirements
Type: Rule
Status: final
Version: 2007-12-06
Source: Peter Eeles, Senior Architect, IBM, 2004, http://www.ibm.com/developerworks/rational/library/4706.html

Gist: to provide a checklist of analysis mechanisms that can be used in order to find out about requirements that will be significant to the achitect.
Analysis mechanism DEFINED AS implementation-independent solution to a problem

R1: Consider the following analysis mechanisms when gathering architectural requirements.

Analysis-Mechanism - Description
Auditing - Provides audit trails of system execution.
Communication - Allows distributed processes to communicate.
Debugging - Provides elements to support application debugging.
Error Management - Allows errors to be detected, propagated, and reported.
Event Management - Supports the use of asynchronous messages within a system.
File Management - Provides services for accessing a file system.
Graphics - Supports user interface services, such as 3D rendering.
Information Exchange - Supports data format conversion.
Licensing - Provides services for acquiring, installing, tracking, and monitoring license usage.
Localization - Provides facilities for supporting multiple human languages.
Mail Services that allow applications to send and receive mail.
Mega-data - Support for handling large amounts of data in a client-server environment.
Memory Management - Services for abstracting how memory is allocated and freed.
Meta-data - Supports the runtime introspection of components.
Online help - Provides online help capability.
Persistence - Services to manipulate persistent data.
Printing - Provides facilities for printing.
Process Management - Provides support for the management of processes and threads.
Reporting - Provides reporting facilities.
Resource Management - Provides support for the management of expensive resources, such as database connections. Provides support for the management of expensive resources, such as database connections.
Scheduling - Provides scheduling capability.
Security - Provides services to protect access to certain resources or information.
System Management - Services that facilitate management of applications in a distributed environment.
Time - Services to synchronize time on a network, and to translate times into different time zones.
Transaction Management - A mechanism for handling ACID 1 transactions. ' The acronym ACID refers to four characteristics of a transaction: Atomic, Consistent, Isolated and Durable.
Workflow - Support for the movement of documents and other items of work, typically through an organization.

How to give a project a good start

Name: How to give a project a good start
Type: Process
Status: final
Version: 2007-12-06
Gist: describes what to do as a manager to make sure that the project after it's finished will be seen as a success AND something of real value has been produced.

S1: Meet with a few of your management colleagues and talk about the project's goals until you reach a consensus.
S2: Gather a kickoff meeting with these colleagues and make everybody bring one or more workers who are supposed to do the project work.
S3: Be as precise and specific as possible if some of the workers ask questions.
S4: Be specific about the project goals or concrete deliverables you might want to see. Let the project work out project organisation and courses of action.
S5: Ask the workers to explain their understanding of your vision.

Note: Surprisingly, you might have a hard time finding a project leader to happily go along with this behavior, for he can't sell almost anything as a success for you.