First a graph showing the total results for each submission. 100% = Top score on every question.

The average score is 50%, and the average time spent answering the audit questions was 6,8 min.


Question: Do you prohibit entry to the Inspection process when the source documents for the product to be Inspected have not exited a previous Inspection? If the answer is no, do you first carry out a mini-Inspection on those documents or at least on a sample of them? Do you prohibit Inspection if the source documents are not of adequate quality as a result of your mini Inspection or sample?
Votes Option Average
a. Never 5 33.33%
b. Sometimes 2 13.33%
c. Usually 3 20.00%
d. Always 5 33.33%

Question: Does your kickoff meeting set Inspection goals numerically, and establish corresponding strategies for reaching them?
Option Votes Average
a. Never 6 40.00%
b. Sometimes 1 6.67%
c. Usually 3 20.00%
d. Always 5 33.33%

Question: Are special roles assigned and defined in role checklists? Is there a library of such role checklists available for all Inspection leaders?
Option Votes Average
a. Never 3 20.00%
b. Sometimes 2 13.33%
c. Usually 2 13.33%
d. Always 8 53.33%

Question: Does the Inspection leader check that every issue logged has had some action taken by the editor?
Option Votes Average
a. Never 3 20.00%
b. Sometime 1 6.67%
c. Usually 4 26.67%
d. Always 7 46.67%

Question: Are the rates for both individual checking and the logging meeting updated, compared to the optimum rates, and used to plan the next Inspection cycle?
Option Votes Average
a. Never 7 46.67%
b. Sometimes 1 6.67%
c. Usually 4 26.67%
d. Always 3 20.00%

Question: Is an acceptable logging rate used as an exit criteria?
Option Votes Average
a. Never 10 66.67%
b. Sometimes 0 0%
c. Usually 3 20.00%
d. Always 2 13.33%

Question: Is the number of remaining defects after edit predicted? If this number is too high for the type of document, does the document fail to exit? In other words, is the estimated number of remaining defects an exit criteria?
Option Votes Average
a. Never 7 46.67%
b. Sometimes 0 0%
c. Usually 5 33.33%
d. Always 3 20.00%

Question: Is defect-finding effectiveness computed, based on test and field data?
Option Votes Average
a. Never 5 33.33%
b. Sometimes 1 6.67%
c. Usually 4 26.67%
d. Always 5 33.33%

Question: Is the current known effectiveness used to estimate defects remaining at the end of the Inspection cycle?
Option Votes Average
a. Never 9 60.00%
b. Sometimes 0 0%
c. Usually 3 20.00%
d. Always 3 20.00%

Question: Do you log substantial quantities of issues in your source documents? (for example, on average between 10% and 25% of reported issues resulting in change requests)
Option Votes Average
a. Never 4 26.67%
b. Sometimes 7 46.67%
c. Usually 1 6.67%
d. Always 3 20.00%

Question: Are Inspection leaders formally certified according to written criteria?
Option Votes Average
a. Never 4 26.67%
b. Sometimes 3 20.00%
c. Usually 3 20.00%
d. Always 5 33.33%

Question: Is there an up-to-date list of certified Inspection leaders?
Option Votes Average
a. Never 6 40.00%
b. Sometimes 2 13.33%
c. Usually 1 6.67%
d. Always 6 40.00%

Question: Are non-certified leaders prohibited from running software Inspections (unless under adequate supervision)?
Option Votes Average
a. Never 5 35.71%
b. Sometimes 3 21.43%
c. Usually 3 21.43%
d. Always 3 21.43%

Question: Are rules, procedures and checklists improved to some degree on a regular basis? (for example, weekly)
Option Votes Average
a. Never 1 6.67%
b. Sometimes 6 40.00%
c. Usually 4 26.67%
d. Always 4 26.67%

Question: Are the results of Inspection standards improvements shared among all Inspection leaders and Inspectors?
Option Votes Average
a. Never 5 33.33%
b. Sometimes 2 13.33%
c. Usually 3 20.00%
d. Always 5 33.33%

Question: Is there a library of Inspection material (for example, forms, checklists, rules) which is well-organized and known, and used by all Inspection leaders?
Option Votes Average
a. Never 2 13.33%
b. Sometimes 3 20.00%
c. Usually 2 13.33%
d. Always 8 53.33%

Question: Is a process brainstorming meeting held to analyze the root causes of defects found in the product Inspection?
Option Votes Average
a. Never 3 20.00%
b. Sometimes 5 33.33%
c. Usually 2 13.33%
d. Always 5 33.33%

Question: Are small Scale local individual improvements implemented immediately?
Option Votes Average
a. Never 3 20.00%
b. Sometimes 5 33.33%
c. Usually 3 20.00%
d. Always 4 26.67%

Question: Are all improvement suggestions formally logged?
Option Votes Average
a. Never 1 6.67%
b. Sometimes 6 40.00%
c. Usually 1 6.67%
d. Always 7 46.67%

Question: Does someone, or some group of people (for example, the Process Change Management Team) follow up and implement process improvements using the Inspection database?
Option Votes Average
a. Never 1 6.67%
b. Sometimes 6 40.00%
c. Usually 3 20.00%
d. Always 5 33.33%

Kai

Share this page:

---

Permalink 0 comments

My main concern these days is the high rate of project failure, partial and total.

My main conclusion as to why, is that we are not motivated to succeed, we IT people get so well paid for failure anyway. We are not focussed on delivering real value to Stakeholders - and we are not rewarded for it.

One cure is 'No Cure No Pay Contracting' (in my opinion)
http://www.gilb.com/tiki-download_file.php?fileId=38
www.nasscom.org/download/Tom_Gilb-.ppt
http://www.gilb.com/tiki-download_file.php?fileId=85


The two most immediately critical technical project development processes, that seem to be at the root of failure in the projects we analyze are
1. the top level Requirements (what are sponsors expecting for their money)
2. the delivery cycle and feedback and learning process.

The problem is:
1. The top ten most critical Requirements are not quantified and not focussed on for the project
http://www.gilb.com/tiki-download_file.php?fileId=237 Vision Engineering Paper
http://www.gilb.com/tiki-download_file.php?fileId=180 Top Level Requirements Cases slides

2. The feedback from real delivery of value to Stakeholders is too late , too infrequent and too badly utilized
http://www.gilb.com/tiki-download_file.php?fileId=30 Agile Now What, Kai
http://www.gilb.com/tiki-download_file.php?fileId=27 Kai Gilb Evo book

However most all IT projects seem to care little to do things 'properly'.

So the key change is going to be radically different motivation. This will not be provided by Agile, Lean, or conventional IT/Software forces (CMMI, TSP). They have shown this in practice for too long.

Leadership must come from top executives (by demanding as policy quantification of primary objectives, and early frequent delivery and analysis of feedback), and government institutions (for example by going to No Cure no Pay contracting).

I am just amazed how pervasively 'stupid' we as a culture continue to be! And how little we seem to care?

Do we have to get totally bankrupted as the financial industry has just been, to wake up? I fear we do.

If there are any powerful people out there who at least want to change their own Corporation or Organization - read the above sources and count me in as an ally if that helps.

There have got to some exceptions to this 'Rule of IT Insantity'

Tom :)

Share this page:

---

Permalink 2 comments

We are attending and presenting at the; Software & Systems Quality Conference - United Kingdom - 2008 that runs from 29th of September to 1st of October.

Web site: http://www.sqs-conferences.com/uk/index.htm
The main site where you will find an overview of the whole program etc.

http://www.sqs-conferences.com/uk/program/day2.html
30th sep. 4.15 - 4.55
Management: Optimising Testing
Testable Requirements: What are the Standards we need to adopt to make sure Requirements are Testable?
by Tom Gilb

http://www.sqs-conferences.com/uk/tutorials/t6.htm
1st of October 09:00 17:00 Track 6
Agile Testing: Improving Productivity
by Tom & Kai Gilb

You can get a 10% discount by contacting Julie Wells Julie.Wells (at) sqs-uk.com Tel: 0207 448 4624 Mob: 07769 882211 and mentioning that you got this information from Tom & Kai Gilb

We hope to see you there!

Tom & Kai Gilb

---

Permalink 0 comments

Sony in Tokyo



HitachiSoft in Tokyo


Union of Japanese Scientists & Engineers (JUSE)

Share this page:

---

Permalink 0 comments

Update:

OK, the tikiwiki that this website is running on, is now successfully upgraded. (no more registration issues)

There are numerous improvements, but I like to point out one. On many places, as a logged in user, you can now tag content using the Folksonomy box located at the top right of this website. And we can all search using the tags.

In addition to the upgrade, I have moved the website away from the /community/ sub domain, so if you have pages bookmarked, they need to be changed

from: www.gilb.com/community/...
to: www.gilb.com/...

and the url that is generated from clicking on the menu items on the left side, are much more human friendly.

Kai

---

Permalink 0 comments

Productivity: Concept *659. August 6 2008 (New)
Productivity is delivering promised value to stakeholders.

‘Deliver’ means actually measurable handed over and available to stakeholders.

‘Promised’ means that clear written agreements, are made in contacts, Requirements, documents and slides, or clear undeniable expectations are set.

‘Value’ means something of perceived use, to the Stakeholder; they need it, they want it, they are willing to sacrifice Resources to get it, they will be unhappy if it is late or lower in power than their expectations.

‘Benefits’ are the results of the perceived value to stakeholders. Benefits are what really happens, though time, as a result of the engineering value delivered.
It is an open question whether systems engineering should attempt to take some planning responsibility for enhancing benefits realization, or whether this is the system recipient Stakeholders that should be responsible for planning an environment to maximize benefits. Someone has to take this responsibility, and I fear that the system users with their ‘day jobs’, do not feel they are responsible or capable. In which case an opportunity for systems engineers, to enlarge their conventional scope of planning, exists.

So, we can simplify and say ‘engineering productivity’ is the ability to deliver agreed requirements.

Share this blog:

---

Permalink 8 comments

Vi gleder oss over å kunne tilby, i samarbeid med Nordnet, et prosjektstyrings seminar i Oslo 17. September 2008.



For mer informasjon, se: Prosjektledelse med Verdiskaping http://www.nordnet2008.no/gilb/index.htm
og http://www.bekk.no/aktuelt/nyheter/Spennende-Evo-kurs-med-Tom-og-Kai-Gilb/

Share this blog:

---

Permalink 0 comments