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.

Specifying Goals

Name: Specifying Goals
Type: Rules
Status: final
Version: 2007-12-20
Source: various authors, including D. Doering ('Die Logik des Misslingens')
Gist: to describe goals (of an organization, of an IT system, …) in a clear and useful fashion
Note: like always, goals are a kind of requirement. So it doesn't hurt at all if you use the rules to lower levels of requirements, e.g. system requirements.
R1: Seperate different goals, even if they seem interrelated, for you can reference them.
R2: Name each goal unambiguously, use a short name.
R3: use the PAM structure:
P urpose
A dvantage
M easure
Purpose: Supplies a higher level rationale for the goal. Understanding the why gives you freedom in finding proper solutions.
Advantage: Differentiates the goal from others and from non-goals. So you also know what NOT to achieve.
Measure: Keeps you on track and supports your communication with the higher management. Gives you a clear sense of 'done' and provides satisfaction at the end. Makes it possible to evaluate measures concerning suitability and effectiveness.
R4: Iterate! There's nothing bad about changing goals along the way. Please restate the set of goals, though.
R5: Avoid comparatives, work until you know what they really mean. Try decomposing a comparative goal into a number of specific goals.
R6: Mind if you specify positive (get to x) or negative goals (avoid y). A positive goal gives you fewer opportunities to succeed than a negative goal, which can be good or bad. Be aware of the possibility that someone states a goal negatively because he does not know how it can be stated positively. You're bound to fail, not within the scope of the stated goals but in the scope of the real goals. Negative goals tend to be too global.
R7: global and specific goals are good, unclear goals are bad. try to make a global goal specific, however. if your global goal is unsufficient and you cannot come to a specific goal, try stating intermediate goals that maximise the opportunity of success. How? By specifying many subgoals with a good chance of reaching them. another way to put it is: try to set goals so, that by adhering to them you will be in a better tactical position towards your strategy.
global: the future state is determined by few (sometimes only one) criteria
specific: the future state is determined by many criteria
unclear: the future state is not determined by a sufficient number of criteria
R8: be extremely suspicious if you seem to have only one goal. this situation is very rare and the phenomenon indicates you forgot a number of goals.

3 Characteristics of Engineering

Name: 3 Characteristics of Engineering
Type: Principles
Status: final
Version: 2007-10-26
Source: Chris Britton, Microsoft, 2007 (http://msdn2.microsoft.com/en-us/library/bb508955.aspx)

The characteristics of engineering are:

1) The design is decomposed from top to bottom
Note: In contrast, software design is almost all low-level, and it is often hard to see how the entire system works.
2) All designs (high-level and detailed) are analyzed or tested to check for correctness.
Note: In contrast, software development relies almost entirely on testing the product only-in other words, the program code.
3) Implicit requirements, as well as explicit requirements.
Note: In engineering, there are some basic requirements-such as the fact that a bridge should not fall down-that do not need to be specified by the stakeholder.

And a nice quote of Chris': "Engineering is the art of scale."

Improve Reusability of Use Cases by Extracting Business Rules

Name: Improve Reusability of Use Cases by Extracting Business Rules
Type: Process
Status: final
Version: 2007-11-21
Source: Scott Selhorst on Tyner Blain; Business Analysis Body of Knowledge, Version 1.6; my own experience, also see Wikipedia

Gist: write use cases that do not have to be edited if business rules change. write use cases that can be reused for various purposes, where the purpose is determined by business rules. write use cases that consist of essential, implementation independent statements (as opposed to concrete and implementation dependent). implement solutions that separate volatile rules from the rest of the code.
Note: It requires an explicit decision within the architecture or the design to implement things that way! However, in an agile development, you might not designg for this kind of flexibility unless you are sure it has a business value. This should not keep you from writing the requirements with business rules separated! Writing business rules separately may prod you towards a respective refactoring step.

A business rule
- describes a policy, guideline, standard, or regulation upon which the business operates.
- determines business decisions.
- defines or constrains some aspect of the business.
- is intended to assert business structure, or to control or influence the behavior of the business.
- is atomic, that is, it cannot be further decomposed.
- is not process-dependent, so that they apply at all times.
- normally has a significant impact on business processes, business data and business systems.
Example: "Only users with Level 3 clearance may access the XY-logs".

business rule IS EITHER a
Constraint - mandated criteria such as "the applicant must not be a felon",
Guideline - suggestions such as "the applicant should not have been rejected previously",
Action Enabler - rules that initiate or trigger behavior, like "when the customer's card has been rejected, it must be confiscated",
Computation - the embodiment of calculations, like "pay 1.5 times the wager for a two-card total of 21″, or
Inference - the canonical "if…then" statements

S1: Assume you have a use case with sections of some sort for a description, triggers, preconditions and normal / other flows.

S2: In every section go find statements that constrain the use case. Look for the keywords "must be", "must have", "make sure that", and also "always", "every", "never", "no", "all", "may", "can". 'careful here, make shure that the statement is true, i. e. validate it.

S3: In every section go find statements that enable actions. Look for the keywords "when", "if", "as soon as", "in case", and time triggers.

S4: In every section go find statements that describe computations. Look for factors and divisors, formulas in general.

S5: In every section go find statements that describe inferences: Look for "if ... then".

S6: In every section go find statements that describe default values. ' A classical rule to be implemented as a parameter.

S7: Especially in the flow sections, look at every decision or branch and find the rules that govern the decision making in this particular spot.

S8: Search the Normal, Alternative and Exception Flow Parts for concrete values like keywords, number ranges, states. Their abstractions are the business rules.Note: this also helps with finding the essential steps in a use case.

S9: For every statement found, see if you can extract it into a whole new sentence AND rewrite the remaining part of the description by using a reference to that new sentence. If you can, you have probably found a business rule in that statement. Give it a name and or a number.

S10: Make sure your Business Rules can be clearly distinguished from the rest of the specification.

S11: Consider writing an explicit requirement that requires some robustness concerning the change of these rules.

Do the Right Things

Name: Do the Right Things
Type: Process
Status: final
Version: 2007-09-04

Gist: to provide verification for a feature of a product, a plan of actions concerning the development of a product, or concerning the development of real options.
Note: you can apply this process on various levels of problems and or solutions.
Note: This process optimizes the success in the success equation

stakeholder differentiating: a function or property of the product (or an action of a plan) adds to the overall capability to satisfy the main stakeholders
Note: This means you have to have some notion who the product's main stakeholders are. The stakeholders will accept the product more if the product helps them reaching their goals.
Note: YOU could be the main stakeholder. Then differentiating means options for a wealth of future situations.

mission critical: a function or property of a product (or an action of a plan) is mission critical if the stakeholders will reach one or more of their goals only if the product has it (or the plan caters for it)
Note: This means you have to have some notion of the stakeholder's goals. The stakeholders will accept the product more if the product helps them reaching their goals.
Note: careful, you might presume that some way is the only way.

S1: produce a 2-dimensional space using the above dimensions (mission critical/not mission critical, stakeholder differentiating/ not stakeholder differentiating). This gives you 4 quadrants.
S2: for each feature or sub-feature of the planned product (or action of your plan, or possible step towards your personal goal), ask and answer the following questions: "is it stakeholder differentiating? y/n" and "is it mission critical= y/n".
S3: place it in the quadrants of the space you created in Step 1. You may express more continuous answers than y/n along the axises of your space.
S4: The verfification rules for the four quadrants are:

stakeholder differentiating AND mission critical:
invest and excel. you should do lots of things. put your main effort here. provide the most inner quality.
Note: this is the place where the rewarding things to do yourself are. It is nice to harvest the options you .
stakeholder differentiating AND NOT mission critical:
"good enough" will do. use Pareto. do cheap and easy things.
Note: Will you have the option anyway, whether you do a lot now or not?

NOT stakeholder differentiating AND mission critical:
find a quality partner. use your partner's services. don't do it on your own
Note: Do not expect that your partner gives you many options. However, it is nice to share success (with a business partner or some other partner). Be honest and thankful.

NOT stakeholder differentiating AND NOT mission critical:
do nothing about it. don't waste time and or money
Note: You can use the options that lie here anyway.

10 Principles for UI Design

Title: 10 Principles for UI Design
Type: principles
Status: final
Version: 2007-09-03

Gist: to support good user interfaces. These principles can be used in an attempt to test UI very efficiently without doing usability studies.
Note: In one of my projects we designed a user interface for a handheld device running Windows Mobile. It seemed apparent that it is not useful to mimic a Windows-like UI with windows, tabs and long lists. After the fact I read a lot of 'our' ideas in Jakob Nielsen's article. Thank you!

Source: Jakob Nielsen, thanks to Scott Selhorst


P1 interacting: Does the system provide information about its status? [”Please wait while the system is updating”]
P2 familiar: Does the system use terms and language that are familiar to the user?
P3 oops-tolerant: Can mistakes easily be undone? [”Undo” and “How do I get back to where I was from here?”]
P4 consistency: Does the system use controls (buttons, links, words) to enable actions consistently [”Yes” vs. “OK” vs. “Apply”]
P5 error preventing: Does the system help prevent common user errors?
P6 obvious: Is it easy for users to see what they can do, versus being forced to remember what they can do?
P7 user differentiating: Are there ways for expert users to be more efficient than novice users?
P8 minimal information: Are users forced to filter out irrelevant information (minimalist design)?
P9 useful on errors: Do error messages help users to resolve the errors?
P10 documentation: Is the documentation searchable, task-centric, and precise with “how to” steps?

Kick-ass or at least suck-less Design

Title: Kick-ass or at least suck-less Design
Type: principles
Status: final
Version: 2007-09-03
Gist: to explain how to design kick-ass products (or at least suck-less products)
Source: Michael Shrivathsan, with some minor addition on my side. Thanks to Scott Selhorst for bringing me this stuff.


P1: Start With the User Interface - because this is the only thing your user will see.
P2: Work Closely With UI Designers - because of R1
P3: Pay Attention to Details - because it's part of the success of Apple Computers :-)
P4: Simpler is Better - because more features are worse
P5: Be Brave - because you need something that differentiates your product from the rest
P6: Be passionate about your own product - because if you're not, chances are nobody is.

Means and Ends again

Title: Means and Ends again
Type: citation
Source: Kathy Sierra

What good does it do to master a tool if we haven't understood (let alone mastered) the thing we're using the tool for?

Stripping User Stories for Incremental Development

Title: Stripping User Stories for Incremental Development
Type: Rules
Status: final
Version: 2007-09-03

Gist: explain how to strip down (thin) user stories in order to have more, smaller user stories instead of few, large ones. This is a way to simplify planning releases, as core features can be added to the product earlier than the nice-to-have features. However, keep in mind that product users might like the product for its nice-to-have features.

Note: I find this kind of technique very valuable when being pressed to release. It is relatively easy to apply AND easy to argue about: "with this little time left, we can only provide the really necessary things." My managers liked the idea of getting the basic stuff, but being sure that they will get it far better that the usual "we will do it" and "oh, we couldn't do it" afterwards.
Note: Have you noticed how frequently used yet odd the term "really necessary" is?

Source: Jeff Patton (Agile Development Outside-In), some minor adjustments from my point of view. Thanks to Scott Selhorst for bringing this stuff to me.

R1 Necessity: Find the basic characteristics (course of event) of the user story that is absolutely necessary for the user. It may not be very comfortable, safe, flexible. Make it an own user story. You might want to mark it "Necessities".

R2 Flexibility: Find all options in the original user story that might make the feature more applicable in different situations. Make a user story each. You might want to mark it "Useful options".
Note: There really is no point in combining independent options into one story just because you don't want to have "so many stories".

R3 Safety: Find all the little features that add to increased data quality, prevent inappropriate actions, prevent trouble downstream from the spot. Make an user story each. Sometimes it is easy to combine these kind of topics into one user story with one common business value, like "ensure data quality". This business value can also serve as a name tag.

R4 Comfort, Performance: Find things that make it easier for the user to use the product. Also consider the next occurrance of the user story in the user's life (like if I can save these settings now, I can use them again later). This is where Kano's exciters come in. Products win usability awards here. Add a user story each. You might want to mark it "Added Comfort" or "Improved Performance".

Describing Alterantive Courses of Action in Use Cases

Title: Describing Alterantive Courses of Action in Use Cases
Type: Rules
Status: final
Version: 2007-08-28
Gist: explain how to model alternative corses in use cases, which can be represtented in purely textual, tabular and grafical fashion. Use case descriptions should provide both an overview and a detailed view. They should clarify for the reader a certain set of scenarios. The use cases context is a set of constants.
Definition: Scenario: one single complete path through the use case
Source: David Gelperin (Modeling Alternative Courses in Detailed Use Cases, LiveSpecs Software, 2003), Tom DeMarco (Structured Analysis and System Specification, Prentice Hall PTR, Upper Saddle River, NJ, 1979), some minor adjustments from my point of view.

R0: The general size rules for use cases apply.

R1: An alternative course of action is either of four types: {Exeption Handler, Required Selection, Optional Action, User-invoked Interrupt}
Exeption Handler: a scenario with an exeption handler does NOT yield a useful business result; in the sense of the use case.
Required Selection: The actor or the system has to select from a number of options and the chosen option determines the next segment of the scenario. the scenario will yield the useful business result in the sense of the use case unless another alternative course says otherwise. It is possible to state "do nothing" as an option, but only if this is not the most frequent option. If it is, use optional actions instead.
Optional Action: some possible segment is included in the scenario. It does yield a useful business result in the sense of the use case.
User-invoked Interrupt: The actor decides to continue with a scenario of a different use case. This other use case has to be described if part of the system. There is NO useful business result in the sense of the use cases (but maybe of the other use case)

R2: There is exactly one sceanrio that represents the most frequent course of events. ' aka main scenario

R3: Each start of a segment of a scenario is associated with a number between 1 and 99. It represents the probability of this segment to occur. The number is the analyst's best guess. Fill it in square brakets.

R4: The sum of all probabilities of a decision point is 100.

R5: Exeption Handlers[text] should begin with "UNLESS". Exeption handlers[graphics] should be signalled by the term "exeption" near the transition between decision and first action of the handler.

R6: Required selection[text] should use IF-THEN-ELSE-clauses. Required Selections[graphics] include an action preceeding the decision, that provides the selection

R7: Optional Actions[text] should use a short and descriptive name in square brackets, placed at the point(s) of insertion into the main scenario. Optional actions[graphics]: same..

R8: User-invoked Interrupts[text] should include an explicit link to the other use case. User-invoked Interrupts[graphics] should make use of "goto" marks

R9: Each use case is supported by real world numbers of its occurence.

Communicating Plans in Agile Development

Name: Communicating Plans in Agile Development
Type: Rules
Status: final
Version: 2007-08-23
Gist: How to communicate a release or iteration plan to team members and to management
Source: Mike Cohn (Agile Estimation and Planning, 2006), my own tested ideas.

R1) You should communicate often, a plan is there to change. This keeps you updating the plan.
R2) You should communicate honestly, you want trust among your team and your bosses.
Note: Agile Planning is about providing real options. Don't get trapped in your own inappropriately communicated release dates.
R3) Make sure communication is two way. It's much easier to get a commitment from everybody if you involve people.
R4) If you're using Gantt charts, try to get away with a plan of milestones only. There may be lots of small milestones between the bigger ones. You may render the plan more readable if you include activity bars between milestones. They should not be connected to the milestones.
Note: remember, the bars are for readability only.
R5) If you're using Gantt charts, don't show a work breakdown structure; do a feature breakdown structure instead. Don't show individual's tasks.
R6) If you're using Gantt charts, show each feature with the lenght of the iteration.
Note: Some tasks relating to the feature will start at the beginning of the iteratioen. The feature will be finished at the end of the iteration, not earlier.
R7) Talk about a due date with a specific degree of confidence or by using a range or both. You may want to use the 50% and 90% confident numbers.
Note: This correctly reflects the degree of uncertainty that is inherent in future.
R8) For communicating or predicting feature burndown, use three numbers: velocity of the most recent iteration, average velocity of the last 8 iterations (or as many as you have, if less), average velocity of the worst 3 iterations.
R9) In reporting or planning test results, use either the number of passed tests (if all tests passed) or the number of failed tests (if at least one has failed).
Note: It does not make sense to report or plan based on failed tests vs.passed tests. In test-driven or even behavior-driven development, a feature is considered finished if and only if all it's tests pass. There's no 'finished to a degree'. You're aiming at zero defects.

12 Tough Questions for Waterfall Projects

Title: 12 Tough Questions for Waterfall Projects
Type: principles
Status: final
Version: 2008-08-22
Gist: to show waterfall projects what they are missing; to show waterfall projects that say they have always been 'agile', that they really have not.
Source: I stole the idea from Tom Gilb's (generic) 12 Tough Questions.

1) why aren't you able to show some useful piece of product after less than 10% of scheduled project time?
2) how do you know that you will hit the scheduled delivery date, at the start of the project?
3) how productive is your team, in terms of features delivered per month? why don't you know?
4) how do you prevent gold-plating before all the necessary features are done?
5) do you know how many defects you have implemented in the latest version of your product? why did you implement those?
6) what if you want to choose between fixed-date and fixed-scope near the end of your schedule?
7) how long does it take you to know wether a change to the system caused ripple effects?
8) how do you know that every feature you deliver is useful by the date of delivery?
9) why aren't you able to deliver a useful system halfway through the project schedule if management wants you?
10) why isn't your team committing to deliver the feature set planned for the project?
11) if the requirements will change anyway, why do you write them down way in advance?
12) do you pay your contractors cash money, even if they have not provided you with a valuable solution to your problem yet?

Humane Interface Design

Title: Humane Interface Design
Type: Principles
Status: final
Version: 2007-08-22
Gist: guiding you in making decisions when designing a user interface.
Source: An article on Shmula on humane interface design. I stole it completely because I like them so much. Did not add anything.

P1) It's not your fault.
P2) Simple things should stay simple.
P3) Fewer choices mean fewer worries.
P4) Your data is sacred.
P5) Your train of thought is sacred.
P6) Good interfaces create good habits.
P7) Modes cause misery.

Do Job Interviews Efficiently

Title: Do Job Interviews Efficiently
Type: Rules
Status: final
Version: 2008-08-22
Gist: selecting people to join your project team in an efficient and fun manner

R1) invite all candidates at once
R2) talk to the group, let the group talk to itself
R3) wait for the silent people to be asked questions by other people
Note: You will need to explain the project only once. You will feel the people you want to be with in a couple of minutes anyway.
You will save time.

Reviewing for content

Title: Reviewing for content
Type: principles
Status: final
Version: 2007-07-26
Gist: Conduct reviews in the right order.

P1: check formal characteristics
P2: only if the object is clean, it's useful to see if it's right

Optimizing subsystems does not help optimizing IT costs

Title: Optimizing subsystems does not help optimizing IT costs
Type: theory
Status: final
Version. 2007-07-26
Source: Chris Matts, Gilb Seminar, London, 2007

The IT world is misperforming when trying to optimize IT costs, because when one subsystem is optimized normally the performance of the surrounding systems decreases.
We have to optimize the whole.
At Toyota, they even optimized their suppliers (and customers?).

Same thing with single projects. Most of the time it is easier to solve a problem by means of thinking out side the box of this praticular project.

Go Agile, Enterprise Wide

Title: Go Agile, Enterprise Wide
Type: Rules
Status: final
Version: 2007-07-26
Source: Pollyanna Pixton, talk at APLN 2006, Gerhard Wohland, Niels Malotaux, my own thoughts

R1: make sure the individuals in the enterprise want to learn and are allowed to learned
- unleash creativity
- lead change (not adopt to change)
Note: since business is global now, you have to put pressure on competitors if you want to sustain and succeed. You cannot just follow, because your market share will be eaten up by others.

R2: prioritize: all decisions are based on business value
- what is the most valuable thing to do *now*
- change lubricant slogan: "take the fun out of being disfunctional"
- finding business value of new products: give the product away for free

R3: do cascading agile:
- Do a business-level roadmap cycle every 3-6 months. "Do the tactical objectives still comply to the enterprise's strategic plans?"
- Do a project-level tactical cycle every 1-3 months. "Does our business unit / project still comply to the tactical objectives?
- Do a delivery-level cycle every 2 weeks or less. "Are we moving towards the right product?"
- Do a task-level cycle every 1 week. "Are we doing the right things in the right order?"

R4: Iterate: Review Goals and Objectives
Principle 1: full transperancy, give all information to everybody
Principle 2: fail early, fail fast!

Being agile on offshoring projects

Title: Being agile on offshoring projects
Type: Process
Status: final
Version: 2008-05-13
Gist: How to implement agile across distributed teams.
Note: Keeping productivity in mind it is really not advisable to distribute teams. Expect half the productivity you could otherwise expect from a team.
See Agile Advice for tips on proper room design.

S1: produce a feature list
S2: Give the offshore team a tiny (2-3% of total size) bit of features
- prioritized based on business value

S3: write the test cases, give them to the offshore team

S4: use focus groups

S5: if the features are delivered, go back to the feature list and ask the focus group: do we have enough business value?

Leadership

Title: Leadership
Type: Principles
Status: final
Version: 2007-07-25

P1) Step aside and let your team members work
P2) Only do 2 things
- make shure everybody has what they need to succeed
- create a place where people want to be

Note: If your people are passionate about what they are contributing to your endeavor, THEY will work things out (better than you can). You just sit and watch!

Note: It is a leader's responsibility to protect the team from leaders higher up in the food chain, that are trying to dictate how to do things.

Good Practice in Writing Acceptance Criteria

Title: Good Practice in Writing Acceptance Criteria
Type: Rules
Status: draft
Version: 2007-07-15
Gist: To explain, how to produce useful acceptance criteria.
acceptance criteria (AC) DEFINED AS a means to express the important tests for a product or system from a behavioral point of view.
Sources: Dan North, Chris Matts, Dave Astels, my own practice.
Note: Writing acceptance criteria is not about specifying tests and not even about preparing for writing test cases. Instead, it's writing specifications of behavior.

R1: Use the standard form "given [Context] when [Event, Feature, Function] then [(expected) Outcome]".
R2: Write one AC for every single expected result. If you end up with more results per AC, try making the contexts more specific. Gist: By keeping the AC small and focused, they are easier to refactor.
R3: Don't just have one AC per feature, that says "everything turns out perfect". You need one per specific context.
Note: This rule seems ridiculously self-evident, but my recent experience while working with an "experienced" requirements analyst shows that it isn't...

Clear Conceptual Writing

Title: Clear Conceptual Writing
Type: Process
Status: final
Version: 2007-07-15
Gist: To explain how to amplify skills for writing information texts (not fiction or poetry). You can apply it to the introductory or explaining parts of requirements and design specifications.
Source: Michael Covington and my own experience.

S1: Planning: Decide what to write about. It's not important to have a very clear idea about the subject yet. It will evolve.
S2: Planning: Decide, for whom you are writing. if you don't know much about your audience, go and find out first.
Note: Writing is about transferring ideas. Although it can be used as a thinking tool for yourself (like this blog), it was invented to express ideas for others to read. Keep in mind that your writing tells something about you, whether you make it easy for you or easy for your audience.
S3: Planning: Every section has a purpose.
S4: Drafting: Write everything down. So you don't have to juggle with ideas in your head.
S5: Drafting: Concentrate on the what, not the how. It's okay if only you understand what's on the paper.
S6: Drafting: Get to the point. Say the main point of every paragraph in its first sentence, then provide the reasoning that leads to the main point in the following sentences.
Note: Mark Twain once said "Establish the facts first! You can mess them up afterwards."
S7: Revising: Make your text as easy to read as possible. Use someone who does not know about the topic to find out if it's understandable. Your kids or your gandparents should be able to understand what you say.
S8: Revising: Shorten your sentences. Then shorten them again.
S9: Revising: Think of ways how your sentence can be misunderstood, e. g. by reading it aloud several times and stressing different words in each pass.
S10: Editing: Fix the grammar, spelling an punctuation.
S11: Formatting: Keep it simple and standard, avoid meaningless variation.

Evolutionary Development, Waterfall and Change

Title: Evolutionary Development, Waterfall and Change
Type: Principles
Status: final
Version: 2007-07-10
Gist: Explain which conditions make a case for evolutionary development.
Source: Scott Selhorst on http://tynerblain.com/blog/2007/07/09/enabling-and-resisting-change/
Find a less brief description of Evolutionary Development here. http://kw-agiledevelopment.blogspot.com/2007/06/scrum-agile-development-uncommon-sense.html

P1: Evolutionary Development can very briefly described as:
Decide what needs to be done.
Do the most important things first.
Release the product incrementally as you complete items.
Re-evaluate and repeat.

P2: Waterfall Development can very briefly described as:
Decide what needs to be done.
Do things in an efficient sequence.
When finished, release the product.

Note: Kelly Waters descibes waterfall as: "Seeking to complete *everything* before releasing *anything*."

P3: There are at least 3 types of change where, if they occur, evolutionary development is better in handling than waterfall development.
Change in business needs (less frequent, large change each)
Change in requirements (frequent, medium change each)
Change in business rules (more frequent, small change each).

Risk and Uncertainty

Title: Risk and Uncertainty
Type: Principles
Status: final
Version: 2007-07-27
Gist: Provide a set of principles on how to tackle risk and uncertainty
Source: Matthew Leitch's Online Survey on 'Indivudual differences in risk and uncertainty management' (http://www.internalcontrolsdesign.co.uk/rumaresults/index.html)

P1: Objectivity and rationality are desirable.
P2: We usually face risk and uncertainty and need to acknowledge this and act in accordance with it.
P3: Focus on single future outcomes is usually at the expense of an objective view of the future, which requires a recognition of uncertainty.
P4: It is better to be honest.
P5: These considerations are very important and usually outweigh others.

Note: Sven Biedermann offers the notion of 'a project without risk and uncertainty isn't a project'.

Humbling Exercise on Estimation

Title: Humbling Exercise on Estimation
Type: Process
Status: final
Version: 2007-07-27
Gist: show the participants of the experiment that they are not very good at making estimates and not very good at knowing what the requirements for a solution are
Source: Niels Malotaux, Gilb Seminar on Decision Making, London, UK, 2007

S1: Explain the 'project': "multiply 2 numbers of 4 digits each, on paper". Every participant will conduct the project on his or her own.
S2: Ask for everybody's estimate, how long the project will take to be finished.
S3: Everybody shall measure the time needed, from reception of the requirements to delivery of the result.
S4: Give the requirements: "The numbers are: 4-5-6-7 and 9-8-7-6".
S5: Let them re-estimate.
S6: Interrupt them now and then by talking, because this happens to every project.
S7: Yot down the times needed.
S8: Ask if they have testet the result. Make them test their results and take the time again.
S9: Add the times and compare them to the original and second estimates.
S10: Show them a solution to very different requirements. Make something up, like changing the order of the digits.

Note: There are a couple of interesting questions to ask here.
Like "What does 'finished' mean?",
"What was the reason for the adjustment of the original estimate?",
"What was the impact of the interrupts?",
"Is it rational to forget testing, and why does it happen all the time?",
"Why were we assuming that we really understood the requirements?"

Reducing the size of power point presentations with pictures

Title: Reducing the size of power point presentations with pictures
Type: Process
Status: final
Version: 2007-07-04

S1: Right-Click on one of the pictures.
S2: Pick Properties.
S3: Click on Compress...
S4: Choose "all pictures" and a flavor of compression you like

Prioritizing Use Cases

Name: Prioritizing Use Cases
Type: Principles
Status: final
Version 2007-08-23
Gist: using a smart way of finding out the use cases to start with
Note: You are not supposed to use all principles at once. Focus on 1-3 principles. Discuss with your sponsor, which principles you should use. Proposal: use 2 principles to find the initial order. Use a third principle to move use cases forth and back in this order.
Note: You may want to replace 'use case' with 'feature'.

P1: a key stakeholder is an actor to the use case
P2: the actor has been determined as 'primary'
P3: the use case's development is particularly risky or it's attainability is uncertain (due to technical or organizational issues, for example)
P4: it is a use cases within a core business process
P5: the use cases yields high business value
P6: the use cases yields high ratio of business value to costs
P7: there is a business related dependency to another use case wich uses the business results of the first
P8: the use case is part of a business process and it makes sense - from a business point of view - to first complete all use cases for this process
P9: the team can gain knowledge (about the domain, the project, the product) from implementing a use case

Finding key stakeholders

Name: Finding key stakeholders
Type: Process
Status: Draft
Version: 2007-05-24
Gist: How to find the stakeholders who should be treated special.

S1: Brainstorm all possible stakeholders
S2: Find the stakeholders who will be the greatest in number.
S3: Determine the 1-5 stakeholders who will impose the highest risk of rejecting the product.
Note: The product may be good, but stakeholders can still make your product development a failure. See this formula.

Principles of Modelling Static OO-Models

Name:Principles of Modelling Static OO-Models
Type: Principles
Status: Draft
Version 2007-05-24
Gist: good practice guidelines in case you want to model the static view of a system, on business level

P1: Only model what you think is really important to say. There are a thousand ways of modelling some part of reality.
P2: Don't put more than 5-9 important elements on a page. Go to a hardware store if you need new wall papers.
P3: Each model should not exceed one physical DIN A4 page (US: letter format; some say DIN A3, which is twice the US letter format). Use multiple models of you really need them.
P4: Model cohesive parts as one unit (class). Parts are cohesive if they are (almost) always together, like user first name and user family name
P5: Loosely couple non-cohesive parts
P6: Every class, every association and every generalization has a business requirement that makes it necessary
Note: Careful here, you have to decide whether you want to model "the world" in general, or with the specific system in mind. Don't mix up things you know about the world with something you need because you have requirements stated for it. If you feel you really need a relationship, go and find that requirement. This is called the art of leaving things out of the model. (<- Guido Zokoll of www.OOSE.de)

P7: Think twice before using aggregation and composition. As Rumbaugh put it, aggregation is a way of saying something about your personal point of view

P8: Think twice before using a generalization if you cannot come up with a discrimminator for it within 30 seconds.
P9: Be extra careful with multiple inheritance.
P10: A lot of <<include>>s are a symptom of functional decomposition (<- Ivar Jacobson)

Finding the right size for a use case

Name: Finding the right size for a use case
Type: Rules
Status: finished
Version: 2008-03-28
Source: www.oose.de
Gist: find out whether a given system use case isn't too large and not too small.

R1: Each use case has a business trigger
R2: Each use case yields an externally observable result that is useful for the business
R3: Each use case is coherent by time
Note: R3 means the use case passes the lunch break test: the primary actor wouldn't take her lunch break while in the middle of the execution of the use case steps.

Calculating Success

Name: Calculating Success
Type: Principles
Status: finished
Version: 2007-05-24
Source: Guido Zokoll, www.oose.de
Gist: how to find out, whether a product is a success.

P1: success = inner quality * stakeholder acceptance
Note: Agile developments specifically adress the stakeholder part of the equation.

Estimating ROI

Name: Estimating ROI
Type: Principles
Owner: RGZ
Status: Draft
Version: 2007-05-24
Gist How to estimate the return of investment for a product/project

P1: If you don't have to express value in dollars and cents there's no sense in expressing costs in dollars and cents. <- Tom DeMarco, "If the value is 'we need it', then costs are irrelevant."

BUFR (big up-front requirements)

Name:BUFR (big up-front requirements)
Type: Principles
Status: Final
Version: 2008-03-27
Gist: How to use the BUFR approach in order to hinder change, to avoid focus on business value, to create thrashing, to facilitate no longer valid requirements and to create high risk.

P1: Try to find, document and analyse all requirements for a non-trivial system development before you do anything else

Changing Requirements with Fixed Price Contracts

Name: Changing Requirements with Fixed Price Contracts
Type: Rules
Status. Finished
Version: 2007-05-23

Gist: A way of changing requirements even if a fixed price contract has beed agreed upon.

R1: The total effort does not change.
R2: The customer has to specify each change to a level of detail which is suitable for being estimated
R3: The supplier estimates the change, yielding an effort of X.
R4: The customer has to exclude not yet developed requirements from the contract with the same value X.
Note: This is based on mutaul trust. If you need an extrodinary complicated or hard to agree to contract, you should probably don't try this.

Naming Use Cases

Name: Naming Use Cases
Type: Rules
Status: Draft
Version 2007-05-23
Gist: Finding a good name for a use case

R1: use the form "<verb> <subject>", e.g. "change reservation"
R2: use <subject> in the correct number (singular/plural): if the actor typically processes several subjects without interruption (due to lunch break, due to end of the day, etc.), then the subject should be in plural. E. g. "insert reports"

User-Centered Development / Personas

Name: User-Centered Development / Personas
Type: Rules
Status: finished
Version: 2007-05-07
Source:
www.disambiguity.com/yes-you-should-be-using-personas/
www.evolt.org/article/Practical_Persona_Creation/4090/56111/index.html

Gist: support the concept of user personas for requirements definition and for getting rid of the elastic user
Note: You can also use your personas {for prioritizing tests, to evaluate new ideas for features, for requirements triage, for writing the user manual] (not a complete list).

R1: User personas should be created to find the "edge cases", use cases that make a difference within the product. Wipe out featuritis with your personas.
R2: Personas should be created with the help of stakeholders.
R3: Don't overdo it (1-3 sentences). Don't define too many (2-6).
R4: You need a complete buy-in on the personas from people who are supposed to use them
R5: Do *some* creative writing when creating personas. Small details matter.
R6: It helps putting a name and a face to the personas. Go out and take photos or cut out magazine pictures.
R7: Group personas as 'primary' (the majority, the most important) and secondary (very different from the primary personas but still very important)

Hume on Ambiguity

Name: Hume on Ambiguity
Type: Citation
Status: finished
Version: 2007-05-04

"From this circumstance alone, that a controversy has been long kept on foot, and remains still undecided, we may presume that there is some ambiguity in the expression, and that the disputants affix different ideas to the terms employed in the controversy."

Source: David Hume, An Enquiry Concerning Human Understanding, Section VIII, Part 1

How to Determine if a Requirement is Atomic

Name: How to Determine if a Requirement is Atomic
Type: Rules
Status: finished
Version: 2007-05-07

Gist: Atomic requirements are a prerequisite for specs of product lines, of concurrent product releases, and of developments, in which requirements are likely to change during one release of the product.

R1: A requirement is likely to be atomic if you cannot say "this requirement is partially implemented".
R2: A requirement is likely to be atomic if it decomposes a higher-level requirement AND you can justify it by saying "if I don't write it like this, the higher-level requirement wouldn't make sense" (not: is incomplete, or is unspecific).

Note: R2 also tests that the requirement isn't specifying a superfluous solution to the higher-level requirement.

Eisenhower on Plans

Name: Eisenhower on Plans
Type: Citation
Status: Draft
Version: 2007-05-07
Source: <?>

"In preparing for battle I have always found that plans are useless, but planning is indispensable." - Dwight D. Eisenhower

Change and Software are Twins

Name: Change and Software are Twins
Type: Principle
Status: finished
Version: 2007-05-07
Source: Tom and Mary Poppendieck, Implementing Lean Software Development, Addison Wesley 2007

From the word 'software' alone can be deducted that this part of an IT system is likely to change. Otherwise it would be implemented in hardware.
Note: Thus, change is nothing that is new, be it due to shorter time-to-market, due to increased market pressure or due to quickly fluctuating stakeholder opinions. It's always been characteristic to software. And that's way the ever popular comparison of designing software systems with architecting a house is not at all appropriate.

Effort Needed for Product Enhancements

Name: Effort Needed for Product Enhancements
Type: RuleSet
Status: finished
Version: 2007-05-04

Gist: Calculate Effort from # of Function Points, for Enhancements

R1: The Capers Jones Formula for Effort E of new Products (in person months): E = (# Adjusted Function Points)^1,4 / 150
R2: Enhancements of products cannot be calculated with the same formula, as you need to take into account that you add complexity to an existing product.
R3: Formula for the needed EnhancementEffort EE for an Enhancement of y function points to a a base product of y function points:
EE = E(x+y) - E(x)
Note: Obviously you need to know y and x. The greater x is, the more significant is the difference between E and EE.

Testcase Numbers based on Function Points

Name: Testcase Numbers based on Function Points
Type: RuleSet
Status: finished
Version: 2007-05-04
Source: Internet, IFPUG-Website, Capers Jones

Gist: Calculate the number of test cases for a reasonably tested product.

R1: # of test cases = (# adjusted function points)^1,2
R2: # of acceptance tests = (# adjusted function points) * 1.2

Avoid Requirements-related Defects in IT-Systems

Name: Avoid Requirements-related Defects in IT-Systems
Type: Process
Version: 2007-04-20
Referring to: Principles for Requirements Engineering Tasks.P3
Source: Sorry, I know I used somebody else's material here but I failed to write the source down. If you feel like "hey, that's my idea" please let me know and I will be more that happy to properly credit you.

Note: The sooner a defect ist detected, the cheaper is its removal. This is a well known fact, nicely pointed out by for example by this article at Tyner Blain <…>. Why? Because in systems engineering usually things are described more than once - from different perspectives. As a rather coarse requirement, as an architecture, as a detailed requirement, as a design, as a test, as code, in manuals. The more of these artifacts have to be changed due to a defect, the more expensive. Add the cost of bringing the system to the user.
Therefore it is a good idea to avoid defects in the first place.

Concerning requirements, defects occur in 4 different steps in the process:
S1: When stakeholders incorrectly or incompletely define their requirements.
S2: When analysts document the requirements incorrectly or incompletely. Writing good requirements is not too difficult.
S3: When developers write unit tests that test the wrong implementation. Even very effective methods of continuous integration then result in very effective testing of the wrong thing.
S4: When testers make sure, that the wrong requirements were implemented or that nat all of the requirements were realised. Then we waste our time by testing for requirements that aren't really requirements

What do we do about it? We add feedback cycles accordingly:
S1: We focus on the ROI, so the stakeholders concentrate on the important requirements. Using different requirements gathering techniques on the same stakeholders help a great deal. Stakeholders oficially approve the requirements that were documented by the analysts. (BTW, that means that the requirements must be readable by stakeholders)
S2: We use a strict Specification Quality Control process to make sure we get well written requirements. One or more analysts approve the work of one other analyst. The ultimate goal in doing so is to improve the author, not the specification itself.
S3: intensive communication with analysts and architects helps developers while comprehending the requirements.
S4: Test cases and test data will be approved by the analysts.

Nonfunctional requirements and level of specification

Name: Nonfunctional requirements and level of specification
Type: Theory
Version: 2007-04-18
Source: My friend Sven

"The higher the level of a system's requirements specification, the greater the portion of non-functional requirements."

This is, because no computer system can directly realise a non-functional requirement; it has to be broken down to a set of functional requirements. This set interacts and thereby attains (or does not attain) a certain non-functional attribute.

Sven's sentence describes a necessary characteristic of good specifications. In other words if you find a high-level spec with few or no non-functional requirements, it does not mean it is not high-level. It probably means that the author forgot to include non-functional requirements.

Also, "portion" is maybe not the correct term (he used the German "Anteil"), but I think the idea is clear.

Signs and Symbols

Name: Signs and Symbols
Type: Explanation
Status: Draft
Version: 2007-04-18
Rationale: This blog makes use of Planguage, a planning language from the Gilb family.

Here's my dialect:

E Entry-Condition
S Step in a process
P Principle
R Rule
X Exit-Condition
[…] Qualifyer, Condition
<...> not sufficiently specific
or
{…} set of things
F(x) s.th. that has been derrived from x using a function F
' commentary text afterwards
italics commentary text

Principles for Requirements Engineering Tasks

Name: Principles for Requirements Engineering Tasks
Type: principles
Status: finished
Version: 2007-04-28
German: RE-Prinzipien

The RE in my projects follows these guidelines:

P1: Requirements are driven by business; technical aspects or solutions to problems never constrain requirements without a clear, documented cause.
P2: Requirements with high business value will be analysed and realised first.
P3: We avoid defects in the system instead of testing them out.
P4: (Potentially) controversal discussions take place as early as possible. Unclear, risky or hard to describe requirements are analysed early.
P5: Bandwidth will be maximised while communicating requirements and while communicating on requirements.
P6: If a rule, standard or other regulatory asset - whether it originates from the outside or inside of the project - hinders understandability of a requirement, the rule will be ignored.
P7: Solutions (Designs) to requirements can occur, but only as suggestions w/o any legal consequences.
P8: The (document) "Requirements Management Plan" will be improved continuously.
P9: ruleset.PrioritizeInEvoDevelopments applies

Evaluate the presentations

Name: Evaluate the presentations
Type: rule set
Status: Draft
Version: 2007-04-18
Referring to: Process.Call for tenders

R1: Have the presentations scheduled with little time between them.
R2: Again have different evaluation tasks assigned to the people on the team (e.g. According to their roles in the project)
R3: Have a list prepared with questions you will definately ask each supplier
R4: be strict about presentation time

Evaluate the tenders

Name: Evaluate the tenders
Type: Rules
Status: Final
Version: 2008-03-28
Referring to: Process.Call for tenders
Source [R8]: Curt Finch, Will Your Potential Software Vendor Meet Your Requirements?

Note: In one of my projects, we evaluated the written tenders first, then the presentations. Step 2 yielded a substantial change in our evaluation results. This can be taken as a hint, that written statements are not very well suited for these purposes.

R1: Has the supplier really anticipated the specific problem? Note that it can be hard to find the individual information among the heaps of tandard text in a witten tender

R2: Again have the the evaluations tasks divided and assigned to different team members

R3: you can evaluate the categories {form, content, sensed quality}
Note: For evaluation, you can something similar to Simple Solid Decision Making. We once used the following simpler, but less solid scheme:
- count: small and large problems with the tender's text, quastions not answered, good points
- give school grades
- build a ranking
Your provider management or purchasing dept maybe can supply you with a spredsheet for that.

R4 [too many suppliers on the list for presentations]: use ranking

R5: Encourange communication among the evaluation team

R6: explicitly allow "subjective" statements (the whole evaluation is kind of subjective). This works towards keeping subjectiveness out of the other criteria

R7: [lots of questions by suppliers]: give a chance to improve the tender (Do that by gathering all questions anonymously , answer them and send them back to the suppliers. Or, better, improve your spec and resubmit it)

R8: [doubts whether the statements about the past are true]: check their references. Be suspicious if references call YOU. Be suspicious if a reference uses an email address from Yahoo!, Hotmail, ... Get a company phone number and call their main number instead of the references' individual number. Do a web search on the company's name and check their website. Call ALL references.

R9: Mind that recent research shows, that decision making is not independent from your emotions

Send the call for tenders

Name: Send the call for tenders
Type: rule set
Status: final
Version: 2007-04-26
Referring to: Process.Call for tenders

R1: make use of professional help
- purchasing department can be used to reduce prices
- provider management department can provide a longlist of possible suppliers

R2: The suppliers on the longlist should be evaluated. Check references the suppliers give on their website or that has been obtained by ther key account manager. Ask tough questions! This results in a short list.
R3: Have the call for tenders sent to all suppliers at the same time to avoid legal problems. Your provider management may well have a standard letter to use, in order not to forget anything.
R4: Allow questions. Handle this rather formally, because you want to redistribute questions and answers to the suppliers.
R5 [fear of unwanted phone calls by suppliers]: Don't forget to exclude your mobile phone number from you email :-)
R6: publish the dates for the supplier's presentations
R7: direct communication to 1 or 2 persons only (on both sides)

Prepare Call for Tenders

Name: Prepare Call
Type: rule set
Status: final
Version: 2007-04-26
Referring to: Process.Call for tenders

Note: Even a call for tenders benefits from sound planning!

E1: A list of evaluation criteria has been assembled an agreed upon by the team and its management.
E2 [COTS]: the requirements have to be defined and prioritized. Note: the supplier's proposals should clearly state which part of the product fulfills which requirement, to what extent.
- also keep total cost of ownership in mind
- don't just care for functions ("what"), but also think of quantified requirements like performance attributes (see DIN 66272, "how well"), resource attributes ("how much"), and general system architecture (check references given).

R1: Experts and stakeholders should be with the evaluation team.
R2 [no expertise]: Go get external know-how, from other parts of your company or even from outside.
R3: Again, get management involved (e. g. get constraints, imform regularly, invite them for the supplier's presentations)
R4: Clearly assign tasks concernig the call itself and its evalution to individual team members. Set deadlines.
R5: Consider preparing a document template to be filled by the suppliers.

Call for tenders

Name: Call for tenders
Type: Process
Status. Draft
Version: 2007-04-18
Rationale: This process can be used as a guideline for issueing and evaluating a call for tenders. It is suitable for requesting projects, products or other external services. It describes WHAT to do (the process itself) and what should be on your mind while doing it (resp. rule sets).

Note: A project I supported recently did a call for tenders in mid 2006. They wanted an external supplyer to develop a part of a IT system. The experiences gained during the time and some older experiences in requesting proposals for hardware components and COTS products went into the following descriptions.

E1: Management has stated or validated the need for an externally supplied solution.
E2 [COTS]: The requirements for the product has been (big-up-front-requirements, BUFR) and the people concerned really understand that defined requirements will change (by a rate of 2-3% per month).
E2 [others]: the requirements for the project or other service are defined.

S1: prepare the call
S2: send the call
S3: evaluate the tenders
S4: evaluate the supplier's presentations

X1: One supplier has been chosen.
X2 [COTS]: the specification has been updated.
X3: The time invested in the call for tenders (between preparation and descision) has not exceeded 5% of total projected time for the project

Note: in the project mentioned above preparation took 2 weeks, the suppliers had 2 weeks to answer, we needed 1 week for evaluation, added an extra chance for improvement for the suppliers (1 week), presentations 2 days, final evaluation and descision 1 day. This sums up to 6+ weeks or nearly 10% of total projected time for the project.

About me

I'm Rolf, born 1971 in Germany.
My studies in computer science ended quite successfully with a thesis on linguistic methods in requirements engineering. I got employed right away by the SOPHISTs, Germany-based consultants spezialising in requirements engineering. There, I was responsible for doing requirements work, later also organising requirements work, then also educating people about requirements work. As a nice by-product, I had the chance to co-author several books there.

After a couple of years I decided that this was enough consultant's work, went to Asia for a small sabbatical, and then joined Deutsche Post World Net. A rather large group that does logistics worldwide. I currently work there in the IT department for the MAIL subdivision. Right in the middle between stakeholders and developers, again I do and organise requirements work, and the aspect of informing colleagues about my ideas and methods got so strong finally, that I decided to start this blog. Please note that everything I write here is my own private matter, and that it does not in any way represent terms or other regulations of my employer.

In general, I'm interested in requiremets engineering and systems engineering. One of my strongest beliefs is that the IT world would be an even nicer place to be, if its people stopped telling stakeholders which solutions they have, and started to listen to the problems.
It would also help a great deal if more IT people started clear conceptual thinking.

About this blog

I started this blog for two reasons:

First, I needed a way to involve my colleagues. Before I kept all what appears as single posts in the blog with my private files on my computer. When I wanted to show something to someone, I had to send it by email, it wasn't always up-to-date etc. So I use the blog to communicate ideas.

Second, I needed a way to keep track of my ideas, preferably in a structured searchable manner, while I don't have my computer with me. So I use the blog to organise my work.
Please note that everything I write here is my own private matter, and that it does not in any way represent terms or other regulations of my employer.

I like the idea of the Robertsons: they called a little competition in 2005 named "stand on my shoulders". This is my list of personal exemplars. As I am proud of standing on the shoulders of so many clear conceptual thinkers of the recent and not so recent past, with equal pride I like to see that some of my ideas will have been build upon by others. This is a way to achieve eternal life.

Along these lines, this blog is constructed by recycled material to a great extent. I add my bit wherever I find it useful. However, some of other people's ideas cannot be improved as of now.

Enjoy!

Lean Product Development

Type: RuleSet
Status: final
Version: 2007-04-20
Souce:http://www.shmula.com/340/lean-for-software-interview-with-mary-poppendieck

R1: Flow (or low inventory, or just-in-time) (inventory DEFINED AS something partially done)
R2: no workarounds, problem exposure
Note: In case of problems you don't avoid but solve them. This may mean you have to stop.
R3: Eliminate Waste (waste DEFINED AS {something without value to the user, work partially done, extra feautures you don't need right now, stuff that causes delay})
R4: Deferred Commitments (DEFINED AS idea of scheduling decisions until the last moment when they need to be made, and not making them before that, because then you have the most information. Note: Mary called it 'delayed commitments', but to my ear that's too close to 'too late'.)
R5: Deliver Fast (DEFINED AS being able to quickly release software. You need proper procedures for that, like {excellent testing procedures, automated testing, stuff that is disjoint from each other (so as you add features you don't add complexity)}

RE-Prinzipien

Typ: Regel-Satz
Status: finished
Version: 2007-04-28
English Principles for RE Tasks

Das Anforderungsmanagement von folgt folgenden Prinzipien:
R1: Die Anforderungen werden fachseitig vorgegeben und nur wo notwendig technisch oder durch Lösungen eingeschränkt.
R2: Zuerst werden die fürs Geschäft wertvollen Anforderungen analysiert und realisiert.
R3: Fehler im System werden vermieden, nicht herausgeprüft.
R4: (Potentiell) kontroverse Diskussionen werden so früh wie möglich geführt. Unklare, riskante oder aufwändig zu beschreibende Sachverhalte werden so früh wie möglich geklärt.
R5: Die Bandbreite in der Kommunikation der Anforderungen und über die Anforderungen ist so groß wie möglich.
R6: Wenn eine Regel, eine Festlegung oder ein Standard, ob vom Projekt stammend, vom Unternehmen oder von außerhalb, der Verständlichkeit der formulierten Anforderungen entgegensteht, so wird sie missachtet.
R7: Lösungen zu Anforderungen werden nur in Form von optionalen Vorschlägen behandelt.
R8: Das AM-Konzept unterliegt einem kontinuierlichen Verbesserungsprozess.
R9: Es gilt AllgRegelnPAEE ("Allgemeine Regeln zu Priorisierung von Aufgaben in evolutionären Entwicklungen")

Zu RE-Prinzipien.R3: Anforderungsbezogene Fehler in IT-Systemen
Fehler in IT-Systemen zu beheben wird umso teuerer, je „später" im Entwicklungsprozess sie entdeckt werden. Dies ist so, weil im Systems Engineering ein- und dieselbe Sache mehrfach beschrieben wird: als grobe Anforderung, als Architektur, als feine Anforderung, als Design, als Test, als Code, in Handbüchern. Je mehr Artefakte aufgrund eines Fehlers zu ändern sind, desto teuerer. Hinzu kommen u. U. noch Kosten, eine Fehlerbehebung in die Fläche zum Anwender zu bringen.
Somit ist es zweckmäßig, Fehler von vornherein zu vermeiden.

Was das Anforderungsmanagement anbelangt entstehen Fehler an 4 Stellen im Prozess:
1) Wenn die Stakeholder ihre Anforderungen falsch oder unvollständig definieren.
2) Wenn Analytiker die Anforderungen falsch/unvollständig dokumentieren. Gute Anforderungen zu schreiben ist kein Hexenwerk.
3) Wenn Entwickler Unit Tests schreiben, die die falsche Implementierung testen. Selbst mit effizienten Verfahren zur ständigen Integration von Implementierungsartefakten wird damit nur sehr effizient das Falsche getestet.
4) Wenn Tester sicherstellen, dass die falschen / nicht alle Anforderungen implementiert wurden. Man verschwendet Zeit damit, Anforderungen zu testen (unf ggf. Fehler zu beheben), die gar keine sind.

Welche Strategie verwenden wir im Projekt dagegen? Wir bauen an den entsprechenden Stellen Feedback-Zyklen ein.

Zu 1): Den ROI des Projektes in den Mittelpunkt zu stellen bewirkt, das sich die Stakeholder auf die wichtigen Anforderungen konzentrieren. Verschiedene Erhebungstechniken helfen dabei. Die Stakeholder geben die von den Analytikern geschriebenen Anforderungen inhaltlich frei.
Zu 2): SQC-Prozess zur Sicherung der Anforderungsqualität. Ein oder mehrere Analytiker geben die Erbeit eines Analytikers formal frei. Ziel ist vorrangig die Verbesserung des Analytikers, nicht der Spezifikation
Zu 3): zwischen Analytikern, Architekten und Entwicklern hilft sicherzustellen, dass die Entwickler die Anforderungen verstanden haben.
Zu 4): Die von den Testern erstellten Testfälle und Testdaten werden von den Analytikern freigegeben.

Principles of Clear Thinking

Type: Rules
Status: Draft
Version: 2007-12-20
Quelle: Principles of Clear Thinking. <- Blog on http://www.blogger.com/www.gilb.com 2007-03-27 (R1 to R10); rest: own thoughts
R1. You have to have a clear set of objectives and constraints, to evaluate proposed solutions or strategies against.
R2. You have to have a reasonable set of facts about the benefits and costs of any proposed idea, so that you can relate it to you current outstanding requirements.
R3. You have to have some notion of the risks associated with the idea, so that you can understand and take account of the worst possible case.
R4. You have to have some ideas about how to test the ideas gradually, early and on a small scale before committing to full scale implementation.
R5. If there are more than very few factors involved ( 2 to 4) then you are going to have to use a written model of the objectives, constraints, costs, benefits, and risks.
R6. If you want to check your thinking with anyone else, then you will need a written model to safely and completely share your understanding with anyone else.
R7. You will need to make a clear distinction between necessities (constraints) and desirables (targets).
R8. You will need to state all assumptions clearly, in writing, and to challenge them, or ask ‘what if they are not true?’
R9. You will want to have a backup plan, contingencies, for the worst case scenarios – failure to fund, failure for benefits to materialize, unexpected risk elements, political problems.
R10. Assume that information from other people is unreliable, slanted, incomplete, risky – and needs checking.
R11. Assume that you models are incomplete and wrong, so check the evidence to support, modify or destroy your models.

AllgRegelnPAEE

Name: General Rules for Prioritizing Tasks in Evolutionary Development
Type: RuleSet
Status: final
Version 2007-04-29
Purpose: What to do next?
Source: Niels Malotaux, www.malotaux.nl

R1: Most important requirements first
R2: Highest risks first
R3: Most educational or supporting for development first
R4: Actively Synchronise with other developments
R5: Every cycle delivers a useful, completed, result