Loading...
 

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 Kai Thomas Gilb323 points  on Wed 17 of Oct., 2007 KaiGilb
I recently got an email from a Client with some questions I like to share. We’ve assembled a small team to start working on how we would implement your methods in our business; looking at how we will market them as well as delivery to clients. A couple of questions have come up today that we would appreciate if you are able to answer: ^1. How do we define top-level project parameters, such as Resources and Budget, at the start? Is there an Evo approach or is the client’s usual business-case acceptable?^ We find that there is a long and mature history on how to define money and time. It is always done measurably. As such the normal defined Business Case is acceptable. but.... the challenge lies in the way the expected Development Resources are derived. To argue my Case here on email is too much, but it goes something like this: How to understand the Development Resources of a project that is not a simple reproduction (copy) of another project is unknown (impossible?). Today people use various method to understand how much something will Cost to develop (Development Resources), they all have one thing in common, non of them Work, they are not even close. They are simply done to make the financial director feel s/he is in some kind of control. Developing NEW products is not as simple as doing a, then b, then c. Each (a, b & c) costing 100 hours, therefore it will Cost 300 hours. There are too many unknowns, things that we do not know how much money or time it will Cost to develop. Where it has not been done Before, or we have not done it Before, we can not normally know the Cost. It is the critical Stakeholder Value and Product Quality Levels that Cost to achieve. Even small increases in certain Product Quality or Stakeholder Value Levels might quadruple the Development Resource Cost of a project. So Evo takes another approach. It admits Development Resource costs are unknown and impossible to calculate, and rather Evo asks what is it worth? What are the expected Stakeholder Value improvements worth. Then it delivers the improvements in cycles, starting where it can deliver the most improvements to Stakeholder Value for the least Development Resources. At one point during development, the value delivered might be viewed as small compared to what it costs. Then Development Resources can be reallocated to something entirely different. A project that has a high value to Cost ratio. So Evo turns the equation upside down. Instead of asking: how much will it costs? Evo asks, what is it worth? And works on delivering the value within what it is worth. It is also called design to Cost. Evo has an amazing track Record of delivering projects within Development Resources. This is among other reasons because it can adjust anything early and continuously throughout the development Process. Typically one adjusts people, Solutions, Processes, Stakeholder focus and by having quantified the Product Quality and the Stakeholder Value aspects, with not only Goal Levels, but also Tolerable levels, one can adjust some of the less critical aspects down, but above the Tolerable Level and keep the critical ones up above the Goal Level. -=for more information see: =- Blog Entry: Estimation or Control?(external link) Paper: Software Outsourcing Contracting: What should be in the contract and what should not(external link) ^2. Work starts with defining the real Requirements; how soon does the delivery of benefits start in practice?^ It can start the next week, in practice. The trick here is to focus on delivering the value improvement, not a Product, and not write the real Requirements for weeks and weeks, they will not be real, the real Requirements you will probably only find when you attempt to deliver value to Stakeholders(external link). We recently had a student that was assigned as a project manager for installing a large IT system into an organization that was in the ip-telephone operator business. The project was viewed as taking more than a year Before any Stakeholder Value could be delivered. Our student first went hunting for major Stakeholders and their expected Stakeholder Value. That lead him to knock on the door of the CEO who had ordered the system. The CEO explained to our student that his company was loosing $12M per year caused by deadline of contracts not being respected and that no one knew about it Before they got the bills. Armed with that knowledge, our student managed to put on the table of the CEO, THE NEXT WEEK, a system that flagged the loosing contracts in time for the CEO to do something about them. The CEO was ecstatic with joy. Our student had won instant and infinite Credibility to continue the rollout of the IT system, at all Evo steps working on delivering Stakeholder Value, not just rolling out an IT system. Of cause, this is an exceptionally good Case, but some useful value to some Stakeholder(external link) (sometimes internal) is normally achievable within the first week or 4. - Kai Gilb {SUBMITBLOG()}{SUBMITBLOG}
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}
First PagePage: 11/12
19101112