Leading ideas on Project Management.
Stakeholder Values, Quantification, Agile, Quality, Requirements, Evo, Quality Control, Systems Engineering.
Created by System Administrator on Sat 15 of Apr., 2006 21:08 GMT+01:00
Last post Sun 31 of Jan., 2010 05:29 GMT+01:00
(69 Posts | 78199 Visits | Activity=2.00)
By Tom Gilb
on Sun 31 of Jan., 2010 05:29 GMT+01:00
TOM'S POSITION ON REAL SOFTWARE ENGINEERING: IT IS NOT ABOUT PROGRAMMING!
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.
Sorry about all these pictures, but I am very excited about this workshop ;-)
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.
Here you see glimpses of the Value Decision Tables, and Solution description.
Intense testing. Reality hits.
Getting better and better for every cycle (with a few occasional setbacks:-).
Every critical Product Value is quantified with Status and Goal levels.
As the teams made the Robots faster, reliability and precision challenges came.
Intensity followed by laughter. One Robot took of and hid behind the speaker.
at the toy store getting parts and discussing options.
Fantastic to see how the Value Management methods drive competition, the name Competitive Engineering really finds its place in this workshop. I have never held a 3 day workshop where the participants learned so much about Value Management (Evo/Competitive Engineering). Kudos to all the participants that stayed with it through the early frustration caused by being asked to do what they had not yet learned to do. I hope there will be many such courses to come. Congratulations with your certifications, they are well earned.
By Tom Gilb
on Mon 07 of Dec., 2009 17:53 GMT+01:00
Part of a Set of slides on Project Predictability, for a Top Manager Presentation
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
By Tom Gilb
on Sat 05 of Dec., 2009 23:48 GMT+01:00
Business Values are always subjective, and almost always quantifiable: an angry answer to immature ideas
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.
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).
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.
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.
By Tom Gilb
on Fri 04 of Dec., 2009 23:00 GMT+01:00
Agile is NOT a major solution to Bad Government or Private IT Projects!
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
Eight CASE STUDIES
and also
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
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!
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!
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, , 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
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.
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 )
=== 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) 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.
Part 1 of 7: Completely wrong Focus: Agile & Scrum is not focused on delivering values to Stakeholders for a minimum or a reasonable cost.
As developers, project managers, product owners etc. we earn our living by delivering values to Stakeholders, by giving our Stakeholders improvements to whatever they do, at a cost they are willing to pay. The systems we develop must therefore first and foremost deliver value efficiently. Deliver agreed value to Stakeholders, within agreed or reasonable development resources. The problem is … that is not what Agile is doing in practice, good intents to the contrary.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The Agile manifesto, being the centerpiece of Agile, states its main values, but does not mention a word about delivering specific and varied values to stakeholders. Agile is far too centered around the developer. The world is seen from the eyes of the developer, the world revolves around the developer. The earth was once considered the center of the universe? Yes there are some customers, and even though not mentioned, some managers, sales people, users etc. They are out there spinning around us developers. But that is not really important enough to analyze in detail, agile is what we value as developers!? Make life easy for us - really delivering measurable value is secondary.
All the ideas in the Agile manifesto are 'solutions' to what is seen as convenient for developers. They are not a set of solutions to solve the challenges of our project, nor for our stakeholders. They don’t even know what these Stakeholders and their many values might be. How can one declare in a manifesto, “this over that” without knowing the real ends. What if “that” would better satisfy my Stakeholder needs? The Manifesto is overgeneralized, and should instead instruct us better on how to make intelligent decisions for our stakeholders.
Where, in the Scrum process diagram, is 'delivering value to stakeholders'? Not there is it? It is assumed that someone up there is picking valuable stuff to develop. We develop it, and it is valuable??? In alignment with the Agile Values, Scrum has as an output, “working software”. Guess what, who cares if your software is working!
The interesting questions are;
Does the software deliver improved value of any kind to my stakeholders?)
If yes. How much value of what kind?)
When and for how much resources?)
I have experienced lots of “working software” over the years that has giving me negative value. Hard to use, problem prone, slow, feature overloaded software that is “working”. Give me sw that is faster, easier, more secure and that improves my ability to do what I want to do. That is what I want. That is the type of thing that your Stakeholders want, and that they are paying us for.
Wait, you might say defensively, what about the Principles behind the Agile Manifesto http://agilemanifesto.org/principles.html
The first principle on their list is:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
So they put this up together with some other principles. That is swell, but it is on the second page. It needs to be on the first page, probably alone, and more sharply formulated, not mixing the Goal and the solution: hint "through" - there could be other better means - sometimes!.
And reading further down this list of principles, this principle has to compete with a long list of other principles, like
“Working software is the primary Measure of progress.”
Guess what, have you heard the expression, “what gets measured gets done”. So if you Measure progress as working sw, lets say through a burn-down chart, then what gets done? “Working sw” gets done. Not “Our highest priority” not value to stakeholders.
It needs to say: we Measure progress through the amount of value we have delivered to our stakeholders.
I recently worked on a project that was very successful in the eyes of the Scrum team that developed it, a very competent team. The product had all the functions and user stories it needed, it looked nice and professional, was developed within costs, working sw etc., but the business owners where screaming loudly, since the 'working' product resulted in less sales, than the product it replaced. We re-did part of the product with 100% focus on delivering value improvements to the stakeholders. We did this with the same Scrum team, we just gave them a very different focus.
This is a message, as loud and clear as I can be, to all fans of Agile.
It is not about working software. It is not about your preferred working process. It is not about user stories. It is not only about your customer or user.
It is all about delivering, to your set of Stakeholders, value improvements, which they care about, which makes their world better, within agreeable, minimum or pre-determined costs.
If that is not the main focus, if that is not clear to everyone on the team, you will eventually lose! If your methods are not focusing on delivering that value, as todays most popular Agile methods are not, they will fail to deliver, they will become last years fad.
What do you do? Develop sw? No, you (should say) deliver value to stakeholders!
Site Overview 
on Sun 31 of Jan., 2010 05:29 GMT+01:00
www.semat.org
