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 Tue 28 of Sep., 2010 kaiGilb
Project-Requirements.png (4.34 Kb)
Part 0 of 7 Introduction(external link)
Part 1 of 7 Wrong Focus(external link)
Part 2 of 7 Developer Creativity(external link)
Part 3 of 7 Stakeout Stakeholders(external link)

!!!Part 3 of 7: Stakeout Stakeholders or Stakeholders will stake you out.
Agile theory, teachings and practices mainly* focus on the users and sometimes the customer. They preach use-cases, user stories and the customer-in-the-next-room Type techniques.
* *I’m sure someone can and will point to projects that takes a wider approach to Stakeholders. I applaud and support that. Please link to sensible information about capturing Complete set of Stakeholders, especially those that target Stakeholders that are not customer and users. I’m in support, not against great Agile implementations. Yet 95% of what I see practiced, written, thought, and preached takes the limited approach to Stakeholders.
Any system being developed has multiple Stakeholders. Stakeholders being the people, groups and things (laws, other systems etc.) that have Requirements related to the system. Stakeholders have a ‘stake’ in the system. Critical Stakeholders can potentially determine success and failure of the system. Stakeholders require something from the system.
StakeholderMap.jpg (41.77 Kb)
Read more
Published by Kai Thomas Gilb323 points  on Mon 22 of Feb., 2010 kaiGilb
Project-Requirements.png (4.34 Kb) Part 0 of 7 Introduction(external link)
Part 1 of 7 Wrong Focus(external link)
Part 2 of 7 Developer Creativity(external link)
Part 3 of 7 Stakeout Stakeholders(external link)
!!!Part 2 of 7: Agile “Baby Talk” Kills Developer Creativity
Conclusions up front Scrum is practiced as a huge cooperative todo list. By not focusing on the critical "how well" Attributes of the system, Scrum is reducing sw development to tasks, not needing skillful creative knowledgeable Developers. Developers are told what to code, not asked how to best satisfy a Product Quality need. When developers are given the challenge to improve a system (Product-Quality) they not only rise to the challenge, but excel at it. This is also observed in Scrum teams where they are given the challenge. There is little or no understanding for how to create a competitive Product. Rather, the opposite is happening, by requiring 'solutions' (made by amateurs (users), not architects), more-competitive options are systematically censored. The Agilists sell Agile as an answer to increasing market pressure, as a way to be more competitive. But Agile falls short of giving its applicants a competitive advantage, because it doesn't say anything about Requirements. The popular Agile practices, teach and practice Use Cases or User Stories and other Function and Feature centric ways to describe the most critical input and outcome of development. There is little or no specification to help us differentiate between a Function “the what”, a value “how well”, and a Solution “how”. Most Agilists teach and practice 'mixing the required Function with the optional solutions'. They don’t seem to teach anything useful when it comes to the most critical Type of Requirements, the “how well”. In practice, by teaching User Stories, they teach not to use the critical “how well” types of Requirements, at least not in a way that can be used to guide decisions in the Solutions. The real value and Cost of a system comes from creating the "how well" Attributes. This “baby talk” Requirements practice makes the popular Agile methods useless to anyone creating competitive systems, to anyone creating systems requiring high value, and to business.
that is it, the rest of this blog is fill :-) to better explain the conclusions above.
Read more
Published by Tom Gilb13 points  on Sun 31 of Jan., 2010 TomGilb
Project-Requirements.png (4.34 Kb) http://bit.ly/axtT9A(external link) www.semat.org(external link) My Position Paper for March Zurich Conference. Too many 'coders' involved! A select group of 'wise old men' (at least 'old') including me, is going to meet 17-19 March at ETH Zurich, to tackle the problem of making real software Engineering happen. I am also going to hold some courses public in town that week too. We have failed miserably, and we have been the methods leaders, book writers, conference speakers for decades. Reading some other's position papers, I am already worried, as I initially was, that some of these people still do not see a distinction between programming, and software Engineering - between a craft of building, and an intellectual/practical discipline of designing and Architecture. They consistently fail to mention anything about Quality and Cost, or design or Architecture to meet performance Requirements within constraints.! They consistently refer to code and coding Processes. I know these guys, they are actually intelligent people - but it amazes me they have no sense at all of what Engineering is. Lack of the culture. Failure to engineer, while "improving Scrum Burn Rates" is arguably one major reason for large software system failure. I find that most large projects do not Quantify their top few critical (Quality, improvement objectives. I have seen at least 3 $100 million software projects totally fail for this reason alone. Lots of smart programmers there though! My personal prediction is that real major change in teaching, and doing, real software Engineering, will only come about as a Result of very major catastrophes, caused by bad software. In my imagination 300 aircraft will kill all their passengers, on a single day, due to an air traffic control 'glitch'. Caused by poor Engineering practices. Will that wake people up? Until then we can try to prepare the ground by working out ideas of what we should be doing - but nothing will happen until we are massively motivated - and we are really not motivated yet. Even events like Nine Eleven (11 Sept, attacks), and Credit Crunch Financial Collapse are not big enough for us to change anything effectively. So something much more painful is required. I hope our ideas survive, the '2012' Catastrophe (see this film - it makes you think). Or wait a minute, our ideas on doing software are so bad now, that maybe if they all got wiped out, we might get a fresh start based on common sense? Yeah, wipe out all those dumb software ideas, including agile, then use our heads: One simple survivor: deliver real measurable value for money to Stakeholders. Is that so difficult to understand?
Published by Kai Thomas Gilb323 points  on Fri 11 of Dec, 2009 kaiGilb
Project-Requirements.png (4.34 Kb) Sorry about all these pictures, but I am very excited about this workshop ;-) Value_Management_Experience_Workshop00.png (444.71 Kb) This is the setup for each team. Prioritizing from Finance to Stakeholder Values to Product with Product Values to Sub-Products with Sub-Product Values to Solutions. to Evo Cycles. Then build the Solutions with sw and Lego. test with measurements missions. repeat. Value_Management_Experience_Workshop01.png (591.98 Kb) Here you see glimpses of the Value Decision Tables, and Solution description.
Read more
Published by Tom Gilb13 points  on Mon 07 of Dec, 2009 TomGilb
Project-Requirements.png (4.34 Kb) ::Principles of Professional Change:: You have to define your critical organizational improvements quantitatively You have to judge all organizational strategies in relation to these critical objectives You have to roll out change early and often, and Measure the effect immediately You have to prioritize change strategies that really Work, and kill off those that don’t, Before scaling up Focus on Meta-Strategies: those that allow decentralized feedback and change during projects (like Evo and Spec QC) Project Architecture must explicitly address quantified project objectives All cost-driving specification must be Quality controlled and have high Quality (1 Major defect/page) Exit levels Projects must deliver Stakeholder value incrementally and measurably Thorough Stakeholder value analysis must be used to prevent Cost surprises later Always prioritize the most efficient strategies next: high value/cost wrt Risk Sub-contract for no cure no pay, not for fixed Cost or time and materials http://www.gilb.com/tiki-download_file.php?fileId=364 (external link)
Published by Tom Gilb13 points  on Sat 05 of Dec, 2009 TomGilb
Project-Requirements.png (4.34 Kb) A BLOGGER, FOLLOWED BY A TWITTER AND RETWEET SAID TODAY ...... "Ppl talk a lot about business value, but they forget that for most people business value is totally subjective! (i.e. unquantifiable)" FROM Tom To the blogger/twitterer (who could be many of you out there, not least - your manager!) I think you need straightening out, regarding your terms and concepts. Of course, you don't have to get straightened out!  :) 'Subjective' Means, based on personal opinion, as opposed to more-objective observation "I think he is heavy". (subjective) "The Scale shows he is 100 kilos" (objective) Personal opinion can be quantified "I think he is about 100 kilos" There is nothing wrong with value being subjective - in fact that is a normal, inevitable thing. People and organizations have their own values, and that determines what they value. Most of these values can be expressed quantitatively, if we want to, and know how. But most often we do not Quantify our value statements, because we do not feel the need, we do not need to, we don't know how. In my opinion, your view is dangerous, and your commonly held view that is one root cause of widespread project failure. I suggest you study (if you care to rise above your misconceptions) top Level objectives(external link) and  vision engineering(external link) Quantifying Stakeholder Values(external link) Value delivery paper(external link) and finally study the Process for quantification in ch 5 Competitive Engineering(external link) When you have concluded, correctly, that you were wrong, misleading, and a danger to the IT community for spreading such incorrect views, you should consider blogging to illuminate your readers about your new insights. Then consider what this might mean to the better control of agile Processes (quantified values as Requirements and testable outputs, and increments). Like this Confirmit Case(external link) Value Driven Project Management(external link) Your observation might be more accurate and useful if you had said.... (you can quote me): "People are good at articulating their business values with nice sounding words ('greater efficiency') but universally terrible at clarifying exactly what they mean numerically and testably. This is one root cause of project failure. The problem with articulating business values is not that people are intellectually incapable of quantifying and defining them. The problem is that they were never trained to Quantify them, nor were that asked by their organization and management to Quantify them" Tom Gilb 5 Dec 2009) I think I will put the above in my blog, but I won't identify you. You are After all the victim of poor education regarding quantification of critical values, like most people. The good news is you can rise above the Level of your teachers, if you choose to. Don't take this personally. It is not your fault. But it will  be your fault if you do not improve your understanding of these things. If I seem angry - I am! These attitudes and misconceptions are directly at the heart of our horrendous IT project failure rate, and consequent lack of trust in IT. We need to learn to succeed more often than we fail. We need to deliver real expected value to society. The programmers of the world are not exactly famous for doing so. I am ashamed to be somehow related to the community. But I am fighting for change. How about you? You might like to know there are some people who feel as strongly as I do that this immature profession needs to grow up. http://www.semat.org/bin/view(external link) Welcome if you want to join us. Tom . SOME DICTIONARY DEFINITIONS subjective |səbˈjektiv| adjective 1 based on or influenced by personal feelings, tastes, or opinions : his views are highly subjective |there is always the danger of making a subjective judgment. Contrasted with objective  value |ˈvalyoō| noun 1 the regard that something is held to deserve; the importance or preciousness of something :your support is of great value. • the material or monetary worth of something : prints seldom rise in value | equipment is included up to a total value of $500. • the worth of something compared to the price paid or asked for it : at $12.50 the book is agood value. • the usefulness of something considered in respect of a particular purpose : some new drugs are of great value in treating cancer. • the relative rank, importance, or power of a playing card, chess piece, etc., according to the rules of the game. 2 ( values) a person's principles or Standards of behavior; one's judgment of what is important in life : they internalize their parents' rules and values. 3 the numerical amount denoted by an algebraic term; a magnitude, Quantity, or number : the mean value of x | an accurate value for the mass of Venus. quantify |ˈkwäntəˌfī| verb ( -fies, -fied)  trans.  1 express or Measure the Quantity of : it's very hard to Quantify the Cost.
Published by Tom Gilb13 points  on Fri 04 of Dec, 2009 TomGilb
Project-Requirements.png (4.34 Kb) From: Tom Gilb tom@gilb.com Sent: 2009-12-03 10:14:10 CET To: Frederik Hermann Siegumfeldt frhs@itst.dk Subject: here is a summary of my 5 oral remarks After your talk at Agile 09 Copenhagen 2 Dec09 1. Agile is not any kind of main Solution to the problem of failed or bad government projects. It has no track Record of doing so Iteration (aka Evolutionary, US DoD Std 494, 1994, an Evolutionary Standard, distancing itself from Waterfall) is a very useful Principle, long Before the 'Agile' era. But you must not confuse Rapid delivery cycle feedback, with Agile. Agile (like Scrum, actually does the feedback Process very badly! The Requirements are screwed up, so feedback works badly, see 2 below) 2. The primary problem with large projects today, in my extensive international experience, is "THE LACK OF Clarity AND FOCUS ON THE TOP FEW CRITICAL OBJECTIVES OF THE PROJECT." http://www.gilb.com/tiki-download_file.php?fileId=180(external link) Eight Case STUDIES and also http://www.gilb.com/tiki-download_file.php?fileId=237(external link) Vision Engineering: how to convert management phrases into measurable targets and measurable strategies. The problem is that projects, agile or not, fail to set really clear objectives (quantified improvements in several critical dimensions, like Efficiency, Productivity, responsiveness, ease of use, security, maintainability, adaptability). h development and test teams are not at all focussed on these wooly objectives, They are in fact forgotten forever. Projects then fail to deliver actual expectations and hopes, to the woolly goals. 3. Systems Engineering: the IT and Software culture is incredibly 'algorithmic centered'. Their whole world is 'delivered code' (even databases are almost never mentioned!). The problem is that delivery of value requires much more than some Functional code, and in many cases we can deliver value best by NOT developing ANY code, even for an it system! For example by training or motivating users or passing a law or implementing a management Policy or writing a contract. So, our REAL Solution, needs to be explicit about the DEVELOPMENT ENVIRONMENT. The development environment CANNOT BE LIMITED TO COMPUTER CODE. One way to do this is to focus on real value delivery, and allow ANY Means TO GET THERE. Another view of the same thing is to officially adopt the SYSTEMS Engineering paradigm (INCOSE.ORG). To say " we are systems Engineering, we use any hardware, software, or human-organizational 'technologies' to reach our VALUE DELIVERY objectives. Admittedly, Scrum, as taught by Jeff Sutherland, can be used for projects of any kind, because the essence is simply a rapid cycle feedback learning loop (which Scrum did not invent by any Means). BUT, most Scrum users we know, are code-centric. They do not apply a systems wide perspective. So, if DANMARK is going to solve the problem of successfully building large government systems WE MUST SHIFT TO A 'SYSTEMS ENGINEERING' (Incose.org) paradigm. We must put the coders in their place, as one technical Component of a larger project, if used at all to solve some problems! People built large national systems without software milleniums ago! 4. The problem with getting successful IT systems is NOT 'the right process' (agile or other). It is the motivation to deliver value! We have no such motivation. In fact we have negative motivation! If the projecr runds over Cost and time, the suppliers earn far more money (FOR EXCELLENT DOCUMENTATION SEE Craigs book: Plundering the Public Sector http://www.amazon.co.uk/Plundering-Public-Sector-David-Craig/dp/1845293746(external link) My suggestion is that we must move in the direction of NO CURE NO PAY contracting. Suppliers only get paid for value delivered, not Work done. http://www.gilb.com/tiki-download_file.php?fileId=38(external link) no cure no pay paper http://www.gilb.com/tiki-download_file.php?fileId=85(external link) ncnp slides THE GOVERNMENT SHOULD LEAD, ON MAKING THIS THE NORM! PS the combined mafia-like (I can't think of a nicer description) forces (D. Craig, book above and below) of Accenture, CSC, Price Waterhouse and their like will massively oppose this. We need strong political leadership. Is anyone in Denmark strong enough to make this happen? Not yet! 5.THE MAFIA CONSPIRACY: as mentioned SEE Craigs book: Plundering the Public Sector http://www.amazon.co.uk/Plundering-Public-Sector-David-Craig/dp/1845293746(external link) The biggest problem is not technical. It is about money and power. See the tragedy of medical systems IT http://www.computerworld.com/s/article/9141428/(external link) Harvard_study_Computers_don_t_save_hospitals_money?taxonomyId=12&pageNumber=1 THIS IS SO MUCH BIGGER THAN 'AGILE' ! The Prime Minister should lead, and ministers should also support and lead. Should Denmark have the courage and ability to tackle these problems, I would be happy to help in various ways. There are no leaders in the world on these issues: be a world leader, Denmark, in stopping to pollution of bad IT projects in government.This is also an 'environmental' problem! Tom
First PagePage: 3/12Last Page