Tom Gilb and Kai Gilb's blog

Leading ideas on Project Management. Stakeholder Values, Quantification, Agile, Quality, Requirements, Evo, Quality Control, Systems Engineering, Value Management.
RSS feed
Published by Tom Gilb13 points  on Sat 13 of Oct., 2007 TomGilb
Making Metrics Practical in the Development Process - ten fundamental principles for failure and ten critical software metrics principles for success in the commercial environment. By Tom Gilb Exclusively for UK Software Metrics Association • 16 October 2007-10-09 • Ten fundamental software metrics principles for failure 1. If you Measure what is easy rather than right , you’ll lose the fight. 2. If you Measure too late, you deserve your fate. 3. If you Measure too few, then ones you left out, will lack any clout 4. If the Metric Level is too low, your users are in for a sorry blow. 5. Know the Role of your Metric, or it can roll over on your project 6. If you fail to Quantify a critical variable, it will fail to be what you need 7. Do not trust managers to define the most critical metrics, help them out 8. Some metrics support other metrics, you’d better know which is the star, and which is the supporting Role. 9. Metrics don’t Add up, but you need to understand the set of them 10. Metrics are a generally good tool, until they are used carelessly or to manipulate people. Ten critical software metrics usage principles for success in the commercial environment 1. Develop Requirements metrics top down from critical management objectives. 2. Connect metrics with metrics. 3. Develop metrics with early rapid numeric and non-numeric feedback. 4. Use metrics to describe metrics, Credibility, uncertainty 5. Use metrics to describe solutions, designs, and Architecture 6. Use multiple metrics to compare alternatives 7. Measure critical variables, but with sufficient Qualities and lowest costs 8. Use metrics to review specifications 9. Use metrics to prioritize, and determine priorities 10. Use metrics to create commonly understood, and really agreed Requirement or objectives. See 2 sets of slides on this subject in the Gilb Library (Oct 2007) {SUBMITBLOG()}{SUBMITBLOG}
Published by Kai Thomas Gilb323 points  on Fri 12 of Oct., 2007 KaiGilb
of a large (tens of millions euro spent) IT project. Not surprisingly, we found the highest Project-Hierarchy-Level of the Requirements where unclear, unmeasurable slogans. And the developers of the project where not focused on satisfying them (hard really, when they are unclear). We also found that the main Stakeholders where not involved and listened to. This might have seemed easier for progress in the earlier stages, but it was hindering the roll out of the Product to the main Stakeholders. They began the project with ideas of simple implementation and early deliveries, but that somehow never happened. The project had not delivered any value to any Stakeholders yet. Just a reminder. ^Clear Quantified Stakeholder Values. And everything else should be driven by the satisfaction of those. Deliver value early, next week or month, to some critical Stakeholders. It is always possible, even if people will tell you it is not. ^ Kai Gilb {SUBMITBLOG()}{SUBMITBLOG}
Published by Tom Gilb13 points  on Tue 13 of Feb., 2007 TomGilb
Requirement(external link) Concept *026 February 13 2007 14:57 A ‘requirement’ is a stakeholder-prioritized future state. Some primary remarks on the definition: • Requirements(external link) *026 are used as an input to problem-solving (the problem being ‘how to reach the requirements’) Processes; like design, Architecture, strategy Planning, more-detailed Requirements(external link) *026, more technical Requirements, and Engineering. • Requirements(external link) *026 may be subject to ‘testing for existence’ in a system. • Requirements(external link) *026 exist without regard to the possible or actual Means by which their future state is achieved. • But a realistic Requirement(external link) *026 may be determined as a Result of knowing the performance limits, and costs, of available designs. • Requirements(external link) *026 can exist even if no known Means exist to satisfy them. • A Requirement(external link) *026 will not necessarily be invested in, until its Priority information causes us to Act on it. • A Requirement(external link) *026 may exist even when a formal Requirement Specification(external link) *508 does not. Deeper Notes: 1. Stakeholder(external link) *233 specifically includes “any person, group or object, which has some direct or indirect interest in a system. The ‘object’ can include any documents or specification at any Level, such as a law or a Standard specification” 2. “Stakeholder-prioritized”: Means that a given Stakeholder(external link) *233, or set of them, can give a variety of signals regarding the relative Priority they place on achieving that future state. These Priority signals* can be analyzed in a given development environment so that the actual implementation of the Requirement(external link) *026 is delayed, implemented in some limited way, or never implemented. There is no absolute certainty that a Requirement(external link) *026 will actually be implemented until it is actually implemented in practice. And there is no certainty that it will remain implemented once it has been implemented. * Priority signals: are of infinite variety, and may be analyzed in arbitrary sets, by any given analyst. They can include for example: deadlines, Binary constraints, target levels, Constraint levels, specification qualifiers, dependencies, risks, uncertainties, willingness to fund, formal Authority, market willingness to pay, current and projected profitability, laws, regulations, and cultural values. 3. A Requirement(external link) *026 is quite distinct from a ‘need’ (*599): A ‘need’ is something desired by a defined Stakeholder(external link) *233. The implication is that satisfying that need would have some value (*269, ‘perceived benefit’ ) for some Stakeholder(external link) *233. A need might not be agreed as a formal Requirement(external link) *026, and it might not be prioritized such that it is actually acted upon (designed and implemented). ‘Need’ is a term often used as a Stakeholder view of a problem Before Requirements specification is carried out. 4. Requirements(external link) *026 are the Baseline for deciding which design ideas (*047) to use to satisfy them. In practice a set of Requirements(external link) *026 will be needed to reasonably optimize a practical set of designs needed to meet them. 5. “Future State”: refers to any observable (testable) Attribute (like Function(external link), performance Level, Constraint compliance*) of a defined system in the future. This does not imply that the system does not already, at present, have the state, but just that it must (also) have it in, or by, a defined future time. * Constraint compliance: can include design constraints, negative constraints and positive constraints, as well as performance and resource Scalar Constraint levels. Figure *026a: Requirement(external link) *026 Concepts. Mil_Std 498: Requirements(external link) *026 are what the acquirer cares enough about to make conditions for acceptance (may be "what" or "how") Design is the set of decisions made by the developer in response to Requirements(external link) *026 (may be "what" or "how") (solutions plus decisions) Pointed out by Niels Malotaux May 18 2005. He also helped simplify the main definition *026. Given below are some IEEE definitions: Requirement(external link) *026: a Condition or capability needed by a user to solve a problem or achieve an objective. ). Related Concepts Requirements *0266]: • Requirement Specification(external link) *508: A written artifact containing a set of Requirements(external link) *026, which may include additional Background information. • Need *599 • Problem Definition *598 • Problem *270 • Design Problem *654 • Target *048 • Constraint *218 • Stakeholder(external link) *233 • Objective *100: An ‘objective’ is not a pure synonym for ‘requirement.’ Objectives are performance Requirements. • Value *269 • Benefit *009 • Client Stakeholder(external link) *650 • Server Stakeholder(external link) *233 • Priority *112 • State *174 Type Requirement *026]: System Specification. {SUBMITBLOG()}{SUBMITBLOG}
Published by Tom Gilb13 points  on Thu 01 of Feb., 2007 TomGilb
A long term Client of ours asked, today, if we could help their people with quantification of intangibles, so we developed a special course outline for them. Maybe this will interest some of you too! Content: (we would tailor this to your situation, needs and culture, but this is what we teach) Business Case Planning: Quantifying 'Intangible' Business Value.     Duration: (minimum 2 days (point 1-13) and prefer 3 days  for solid really-learn to do it exercises (Point 1-16) , Point 1-6 could be done in 1 day lecture 1. How to Quantify any interesting business variable, especially 'intangibles' 2. How to analyze and approximate current levels 3. How to determine future Constraint levels 4. How to determine future business target levels 5. How to specify variations in the market/employee/customer space 6. How to deal with numeric uncertainty  7. How to specify issues, dependencies, risks. 8. How to specify priorities for business objectives. 9. How to avoid confusing objectives (ends)  and strategies (Means) 10. How to estimate the numeric Impacts of multiple strategy proposals on multiple numeric objectives and budgets. (The Impact Estimation method) 11. Evolutionary Result delivery: how to deliver early measurable results, even for intangibles. 12. How to define a Measurement Process for all numeric objectives, even intangibles. 13. Corporate Standards: Policy, Specification Rules, Defined Process 14. Exercises with instructor feedback.(throughout) 15. Analysis and rewriting of real plans or Case study plans. 16. Quality Control of plans with respect to the defined 'Rules". {SUBMITBLOG()}{SUBMITBLOG}
Published by Tom Gilb13 points  on Fri 29 of Dec, 2006 TomGilb
I am drafting the basics for a paper on my views on estimation. Here is the first draft. Tom Estimation or Control? • Accurate estimation is impossible for Complex technical projects, but keeping to agreed budgets is still possible using feedback and change. Version: initial draft: 28 December 2006, Latest =29 12 06 © Tom at Gilb.com Introduction Accurate estimation of Complex systems and software projects is seemingly impossible to guarantee. There are many unavoidable reasons for this. Even when estimation seems to Work, this might just be a Case of stopping the effort when the Budget runs out, but as a Result - delivering systems of unacceptably low Quality. The main Idea of this paper is that there is a constructive alternative to bad estimation Processes. o You use ‘process control’ (do a little, learn quickly, change quickly) to quickly and continuously tune anything and everything about your project, so that prioritized budgets (like time to market, money, human Resources) can be met. o You consciously sacrifice less-holy things for your more-holy things We are better off stipulating reasonable resource constraints (deadlines and Cost budgets) and then learning to live within them. This is acceptable as long as we get our highest priorities satisfied when Resources run out. The rest is by definition, marginal. Why we cannot estimate project costs accurately: o We do not define Requirements well enough to estimate their costs o We do not collect or have access to experience data that would allow us to estimate costs, even if we did have clear Requirements o Even if we did have historic data for the costs of meeting clear Requirements, it would probably not help much because our new project would be different in some way. o We do not really need time and Cost estimates: o They are an old custom, intended to prevent overruns, and to give management some feeling that the job will get done in time at a reasonable Cost. But they do not in fact prevent overruns or assure value. o What management needs is delivery of some critical system Requirements in a predictable time frame o And they need to be sure that the project will be profitable, and not embarrass them with unexpected losses. o This paper describes an alternative way to achieve these management needs.  Principles of Resource Control The Risk Principles 1. DRIVERS: If you have not specified all critical performance and Quality levels numerically – you cannot estimate project Resources. 2. EXPERIENCE: If you do not have historic data about the Resources needed for your technical solutions - you cannot estimate project Resources. 3.Architecture: If you do your project solutions all at once without learning their costs and interactions – you cannot expect to be able to estimate the results. 4.STAFF: If a Complex and large professional project staff is an unknown set of people, or changes in mid project – you cannot expect to estimate the costs. 5. SENSITIVITY: If even the slightest change is made After an ‘accurate’ estimation, to any Requirements, designs or constraints – then the estimate might need to be changed radically. And – you probably will not have the information necessary to do it, nor the insight that you need to do it. The Control Principles 6. LEARN SMALL: Do projects in small increments of delivering Requirements – so you can Measure results and costs against estimates. 7. LEARN ROOT: If incremental costs for a given Requirement deviate negatively from estimates – analyze the root cause, and change anything about next increments that you believe might get you back on track. 8. PRIORITIZE CRITICAL: You will have to prioritize your most critical Requirements and constraints: there is no guarantee you can achieve them all. Deliver high-value for resources-used first. 9. Risk FAST: You should probably implement the highest-risk ideas early, so you have plenty of resource to deal with their uncertainties. 10. APPLY NOW: Learn early, learn often, learn well, and apply the learning to your current project. Some Constructive suggestions to people who want estimates. • Stipulate one or more useful deadlines from you point of view. o Be specific about what has to be done by each deadline. o Ask if these deadlines seem reasonable for the tasks prioritized. o If necessary make adjustments. • Stipulate the value to you of reaching each major (top 10) Requirement. Make an outsourcing contract and pay part of that value only when that Requirement is successfully delivered. • Do business with suppliers who consistently deliver value for money. Don’t waste your money on suppliers who make excuses. ‘No cure, no pay’ is one way to motivate suppliers to give you value for money – otherwise their motivation is to keep billing you forever. {SUBMITBLOG()}{SUBMITBLOG}
Published by Tom Gilb13 points  on Mon 25 of Dec, 2006 TomGilb
Many of our large multinational clients have thousands of Product development and maintenance engineers employed. If they need more, they hire more. But sometimes you cannot hire enough. Increasing the Productivity of the ones you already have is tempting. But how do you manage this? I am writing a paper on the subject and here is the first part. The full paper will be on this website when it is done. Best wishes Tom Introduction: There are often too few qualified engineers. I am mostly referring to Product design engineers – software engineers and systems engineers. One reason we have too few is that we misuse their time so badly – we waste at least 50% of it. But when we can longer desire or afford to solve the problem by hiring or off-shoring to get more warm-bodies, we need to consider getting more Productivity from the engineers we already have. There is one great advantage from that tactic – they already have plenty of experience in our company! There are several tactics to improve Productivity. They can take many years to come to full effect, but a steady long term improvement, and dramatic short term improvement, should be possible. The key Idea in this paper is that we can define our own Productivity quantitatively – and manage the improvement of it quite systematically. Your own definition of Productivity demands several simultaneous dimensions of Productivity. The definition of Productivity also requires substantial tailoring to your organization, and to its current environment. The Engineering Productivity Principles: Here are some basic suggestions for a framework for getting control over Engineering Productivity: 1. Productivity is our subjective opinion of what values we want to create for our critical Stakeholders. 2. Productivity can be defined as a set of quantified and measurable variables. 3. Productivity can be developed through the individual competence and motivation, the way we organize people, and the tools we give them. 4. The initial attack on Productivity improvement should be reduction of wasted effort 5. The next Level of attack on Productivity should be to improve the output of an organization that does not waste effort. 6. Productivity improvement can always be done: there are no known limits. 7. Increasing system performance costs far more than increasing volume of output. 8. Product Attributes are viewed and valued quite differently even by members of the same Stakeholder group. 9. You cannot be sure how well a Productivity improvement strategy will Work until you try it in practice 10. Yesterday’s winning Productivity tactic may not continue to Work as well forever. {SUBMITBLOG()}{SUBMITBLOG}
Published by Tom Gilb13 points  on Mon 25 of Dec, 2006 TomGilb
Reliability - designing it in, not testing it in I am writing a paper on Reliability. When it is done it will be posted on this site in downloads. It is in response to the the frequent question I get from clients - "Help us get better Quality, by teaching us software inspections (title of my book). I always have to explain that you cannot get higher Quality by inspections (you might save some time) in getting to specific Quality levels. You determine Quality levels by defining the Scale and Level you want - and then working towards it - not least by designing reliability into the Work Process, the individual motivation, the Architecture and the detailed design. If you refuse to release until the Goal Level is reached then the only influence that all these tactics can have (After setting the Requirement) is on time another Resources needed to get there. Anyway here are some principles I thought would be the core of the paper: Gilb’s Reliability Principles 1. FREQUENCY: Reliability is the frequency of failure, not the density of bugs – or the availability of the system. 2. SERIOUSNESS: Reliability is the seriousness of the failure for Stakeholders, all failures are not equally important. 3. PERFECTION: Perfect reliability costs infinitely, but incredible reliability can be engineered. 4. Engineering: Reliability must be engineered into the Product, the Work Processes, and the organization. 5. BALANCE: Reliability is not the only necessary Quality – it must be balanced with other Product performance characteristics – that compete for the same limited Resources. 6. VALUE: Reliability has a value, and a Cost – so these must be balanced so the investment pays off. 7. QUANTIFICATION: Reliability can be quantified and it can be measured – we need to engineer it in, not throw nice-sounding platitudes at it. 8. MANAGEMENT: Reliability is not just ‘technical’ - it is determined by intelligent and persistent management. 9. Gilb’s First Law of Reliability: Computer systems are unreliable, but people are even more unreliable paraphrasing 3, p. 81 10. Dijkstra’s Principle: You can never prove the absence of bugs, but you can prove their presence. 4, 3 p.85 Ref 3 is Gilb, Laws of Unreliability, Datamation march 1975 (I'll send a photo copy on request). {SUBMITBLOG()}{SUBMITBLOG}
First PagePage: 11/11