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 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
Published by Tom Gilb13 points  on Tue 17 of Nov., 2009 TomGilb
Project-Requirements.png (4.34 Kb) MY ANSWER, TO THE EMAIL QUESTION COPIED AT THE BOTTOM OF THIS BLOG NOBODY AND NO 'BODY' HAS AGREED ON A SATISFACTORY DEFINITION IMHO OF 'ARCHITECTURE' Our profession (as Mark Maier, maiermw at gmail.com, pointed out in a chapter The Art of Systems Architecting) has no agreement on the meaning of (systems) Architecture, let alone Engineering. It becomes consequently arbitrary to train and certify them. KOEN ON 'WHAT IS ENGINEERING'? I like to defer to the deep thinker, Billy V. Koen, and I agree with his conclusions http://online.(external link)Engineering.illinois.edu/webcourses/seminars/ETC/notes/01-24-07.pdf slides http://www.cse.hcmut.edu.vn/~minhle/congtackysu_2008/Engineering_Method.pdf(external link) paper http://www.me.utexas.edu/~koen/OUP/OUP.html(external link) book - a remarkably deep book ! CAN WE EVEN AGREE ON THE Complex NOTION OF Requirements? Actually, since Engineering and Architecture are completely dependent on the notion of Requirements, it might be interesting if we found mature agreement on the Concept of Requirements! Most of the real world is in a terribly confused state about it, in my view. It is then premature for the same world to decide what an engineer or architect is to do. HERE IS MY LATEST Planguage DEFINITION OF Requirement A ‘requirement’ is a stakeholder-prioritized future state. ARE Architecture AND Engineering DIFFERENT? I believe that they are essentially identical as disciplines. The practical and immediate temporal distinction being Scope and viewpoint alone. "JUST CALLING SOMETHING BY A NAME, DOESN'T MAKE IT SO" (G M Weinberg) We choose, arbitrarily, to say 'architecture' when we want to emphasize something more whole, more Complete. And we say 'engineering' when we Wish to emphasize something more specialized, and more of a subset of the Architecture we referred to. There is a human communication needs difference. But I do not believe there is a difference in the necessary logical Processes to carry out the disciplines, whatever they are named, properly. Those disciplines, in my personal view, are thoroughly described in my CE book, and my many papers and slides (gilb.com). SO WHICH VIEW OF Architecture AND Engineering DO I BELIEVE IN? Here is a summary of my direct answers to the 3 options described, below (they are 'in place' there, below) GILB Comment: both disciplines must necessarily find the 'designs'/'solutions' (how?), to meet the Requirements (what=function, how well = performance levels, constraints = limits on solution). The only difference is one of detail, and Level of consideration. GILB Comment: YES. Architecture is a logically necessary 'swim lane'; which will 'narrow in' on the next set of Engineering approaches. An architect for example might choose a 'buy' or 'maintain old system' avenue, rather than a 'build new system' avenue - thus radically Changing the disciplines needed downstream. 'Legal/Procurement Engineering' anyone? GILB Comment: the Level of experience is immaterial. Good electrical engineers do not become building architects. Both disciplines need intelligent, trained and experienced people, using logical methods to achieve their purpose. Both need access to information that is not in their personal memory. Tom MY FORMAL DEFINITION OF CONCEPTS RELATED TO Architecture AND Engineering ps here is a subset of my Concept Glossary, re Architecture and Engineering Engineering and Architecture concepts - below is a subset ) http://www.gilb.com/tiki-download_file.php?fileId=287(external link) The full Glossary is at http://www.gilb.com/tiki-download_file.php?fileId=25(external link) ========= here is the email I got today 17 Nov 2009, from Daniel in NJ Tom, I found your paper (“Systems Architecture: a View Based on Multiple Impacts”, http://www.gilb.com/tiki-download_file.php?fileId=47)(external link) in the INCOSE SAWG web site. I realize that this paper is a couple of years old now, so I was wondering how you view the current initiatives to certify or credential systems architects. How do you view systems Architecture in relation to systems Engineering? I have encountered at least 3 fundamentally different perspectives on this. Architecture is emerging as an Engineering science separate and distinct from systems Engineering. Architects envision the "what" with out-of-the-box thinking that creates solutions that may leverage existing solutions but are not constrained by them. Systems engineers, then, Add flesh to the architecture's bones by sweating the details of "how". Those interested in creating new departments (that they can Chair or lead) tend to be attracted to this view. Does that necessarily make it invalid? Companies and organizations are currently standing up separate Boards to "qualify" systems engineers and systems architects. Does this imply that they are distinct Engineering disciplines? GILB Comment: both disciplines must necessarily find the 'designs' (how?), to meet the Requirements (what=function, how well = performance levels, constraints = limits on solution). The only difference is one of detail and Level of consideration. ------------- Architecture is a Level of proficiency in that the most experienced and capable systems engineers are qualified to be architects. A novice systems engineer may be good at Requirements development or Functional modeling but inexperienced in verification Planning or discrete event simulation analysis. Architects who lead the team must be reasonably skilled in all these areas. I have had two architects from what was once Bell Labs tell me that this is how the term was used in that industry. "The architect was what every systems engineer wanted to grow up to be." I tend to call this the "Jedi Master" definition since the architect has to do everything that the SE does--only better. GILB Comment: the Level of experience is immaterial. Good electrical engineers do not become building architects. Both disciplines need intelligent, trained and experienced people, using logical methods to achieve their purpose. Both need access to information that is not in their personal memory. ----------------- Architecture is one of several skill areas that a systems engineer must master. The older engineers will tell you that Before Zachman hit it big, we were all systems engineers. We did the same flow diagrams and network layouts, but those were not called Architecture artifacts in those days. Architects may not need to do operational analysis trades or verification plans, but systems engineers do. If the previous perspective is thought of as a vertical relationship with architects being at the top of the SE pyramid, then this one might be characterized as the horizontal view with Architecture just being one of the "swim lanes" of the total skill set needed for systems engineering-along side Requirements analysis, operational analysis, verification, etc. GILB Comment: YES. Architecture is a logically necessary 'swim lane' which will 'narrow in' on the next set of Engineering approaches. An architect for example might choose a 'buy' or 'maintain old system' avenue, rather than a 'build new system' avenue - thus radically Changing the disciplines needed downstream. 'Legal/Procurement Engineering' anyone? -------------- Are you aware of any Work being done to clarify the roles of systems architect vs. systems engineer? With these three diverse views out there (at least), we seem to be a long way from reaching consensus. I would welcome your thoughts.
First PagePage: 3/11Last Page
1234511