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?

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.

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.

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.

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.