The Happy Project Saboteur

Principles of Project Failure:  How to sabotage a project, without anyone noticing you.

by Agent 20-7

Version 050619.0002 

‘Something like 42% of all IT Projects Fail’ (Google that! 7 million hits).

Some of you might like to know ‘how to sabotage a project,’ an IT project, or any other project.
This could be because you are an agent of the government, and it is your job — sort of like James Bond 007.

I can immediately give my formal permission, for those who want to continue to train project sabotage agents, to use data saboteur methods, as described here, in their formal training. For example in Agile [5, 6], Lean [1], KanBan [1], Balanced Scorecards, Harvard Business School MBAs, Scaled Up Agile Methods [7], Design Sprints [2], DDD [4], Prince 2, OKR [3], and countless other teachings, which already understand how to sabotage projects (no help from my me is needed there). However, they are all claiming the opposite (success) for their methods.

I should especially credit Google (OKR [3], Design Sprint [2]) and Toyota (Lean [1], Quality Function Deployment [1, 9] ) who, through their method agents, have already managed to fool so many, into believing that their corporate success, is due to these sabotage techniques.

This has proven an excellent tool to reduce real competition for them, from potential competitors. That tactic of misleading the competition, as to their real methods, is their real secret to competitive success.

A secondary credit is due to the many universities worldwide who have made sure that their students lack the analytical ability, to see through the false promises, of the most popular project management methods. They (academic staff) still believe in these weak pop methods, and imagine that the methods will prevent failure, rather than, as is the case, cause it.

A ‘special thanks’ to the giant body-vendors, like 'Giant Systems Integrators' (but I am not naming any at all), who continue to passively accept use of ineffective project methods - rather than to help us (by bringing in effective value-delivery methods to help), and who also help us to ‘avoid detecting the project sabotage methods I specify below’.

Though I needn’t thank the giant body-vendors so much here, for they are well-rewarded by massive payments over many years, for delivering no value, and then getting a contract to start all over again. Also, these body-shoppers serve the useful purpose of being our scapegoat, when all fails, and it does not seem to hurt their reputation at all, for they continue with the same corporate and government clients anyway.

Fortunately for us project saboteurs, the body shoppers never display any ideals, like ‘helping their clients get value for money.’ The big contractors' ideals are the Almighty Dollar. For example, I have never (OK, Once in Norway) heard of them accepting a No Cure No Pay Contract [15], or of paying back all the money for totally failed projects.

They keep their spoils, and lust for more, from the same wronged customers. Of course, they are not to blame, in my opinion. They are excellent ‘saboteur tools.’ The customer, Caveat Emptor, has the primary responsibility to make cost-effective contracts, and they haven’t got a clue as to how to do it. They also seem uninterested in doing or learning no cure no pay contracts. The business schools, as usual, are no help in managing good contracting. So they can share the honor for the failures.

In addition, as the UK Parliamentary Inquiries into IT failures pointed out, the big suppliers provide an alternative career path, for the civil servants who gave them the lucrative contracts. And the civil service responds in kind, by employing former consultants at the big consultancies, to ensure continued lucrative contracts, for doing nothing useful. 'Revolving Doors’ it is called.
This helps to make sure that young, smart graduates, employed by the big consultancies, are gainfully employed, as nobody else in their right mind, would hire them, with their lack of experience, and lack of understanding, on ‘how to succeed’, and on ‘how to avoid project failure’.
This is undoubtedly a good balance of ‘using government taxpayer’s money; to keep the unqualified employed,’ and balanced with ‘their paying taxes,’ which can then be recirculated into more such ‘failed projects.’ ‘Win Win,’ as managers like to say.

This cycle of non-value delivery also helps keep the 'unemployed statistics’ down; and is less taxing on the social services. Politicians delight!

It could be that you, a potential Project saboteur, personally, are so angry at your stupid employer/client/boss/managers that you want revenge, before you leave them, for a better job. The important thing is that you do not get caught at it: or even ‘get detected, and blamed,’ later.

Sweet revenge is that ‘they never knew what hit them.’ Well, you can send them an anonymous message afterward. “You idiots deserve a humiliating failure. My revenge is sweet”.

It is, of course, most fun, to sabotage projects, when you can actually be there, during the failure process, and watch them running around scared shitless, stressed out, blaming each other, and anyone else, afraid of losing their job, or afraid of losing their cash-cow, the immature, client.

I should warn you that these dirty tricks will even work on people who are intelligent, well-educated, and well-trained in anti-project-sabotage; who are idealistic, high-principled, and who use their common sense, because they are blinded by a muddy culture. However, there are so few such idealistic people, that you can pull this Project sabotage off with most people.

 NASA (Clearlake Texas) told me they used 7 concentric rings of system redundancy as backups, for the moon return, in 1969. Except for the moon liftoff motor, which then had no moving parts. So the ardent Project saboteur needs to have perhaps 7 concentric rings of laudable-evil, to finally sabotage projects. I hope this blog will supply you with these tools.

THE 7 MAIN PRINCIPLES OF FAILURE

1. Only analyze ‘customers' and ‘users’  forget the other 48 stakeholders.

The most important thing is ‘users and customers’ [5]. Use cases, User Stories are ‘requirements.’ After all Amazon’s Jeff Bezos’ mantra is Customer, Customer, and Customer. And he is the Richest. Right? Wrong! Well, right for the project saboteur, of course.

The delightful result, for us, Project saboteurs, is that this ‘User-Customer focus’ will take all attention away, from some of the project’s most-critical stakeholders. The very ones we want to help destroy the project — the ‘other’ stakeholders.

Figure 1: A generic stakeholder map, showing there is much more than users and customers to contend with.

Good Project saboteurs call this ‘diverting project attention from critical factors.’ Sort of like magicians do, divert your attention.

A simple example. Did you notice all the trouble Facebook and CEO/Founder Mark Zuckerberg has been getting into with the European Commission, and US Congress, about privacy, and misuse of Facebook (allowing the Russians), to rig elections?

Enough to destroy the Company and its share value. Wait a minute, EU and USA Congress are not customers and users. They are just lawmakers and regulators.

Russians are clearly amongst the top project-saboteur professionals. Ask Hillary! Imagine if Putin would offer a public course, “Become a Certified Project saboteur Master’ (2 days).

Russians are in good company with North Koreans, Chinese, and Iranians. I’d like to think the CIA is equally professional, so that ‘Our Side’ has a chance in the ‘Premier League, Cyberwar Championships.’ These cyber contests are much better than real ‘bloody’ wars.

In fact, Russians are so good that I think they should be encouraged to join NATO (Not Any Terrific-Saboteur Organization ?). Putin will need a follow-up job sometime, when he gets tired of ruining Russian democratic election projects; so he could be made CSO (Chief Sabotage Officer) of NATO. His earlier KGB experience would come to good use again.

I do realize that I could get shot, or poisoned, for saying the above, but at least you can then be sure who did it. But first someone will have to crack the secret code of my 20-7 identity. And, sorry Tom, I laid out seriously distracting disinformation, to get them to think it was you, who wrote this. I’ll bet they will be surprised when their ‘wet’ project is a failure — killing the wrong journalist. And I do apologize in advance for any inconvenience, Tom. We ‘project saboteurs’ have to look out for ourselves. And believe me ‘Privacy, Safety, and Security are our most important concerns’ as they say, when they screw up, like aircraft software design. [12]

IT/Software/Management people (unlike more-mature ‘systems engineering’ people, INCOSE.org) still (95% of them) do not ‘get it.' There are quite a lot of critical stakeholders (who can kill your project), which have critical stakeholder requirements (which can kill your project).

So one ‘project saboteur’ (sorry, ‘Bad-Project-Destruction Idealist’) tactic, which is certain to destroy, or seriously wound a project, is to focus on the user+customer and to forget the other 48 stakeholders. This is guaranteed to lead to the project’s failure to identify a critical stakeholder need, and failure to identify a consequent Critical Stakeholder Value Requirement.

So when the project fails, partly or totally, because the Stakeholder is outraged at the low quality, or high cost, of the system, or outraged at violation of a critical constraint (‘don’t rig Presidential Elections’), your ‘sell them on user stories as requirement’ project sabotage tactic, will have succeeded, as it has massively in IT systems, for the last decade or so.

Please do not misinterpret me. I am not against analyzing users and customers needs. Indeed it is an improvement on the previous generation, of project saboteur tactics; called “Enthral Them With The Latest Technology.”

Users and customers don’t really know what they want, anyway. (Jobs, not the Bible!)

2. Do not clarify stakeholders values. Give them the technology they say they want.

This brings us to the touchy subject of clarifying the stakeholders' needs.

The ‘advanced and certified project saboteur’ knows that if their target-project has managed to thwart you, the ‘User/Customer Only’ project saboteur (I accidentally typed ‘errorist’ just now and created an interesting term) then your Second Line of Attack, is to make sure that even if the project is lucky enough, to identify a critical stakeholder value, we need to make sure it is ‘Value Obfuscated’. That is my fancy new term today, for Management Bullshit, or Management C.R.A.P (Common Replies And Phrases).

This ‘Obfuscation’ Project saboteur Tactic, is incredibly easy to make happen, in the real project world. In fact, no effort at all is needed by the Project saboteur. You see, Projects are habitually, and by training, suicidal. They do a large number of things which doom the project to failure, without any explicit Project Saboteur (OK, ‘PS’) intervention. This is not only time-saving, and cost-saving for the PS, but it has the decisive characteristic that nobody can ever pin the blame on you, the humble saboteur. Just remain passive. Don’t teach them Clear Communication [11].

Managers and projects will quite naturally, continue to express stakeholder objectives, in a vague language, in bullet points on Powerpoint charts (another Project saboteur Weapon, along with Yellow Stickies). They never learned at any school, even universities, how to spot defective requirements and objectives, let alone ‘what to do to clarify them,’ so that everyone really understands the project objectives.

This ‘Vague Values’ strategy is almost better than preventing the projects from analyzing their critical stakeholders! They have, somehow, managed to get past your first project saboteur barrier. They have identified the critical stakeholders, in spite of our efforts to prevent such insights. However, now they will still sabotage themselves, with their ‘unclear value requirements,’ without even knowing it!

“We believe in State of the Art Safety,” they babble [12], like grownup executive children, do.

When they should have been more precise, for example ‘No attempt to compete with Airbus, will ever cause us to keep our Airplanes flying, after a deadly crash, because of software and pilot-training design-faults, that have not been determined and rectified.’

I have seen such companies from the inside, extensively, and can verify that they hold the ideals of quality high: but there are constant pressures from some managers to put deadlines before quality, and it now looks like a breach in their 'quality defenses' managed to happen. Both the ‘stakeholders wall’ (pilots, airlines, passengers, internal quality instances), and the ‘values walls’ were breached (updated information needs, failsafe system needs, training process quality), as far as I can see.

I think that if we Project saboteurs, continue to make sure that clear, quantified, specification of critical system-values, are not taken seriously: we shall continue to be victorious.

I also hope we can find a way to distinguish between ‘Evil projects,’ which are worthy of our espionage efforts; and on the other hand ‘Good projects,’ where we would hope to keep these saboteur methods away from. This has always been the ‘saboteurs Dilemma.’

If distinguishing between Good and Evil projects is too difficult, we could start by sabotaging simple useless or unprofitable projects. That might help us keep our weapons sharp. It might build our ‘Project saboteur credibilityI’, in both the Good and Evil communities; which will be handy, when we finally figure out which is which.

I hope we don’t have to wait for thousands of years for this Good-Evil distinction to be computed, and I would be most annoyed if the answer turned out to be ’42’ since I am pretty sure, we do not even know the precise question, yet. Hi Doug!

Keep the C. R. A. P. Flowing, as usual. Long live Project sabotageism!

Figure 2a. The metric ‘time between project failures’ (TBPF), is a function of the ‘time to suffer through the previous failure’ (TTSTTPF) + ‘waiting around for the next project failure’ (WAFTNPF) time.

Source: https://blog.fosketts.net/2011/07/06/defining-failure-mttr-mttf-mtbf/

The true Project saboteur tries to maximize the frequency of this Failure Cycle by Concurrent Project Engineering, combined with Early Failure (‘Fail Fast’ method) and the ‘Throw-Away Failed Systems’ method, to avoid lengthy boring Repair sequences, of failed projects.
This does have the unwanted side-effect, of minimizing the ‘Total Failure Damage/Year,’ but it does have the primary effect of providing the Project saboteur with More ‘Failures Per Month’ to enjoy.

The pure-hearted Project Saboteur is not sadistic and does not enjoy seeing their victims suffer prolonged loss, disturbance, or agony. Not too much, anyway. Things should be as ‘agony free’ as possible, but not too much more.
The PT is an idealist, serving society, in ensuring that the frequency of Project Failures is ‘as high as possible, but not too high.’ Because that is the way society can learn lessons faster if it could be bothered to learn them.

Here below is a perfect example (2C) of the total management BS (Benevolent Sagacity) and techno-babble surrounding us.
The text is a strong dose, of all possible desired values, and with absolutely no evidence that the author knows what he is saying.

(2C.)
"Agile product management is lightweight, continuous, smaller in terms of effort, and less linear.
The era of building big, long-term strategies designed upfront, both for business models and product lines, is behind us. Agile has enabled businesses to accelerate their value delivery to the market – but often at the expense of product strategy. The reason for this is that, led by a widely pervasive and mistaken view that Agile is only about delivering software and a desire to get on the “Agile train,” businesses failed to determine the role of strategy, longer-term planning, and customer research in an Agile organization. Agile was being used to create prioritized backlogs for delivering value – often in the form of widgets or features that may or may not have been what customers need most – and most were happy just to deliver something on time and within budget.
Today we recognize the weakness in lacking product strategy and customer understanding: customers don’t care about more features. They care about solving their problems – and Agile product management restores an organization’s capability to determine what customers need and what market opportunities might exist or need to be created. Agile product management, among other things, ensures that product backlogs represent our best learning about customer needs and desires while helping realize successes hypothesized by Agile product managers."

The author reeks of wonderful idealism, and I want to fight on his side, emotionally. However, the 'rational me', the one that wants to survive long enough to be the greatest Project saboteur on Earth, 20-7, suspects the author might not know any useful corroborating facts, or is maybe hiding them, or both.

In any case, he is clearly (or is it ‘not so clear’ ?) with us, in supporting the ‘end result’ of Rapid-velocity Agile Project Sabotage Culture. May his inspiring words (whatever he intends to say) live in eternity and be chiseled in Hieroglyphs (so that agile developers cannot read them).

3. Commit to all the ‘nice-sounding’ designs and strategies. Especially the ones on the managers’ PowerPoint slides.

Of course, the very best, and time-tested way, to sabotage projects, is to specify a sexy-sounding ‘means’ (technology),
rather than the actual ‘purpose’ (value improvement level).
This ‘Means Instead of Mere Ends’ (MIME) method, is almost as effective, as a Project sabotageism method, as is the method of ‘Critical Alienation of Values Entertained’ (C.A.V.E.-Mans method) discussed above.

(the ‘tongue out’ was because paparazzi annoyed him ‘too much’). 

Strategy ‘Alienation’ means 'Obfuscation', meaning: ’fuzzy,’ ‘unclear,’ ‘vague,’ ‘ambiguous’ and ‘confusing’ - if ‘Obfuscation’ confused you).

In fact, the charm of the ‘Means Instead of Mere Ends’ (MIME) method is, that you can pretend to develop 'extremely clear specifications', for the wrong means; for an ‘undefined set of ends,’ and you are guaranteed to fail to get, what any stakeholder really wants.

This ‘MIME’ method is a tactic similar to selling a project management method, which gives 6-times the Velocity for producing User-Story-related computer programs, with no apparent connection to any well-defined Stakeholder Values; except the vague User Story [13] justification, like ‘SO THAT it gives better security.’

Sales-people try to sell IT-professionals, on the 'blinding speed’ of producing Common Replies And Phrases (like ‘better security’: which nobody defines, or clarifies, or can test delivery of).

We could call this Project-saboteur tactic: ‘Rigorous Scientific Engineering of The Wrong S.H.I.T.’ (Solutions, Helpfully Incapacitating Truth).

To guarantee project failure, while confusing managers to think they got what they required and paid for, there is hardly a better and more common tactic than asserting, incorrectly, that the technology (like ‘digital transformation’) is the main objective, and that all desired stakeholder values (or, if you really want to confuse people, ‘all advanced features and functions’), will be delivered in time, if we follow that ‘SSS’ (Sexy Sounding Strategy). Sometimes called the S.S. Strategy by Right-Wing Project Saboteurs.

This paper is for the Left-Wing Project Saboteurs: with the motto ‘If You Go Left, you will be Right, but if you go Right you will get Left.’

If this long sentence above, was confusing to you, we are merely trying to demonstrate the art of Project Saboteur Obfuscation (PSO), which is a meta-method for ‘Digital Transformation’ (DT, aka Delirium Tremens). PSO operates at 42 times the velocity of ordinary S.H.I.T., which is approximately 7 times faster than some agile methods.

Dr. Deming and I liked to go to the ballet together in London (1980s). The Ballet Projects never seemed to get hit by Ballet Saboteurs. There is a lot of old motivated culture and discipline there, that IT projects might learn something from, for success, so keep IT people away from ballets and the like.

I had to get tickets on Friday nights, because the other weekdays he was preparing the next day’s Kaizen increment to the courses, he had held for decades, out of respect for his students. I never was sure where he put his ‘incremental improvements’ on his one '14 Points’ acetate overhead projector foil (Google it kids). Maybe he just incremented his mind a bit.

4. Make use of the most widespread project development methods to ensure failure. Popularity is a sure sign of oversimplification. Methods which oversimplify, have failure rates that are over 50%, for years on end. No-one does anything effective about the Simplification Failure.

Wouldn’t it be good for society, if the most-popular, and well-known, project management methods, were also the most cost-effective ones?

Unfortunately there seems to be a ‘Law of POP’: Popularity Outlaws Performance.

You see, fortunately for Project saboteurs, in their very own ‘2-day Master-Of-The-Universe PT Certification Course’, they cannot sue the course trainers for criminal negligence, since even the lawyers don’t understand what was taught, well enough to claim illegal practice.

From a Project saboteur point of view, it is vital that the ‘POP Method Certification’ courses are priced ridiculously high, because quite enough people confuse price with value. The only ‘value’ quantification they understand is money.

This outrageous pricing, combined with managers who are willing to hire people with the ‘right’ certification, ensures that these Certified professionals (the ones with very little academic baggage, because their parents could not pay $50,000/year university fees) will flock to the courses, at company expense, in hopes of getting a job, at a company, which is obviously too-badly managed, to understand that the Certified Professionals are producing nothing of value. 

The people, like me, without too much academic baggage all had a wonderful opportunity to use their intelligence and common sense. Most of them blew it. 

The reassuring aspect of this situation is that these inept managers are likely to get fired in the long term, due to not being able to show value for their efforts. This will bring in a new crop of equally inept managers (with the same MBA Certification) which still have no clue as to what these ‘Certified professional’ IT people do.

This will keep inept professionals employed, and paying taxes, until the Chinese takeover, because the Chinese are productive; and have a smattering of Certified Zen Masters, and Martial-Arts Masters to boot.

Unfortunately from the Project Saboteur point of view, when the Chinese take over, the fun is over, since these sabotage methods will not work well with them. The Project saboteur Methods are developed recently, in the last 50 years in Western IT Cultures. The Chinese get things done anyway, as they have for thousands of years. Undisturbed by the short-term fancies of Western Cultures. You can’t trump that!

Wait a minute, is it possible… no it can’t be. That is too far fetched, that the corrupted ‘project management methods of the West’ were seeded as a ‘disinformation plot’ by the Chinese. [1] Surely the Chinese are not as devious as the Japanese, or Americans? Is Confucius a nickname for ‘Confusing’?

THAT would be the ultimate example of Project Saboteur Methods: to use them to conquer other civilizations (not just projects)!

I wonder if the Chinese then might be persuaded to hold 2-day Certification Courses, for no more than $5000 a pupil, on the subject of ‘Undermining Immature Civilizations.’

A free Huawei Cellphone to every student, with the Graduation Certificate written entirely in Chinese, so most people, without a Google translator App handy, cannot figure out exactly what the students are certified in. Does the Google Translator app do hieroglyphics yet?

5. Make sure no one ever estimates 'how effective’ a design or strategy will be (effective at delivering critical values).' Or ‘what it will cost in the short term or long term.’ Such estimates are rarely perfect (so forget it), and might distract from using perfectly nice and modern-sounding designs. Like ‘AI,' ‘blockchain,’ or ‘big data.’

It is normal in politics, and business, even in technology - to discuss and argue in colorful terms, about the goodness and badness of strategies, or political options.

Indeed Great Wars have been fought over highly-emotional words, like ‘democracy’ (as in DDR, German Democratic Republic, the one with the Wall), ‘solidarity' (as in communism), freedom (as in ‘racial cleansing’), and ‘liberty’ (as in ‘we will let you out of the Gulag sometime’), and ‘will of the voters’ (as in ‘Brexit’).

The key point from a True-Patriot Project-Saboteur point-of-view is to make sure that your ‘target’ projects NEVER clarify the meaning of these strategies, in terms of objective measures of human values (like 20% more happiness, and 50% more security). 'What-cha-gonna get fur yur idea?’ (that’s ‘slang’)

If these wonderful-sounding ideas were to be ‘human-value estimated’, ‘presented’, and finally ‘measured’ during the project, to check on ‘actual value delivery’: then the ‘political’ projects could never sell them, to the same generation, more than once, because the false promises would be exposed. The next generation, however, can be fooled, since they do not remember, do not learn their history, and are busy with social apps anyway.

https://www.simflexgroup.com/portal/?page=Solutions.Solutions.Value%20Chain%20Strategy

6. For goodness sake. Do not waste energy trying to estimate the negative side-effects of otherwise-exciting strategies, on your critical objectives and costs. Such insights would delay your ‘will to get on with it,’ and eagerness to overrun the deadline.

It is a disaster for improving project failure, as noted above, if ‘clear numeric relationships’ are made between the ‘proposed means’ and the ‘ends they can serve.’

Fuzzy emotional claims are all it takes to sell most people.

However, the Project Saboteur must also make sure we retain our strict and simple-minded one-dimensional focus (numeric or wordy). And be sure never to estimate, or even measure, in advance, or by early experiment, the unpleasant side-effects of our strategies. True Gentlemen do not condescend, to refer to such repugnant experiences, in polite company.

The interesting side effects, to avoid thinking about, are the ‘negative effects’ on other stakeholder-valued objectives, and costs.

‘Ignorance is bliss’ they say. We PTs must keep people in bliss. People prefer it that way. There are so many unpleasantries in today’s world. We need not expose even more bad shit than necessary.

The fact that, for example, extreme ‘security’ and ‘privacy’ strategies, destroy ‘usability’ and ‘accessibility’, as side effects, must be hidden, until the project is finished, and has irrevocably failed, or just been ‘accepted with disgust’, as ‘the only existing option’. This latter type of failure has a lovely euphemism: ‘Challenged’ projects.

The Project Saboteur must subtly encourage people to ‘dream the extreme,’ and thus to mess up everybody else’s dream. Extremists are fascinating, and ‘balance’ is boring.

“There are three side effects of acid: enhanced long-term memory, decreased short-term memory, and I forget the third.”  - Timothy Leary


7. Reward your project team by effort expended: NOT 'No Cure, No Pay'.

Finally, to ensure failure, we must avoid any legal contract, or organizational structure, where people or businesses, are ‘rewarded in proportion to value delivered.’ That would be unfair to inferior performers, who need to feed a family too.

To be sure of promoting project failure, we need to have fixed-price, fixed deadline, project contacts. We need fixed salaries, no matter how badly projects go, and stable employment. ‘Fixed’ is good for stability! (whatever that means)

If complex software projects got finished ‘on time and under budget,’ as in the PS-dreaded Cleanroom method at IBM [14], then we would not know what to do with our gigantic development staffs, and might not risk going bankrupt from huge unnecessary expenses. Much of which costs, our local national government will cover, if we are ‘too big to fail.'

‘Filling out the available time’ is the socially right thing to do. No idle hands.

'Infinite bug testing' can be used, to use up any available resource, with practically no disturbing ‘successful project increase’ side effect. You can never actually be sure you have actually found that ‘last bug.’

Fortunately, IT people have no sense of history; after all, the American Way is ‘New is Better.’

So Universities, as well as Agile Training Courses, have conspired to prevent most everybody from knowing about the world's best ever (and ‘agile’) software project management method [14]. (or do you know of a better one?).

Besides, we generate a vast quantity, of variations of, agile and lean methods, so there is at least one, to every one-person consultancy. Most of these have little evidence of what they are good for, except to give their perpetrator (the ‘perp’ as they say on TV) some exclusive method, and dreams of agile wealth.

It is actually good that we generate so many dubious methods, because they help keep the project failure rate high.

Fortunately, there is no serious regulated process of evaluating new development methods, like there is for medicines; so most development methods seem to continue the high rate of failed projects.

If medicine did the same lack of quality control and regulation , 50% of all pill takers would be dead, and another 40% would be Challenged. It is a good thing dead projects have no fathers; only successful projects do.

Active Project Saboteurs can relax in such chaotic environments.

So fortunately, the ‘real degree of failure’ is hidden by the fact that so few projects ever define ‘success and failure’ quantitatively, to begin with.

Most IT projects can claim to ‘not clearly have failed’ since most have 'failed to be clear' (about purpose).

Summary

The Project Saboteur need hardly lift a finger to ensure project-failures.

The failure rate is high and stable over the long term, proving that there is no cultural ability to change to success, or to 'zero project-failures' (a PT shudders, at the thought of zero failures), as the norm.

Management cannot seem to ‘manage,’ and the Business Schools cannot seem to teach effective management.

The motivation to succeed is not as strong as the rewards of failure.

There is almost no fun in being a Project Saboteur. No challenge.

But at least, creative and innovative ‘foreign agents’ can have some fun spreading even worse methods, than are popular now, if it gets boring, or if the failure rate declines.

And last, but not least: be sure your Project Sabotage is Ethical!

More ethical than your opponents in counter-sabotage

Don’t be evil.

Strike that.

Do 'Project Sabotage' Right!

Thanks for bearing with me.

20-7

PS If you thought I was being sarcastic and joking …
‘dead’ serious is my ‘agent’ style.

A license to kill projects is my will.

References

[1] “The Ohno Conspiracy” with (How ‘Lean’ was ‘misunderstood’ by the West)

Quality Function Deployment (QFD) detailed method analysis of method weaknesses.

http://concepts.gilb.com/dl954

[2] ‘Design Sprint

A Critical Analysis

and a Constructive Alternative’

3 Analytical Slides on 'Design Sprint'. 2 Critical Analysis and 1 with my alternative Startup Planning Week.

http://concepts.gilb.com/dl945

(May 12 2019)

[3] Tom Gilb

OKR Objectives and Key Results: what’s wrong and how to fix it.

http://concepts.gilb.com/dl879

Paper 2 Feb 2017

[4] Gilb Opinion on DDD Domain Driven Design

http://concepts.gilb.com/dl947

May 2019

[5] Tom Gilb:

"How well does the Agile Manifesto align with the principles that lead to success in product development?”

Paper

January 8 2018

http://concepts.gilb.com/dl921

[6] “What are the Dangers of Current Agile Practices (like Scrum and others),

and

How Can We Fix Them?”

SLIDES pdf 6MB

for London Metropolitan University, BCS Student Chapter Lecture 201117

http://concepts.gilb.com/dl910

[7]  A  “Beyond Scaling: Scale-free Principles for Agile Value Delivery - Agile Engineering”

http://www.gilb.com/dl865

  (Paper)

(Jan 8 2016, Updated 310519 )

[7 B] “SCALE-FREE:

Practical Scaling Methods

for Industrial Systems Engineering”

lecture slides

http://concepts.gilb.com/dl892

[8] What is Wrong with Balanced Scorecard, slides

http://www.gilb.com/DL135

[9] How problems with Quality Function Deployment's

(QFD's) House of Quality (HoQ) can be addressed by

applying some concepts of Impact Estimation (IE)

http://www.gilb.com/DL119

[10] “Stakeholder Power:The Key to Project Failure or Success

including 10 Stakeholder Principles”

http://concepts.gilb.com/dl880

2016 Paper

[11] “Principles of Clear Communication”, 2018 Digital book.

The Anti-Project-saboteur Handbook.

  €14, https://www.gilb.com/store/oJCCxtsM

If you can’t afford this price for saving your expensive project, I’ll send you a free copy.

But then you send me 50% of the value of your next project, OK?

Project saboteurs are trying to suppress this disinformation, as they call it, Fake News.

One clear signal is the paper publishers show no interest, and earn big on Project Tourist Books, n sectors such as Agile, Lean, Digital Transformation

[12] CEO Dennis Muilenburg says Boeing will maintain its “relentless commitment to make safe airplanes even safer.”  Mar 18, 2019

Me-thinks he doth protest too much.

https://en.wikipedia.org/wiki/The_lady_doth_protest_too_much,_methinks

[13] User Stories

A. http://vimeo.com/53159408

2012 Talk Video Recording, in English

8 Minutes

Published on Dec 15, 2012

Tom Gilb discusses the dangers of User Stories at ‘Smidig 2012’ (annual conference of Agile software development in Oslo.)

B. ‘User Stories: A Skeptical View’

www.gilb.com/DL461

User Stories paper by Tom and Kai Gilb

In Gilbs' Mythodology Column, Agilerecord.com March 2011

[14] Cleanroom

MIlls and Quinnan Slides

http://concepts.gilb.com/dl896

Mills, H. 1980. The management of software engineering: part 1: principles of software engineering. IBM Systems Journal 19, issue 4 (Dec.):414-420.

Direct Copy

http://trace.tennessee.edu/cgi/viewcontent.cgi?article=1004&context=utk_harlan

Includes Mills, O’Niell, Linger, Dyer, Quinnan pg. 466 on

Library header

http://trace.tennessee.edu/utk_harlan/5/

Mills, Harlan D.; Dyer, M.; and Linger, R. C., "Cleanroom Software Engineering" (1987). The Harlan D. Mills Collection. http://trace.tennessee.edu/utk_harlan/18

http://trace.tennessee.edu/cgi/viewcontent.cgi?article=1017&context=utk_harlan

(ACTUAL DOWNLOAD) IEEE

Mills Generally

http://trace.tennessee.edu/utk_harlan

[15] A. ‘Agile Contracting for Results The Next Level of Agile Project Management’: Gilb's Mythodology Column Agilerecord August 2013

concepts.gilb.com/dl581

B. ‘Agile Contracting for Results’

Smidig 2014 Oslo Ten minute talk slides

http://www.gilb.com/dl832

[16] There is much said about the fact that nobody can prove Einstein said the ‘Things should be a simple as possible, but no simpler’. Here are a few notes from my archives. 20-7

Here is the nearest we could find of what Albert said: (Close enough) “On the Method of Theoretical Physics”
Albert Einstein
Philosophy of Science

Vol. 1, No. 2 (Apr., 1934), pp. 163-169

“It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.” 

“It is essential for our point of view that we can arrive at these constructions and the laws relating them one with another by adhering to the principle of searching for the mathematically simplest concepts and their connections.”

Source: http://www.jstor.org/stable/184387?origin=JSTOR-pdf&seq=1#page_scan_tab_contents

used as ref 6 in paper 12-3-17 ’Too Simple”
’Too Simple’,
‘Methods should be as simple as possible for delivering value, but no simpler.’ http://concepts.gilb.com/dl903

The Quote Investigator takes on this http://quoteinvestigator.com/2011/05/13/einstein-simple/