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