Showing posts with label risk. Show all posts
Showing posts with label risk. Show all posts

Review Standish Group – CHAOS 2020: Beyond Infinity

Mike's Notes

I have been researching and reviewing the material referenced by Roger Sessions. This is about the Standish Group.

There is now a collection of Standish reference material in the library as part of the Roger Sessions collection.

Resources

References

  • Standish Group – CHAOS Report 2020

Repository

  • Home > Ajabbi Research > Library > Authors > Roger Sessions
  • Home > Handbook > 

Last Updated

01/06/2025

Review Standish Group – CHAOS 2020: Beyond Infinity

By: Henny Portman
Henny Portman's Blog: 06/01/2021

A few weeks ago, I received the latest report from the Standish Group – CHAOS 2020: Beyond Infinity – written by Jim Johnson. Every two years the Standish Group publish a new CHAOS Report.

These reports include classic CHAOS data in different forms with many charts. Most of the charts come from the CHAOS database of over 50,000 in-depth project profiles of the previous 5 years. You have probably seen some of those yellow-red-green charts showing e.g., challenged, failed and successful project percentages. 

The book contains ten sections and an epilogue:

Section I:

Factors of Success describes the three factors (good sponsor, good team and good place) the Standish Group has determined most seriously affect the outcome of a software project. Specific attention has been given how poor decision latency and emotional maturity level affect outcomes and the success ladder benchmark.

Section II:

Classic CHAOS provides the familiar charts and information generally found in CHAOS reports. E.g., resolution by traditional measurement, modern measurements, pure measurements and “Bull’s Eye” measurements.

Section III:

Type and styles of projects breaks down project resolution by measurement types and styles of delivery method.

In the next three sections we get an overview of the principles for the good sponsor, the good team and the good place. Each principle is explained in detail, including the required skills to improve the principle and a related chart showing the resolution of all software projects due to poorly skilled, moderately skilled, skilled and very skilled.

Section IV:

The Good Sponsor discusses the skills needed to be a good sponsor. The good sponsor is the soul of the project. The sponsor breathes life into a project, and without the sponsor there is no project. Improving the skills of the project sponsor is the number-one factor of success – and also the easiest to improve upon, since each project has only one. Principles for a good sponsor are: 

  • The Decision Latency principle
  • The Vision Principle
  • The Work Smart Principle
  • The Daydream Principle
  • The Influence Principle 
  • The Passionate Principle
  • The People Principle
  • The Tension Principle 
  • The Torque Principle
  • The Progress Principle.

Section V:

The Good Team discusses the skills involved in being a good team. The good team is the project’s workhorse. They do the heavy lifting. The sponsor breathes life into the project, but the team takes that breath and uses it to create a viable product that the organization can use and from which it derives value. Since we recommend small teams, this is the second easiest area to improve. Principles for a good team are: 

  • The Influential Principle
  • The Mindfulness Principle
  • The Five Deadly Sins Principle
  • The Problem-Solver Principle
  • The Communication Principle
  • The Acceptance Principle
  • The Respectfulness Principle
  • The Confrontationist Principle
  • The Civility Principle
  • The Driven Principle.

Section VI:

The Good Place covers what’s needed to provide a good place for projects to thrive. The good place is where the sponsor and team work to create the product. It’s made up of the people who support both sponsor and team. These people can be helpful or destructive. It’s imperative that the organization work to improve their skills if a project is to succeed. This area is the hardest to mitigate, since each project is touched by so many people. Principles for a good place are: 

  • The Decision Latency Principle
  • The Emotional Maturity Principle
  • The Communication Principle
  • The User Involvement Principle
  • The Five Deadly Sins Principle
  • The Negotiation Principle
  • The Competency Principle
  • The Optimization Principle
  • The Rapid Execution Principle
  • The Enterprise Architecture Principle.

Section VII:

Overview of the CHAOS Database explains the process of creating project cases and adjudicating them for inclusion in the CHAOS database.

Section VIII:

New Resolution Benchmark offers an overview of this new benchmark, which will replace the original in the CHAOS database. The Project Resolution Benchmark is a self-service instrument that uses a three-step method to help benchmark your organization against similar organizations on the basis of size, industry, project mix, types, and capability.

Section IX:

The Dutch Connection describes and celebrates the contributions made by our colleagues in the Netherlands and Belgium and their effect on our research.

Section X:

Myths and Illusions debunks some typical beliefs about “project improvement.” By using the data points from the database. The busted myths are:

  • Successful projects have a highly skilled project manager
  • Project management tools help project success
  • All projects must have clear business objectives
  • Incomplete requirements cause challenged and failed projects.

Epilogue

The Epilogue takes a look at 60 years of software development. The Standish Group has come up with four distinct evolutionary periods of developing software. The first period, which ran roughly from 1960 to 1980, is called “the Wild West”. The Waterfall Period ran from 1980 to about 2000. The Agile Period started around the year 2000 – and their prediction is that it will end shortly. They are now seeing the beginning of what they call the Infinite Flow Period, and they imagine that the Flow Period will last at least 20 years. In the Flow Period, there will be no project budgets, project plans, project managers, or Scrum masters. There will be a budget for the pipeline, which is a pure direct cost of the output. There will also be a cost to manage the pipeline, which will reduce the current project overhead cost by as much as 90%. This will be accomplished by reducing and eliminating most of the current project management activities. Functional description of work will come into the pipeline and out of the pipeline fully usable. Change will happen continuously, but in small increments that will keep everything current, useful, and more acceptable to users, rather than startling them with a “big bang boom” result (in a next blog I will dive into some details of the Flow method).

Conclusion:

CHAOS stands for the Comprehensive Human Appraisal for Originating Software. It’s all about the human factor. If you are looking for areas of improvement of your organizational project management skills (good sponsor, good team and good place), this guide gives a great overview where you could get the highest benefits from your investments. It gives excellent insights in root causes for project failure or success.

A pity this is the last CHAOS report (there will be an updated version in 2021, but that will not be a completely new CHAOS report). Given that The Standish Group are recommending you move to Flow, they state that there is no need for them to continue to research software projects. I would say not all projects are software projects, why not collect datapoints from non-software projects and start building a database and analyze the impact of the good sponsor, the good team and the good place for these projects too.

To order CHAOS 2020: Beyond Infinity

A study in project failure

Mike's Notes

Here is another study into the cause of IT waste.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

26/05/2025

A study in project failure

By: Dr John McManus and Dr Trevor Wood-Harper
British Computer Society: 06/09/2008

Research highlights that only one in eight information technology projects can be considered truly successful (failure being described as those projects that do not meet the original time, cost and (quality) requirements criteria).

Despite such failures, huge sums continue to be invested in information systems projects and written off. For example the cost of project failure across the European Union was €142 billion in 2004.

The research looked at 214 information systems (IS) projects at the same time, interviews were conducted with a selective number of project managers to follow up issues or clarify points of interest. The period of analysis covered 1998-2005 the number of information systems projects examined across the European Union.

Number of IS projects examined within European Union

Rank Sector No. of projects examined
1 Manufacturing 43
2 Retail 36
3 Financial services 33
4 Transport 27
5 Health 18
6 Education 17
7 Defence 13
8 Construction 12
9 Logistics 9
10 Agriculture 6
Total   214

Project value in millions of Euros

Value range in millions (€) Number of projects Percentage(%) Accumulative (%)
0 – 1 51 23.831 23.831
1 – 2 20 9.346 33.177
2 - 3 11 5.140 38.317
3 - 5 33 15.421 53.738
5 - 10 4 1.869 55.607
10 - 20 87 40.654 96.261
20 - 50 6 2.804 99.065
50 - 80 2 0.935 100.000
Totals 214 100.00 100.00

At what stage in the project lifecycle are projects cancelled (or abandoned as failures)?

Prior research by the authors in 2002 identified that 7 out of 10 software projects undertaken in the UK adopted the waterfall method for software development and delivery. Results from the analysis of cases indicates that almost one in four of the projects examined were abandoned after the feasibility stage of those projects completed approximately one in three were schedule and budget overruns.

Project completions, cancellations and overruns

Waterfall method lifecycle stage Number of projects cancelled Number of projects completed Number of projects overrun (schedule and/or cost)
Feasibility None 214 None
Requirements analysis 3 211 None
Design 28 183 32
Code 15 168 57
Testing 4 164 57
Implementation 1 163 69
Handover None 163 69
Percentages 23.8% 76.2%  

Of the initial 214 projects studied 51 (23.8 per cent were cancelled) - a summary of the principal reasons why projects were cancelled is given below. Our earlier research elaborated on the symptoms of information systems project failure in three specific areas: frequent requests by users to change the system; insufficient communication between the different members of the team working on the project and the end users (stakeholders); and no clear requirements definitions. Whilst communication between team and end users was still perceived as an issue within some projects; the top three issues from this study are: business process alignment; requirements management; and overspends.

One notable causal factor in these abandonment's was the lack of due diligence at the requirements phase, an important factor here was the level of skill in design and poor management judgement in selecting software engineers with the right skill sets. Equally the authors found some evidence in poor tool set selection in that end users found it difficult to sign-off design work - in that they could not relate process and data model output with their reality and practical knowledge of the business processes.

Key reasons why projects get cancelled

  • Business reasons for project failure
  • Business strategy superseded;
  • Business processes change (poor alignment);
  • Poor requirements management;
  • Business benefits not clearly communicated or overstated;
  • Failure of parent company to deliver;
  • Governance issues within the contract;
  • Higher cost of capital;
  • Inability to provide investment capital;
  • Inappropriate disaster recovery;
  • Misuse of financial resources;
  • Overspends in excess of agreed budgets;
  • Poor project board composition;
  • Take-over of client firm;
  • Too big a project portfolio.

Management reasons

  • Ability to adapt to new resource combinations;
  • Differences between management and client;
  • Insufficient risk management;
  • Insufficient end-user management;
  • Insufficient domain knowledge;
  • Insufficient software metrics;
  • Insufficient training of users;
  • Inappropriate procedures and routines;
  • Lack of management judgement;
  • Lack of software development metrics;
  • Loss of key personnel;
  • Managing legacy replacement;
  • Poor vendor management
  • Poor software productivity;
  • Poor communication between stakeholders;
  • Poor contract management;
  • Poor financial management;
  • Project management capability;
  • Poor delegation and decision making;
  • Unfilled promises to users and other stakeholders.

Technical reasons

  • Inappropriate architecture;
  • Insufficient reuse of existing technical objects;
  • Inappropriate testing tools;
  • Inappropriate coding language;
  • Inappropriate technical methodologies;
  • Lack of formal technical standards;
  • Lack of technical innovation (obsolescence);
  • Misstatement of technical risk;
  • Obsolescence of technology;
  • Poor interface specifications;
  • Poor quality code;
  • Poor systems testing;
  • Poor data migration;
  • Poor systems integration;
  • Poor configuration management;
  • Poor change management procedures;
  • Poor technical judgement.

What is the average schedule and budget overrun?

In examining the cases it was noted that the average duration of a project was just over 26 months (115 weeks) and the average budget was approximate 6 million Euros, (Table 5). In many instances information on a project being over schedule and over budget will force senior management to act, however, the search for the underlying factors should begin else where in the projects history.

The pattern that emerges from a synthesis of case data is complex and multifaceted. In a few of the of cases examined the project commentary and history was ambiguous; however, once a decision had been made to support a project which was over schedule or over budget the ends usually justified the means irrespective of the viewpoints of individual project managers or stakeholders.

Cost and schedule overruns (N=69)

Projects From Sample 2 (2) 11 (13) 19 (32) 25 (57) 12 (69)
Schedule Overrun  11 weeks 29 weeks 46 weeks 80 weeks 103 weeks
Range Average  Budget + 10% Average  Budget + 25% Average Budget + 40% Average Budget + 70% Average Budget + 90%
Cost Overrun €600,000 €1,500,000 €2,400,000 €4,200,000 €5,400,000

What are the major causal factors contributing to project failure?

Judgements by project stakeholders about the relative success or failure of projects tend to be made early in the projects life cycle. On examination of the project stage reports it became apparent that many project managers plan for failure rather than success. 

If we consider the inherent complexity of risk associated with software project delivery it is not too surprising that only a small number of projects are delivered to the original time, cost, and quality requirements.

Our evidence suggests that the culture within many organisation's is often such that leadership, stakeholder and risk management issues are not factored into projects early on and in many instances cannot formally be written down for political reasons and are rarely discussed openly at project board or steering group meetings although they may be discussed at length behind closed doors.

Despite attempts to make software development and project delivery more rigorous, a considerable proportion of delivery effort results in systems that do not meet user expectations and are subsequently cancelled. In our view this is attributed to the fact that very few organisation's have the infrastructure, education, training, or management discipline to bring projects to successful completion.

One of the major weaknesses uncovered during the analysis was the total reliance placed on project and development methodologies. One explanation for the reliance on methodology is the absence of leadership within the delivery process. Processes alone are far from enough to cover the complexity and human aspects of many large projects subject to multiple stakeholders, resource and ethical constraints.

Although our understanding of the importance of project failure has increased, the underlying reasons still remain an issue and a point of contention for both practitioners and academics alike. Without doubt there is still a lot to learn from studying project failure.

Going back to the research undertaken there is little evidence that the issues of project failure have been fully addressed within information systems project management. Based on this research project failure requires recognition of the influence multiple stakeholders have on projects, and a broad based view of project leadership and stakeholder management.

Developing an alternative methodology for project management founded on a leadership, stakeholder and risk management should lead to a better understanding of the management issues that may contribute to the successful delivery of information systems projects.

Worldwide cost of IT failure (revisited): $3 trillion

Mike's Notes

Nine years ago, I came across the writings of Roger Sessions about the cause of IT failure waste. I then discovered the writings of Gene Kim et al from IT Revolution. The annual figure for IT failures exceeds US$3 trillion. 

I will locate those references and republish them here.

This waste has become the problem that Pipi was built to help solve.

Resources

References

  • IT Complexity White Paper  by Roger Sessions

Repository

  • Home > Ajabbi Research > Library > Authors > Roger Sessions
  • Home > Handbook > 

Last Updated

25/05/2025

Worldwide cost of IT failure (revisited): $3 trillion

By: Michael Krigsman
ZDNET: 09/04/2012

Michael Krigsman is an industry analyst and the host of CxOTalk, which tells stories of innovation and opportunity with the world's top business and technology leaders. He is a frequent speaker and panel moderator at technology conferences and advises the most successful enterprise companies on marketing and communications strategy. Michael's work has been referenced in the media over 1,000 times and in more than 50 books..

Calculating the global impact of IT failures on an annual basis is a worthy goal. However, aside from the challenge of collecting data, failure itself has no clear definition, subjecting the entire effort to assumptions and guesses. Still, several years ago, one analyst attempted to quantify the data in a noble, yet ultimately flawed, effort.

Also read: Worldwide cost of IT failure: $6.2 trillion Critique: $6.2 trillion global IT failure stats

Related: British Computer Society:A study in project failure

Nonetheless, the challenge of quantification remains. For this reason, I invited two qualified experts to re-assess the worldwide economic impact of IT failure. Gene Kim was the founder and former CTO of Tripwire, Inc., co-author of The Visible Ops Handbook, and a co-author of an upcoming book called When IT Fails: The Novel; his colleague, Mike Orzen wrote the book Lean IT and consults on IT operations and business transformation. They are currently co-authoring a new book called The DevOps Cookbook.

The two experts calculated the global impact of IT failure as being $3 trillion annually. They supplied the following text to explain their logic:

For just the Standard & Poor 500 companies, aggregate 2012 revenue is estimated to be $10 trillion. If 5 percent of aggregate revenue is spent on IT, and conservatively, 20 percent of that spending creates no value for the end customer - that is $100 billion of waste!

(The 20 percent assumption is an extremely conservative number when you consider that when we analyze the value streams of almost all processes across all industries, we discover over 80% of the effort creates no value in terms of benefit to the customer. Mike Orzen's work value stream mapping in many of the largest IT groups around the world consistently shows the same results.)

Here's another approach at calculating the total waste in IT worldwide: Both IDC and Gartner projected that in 2011, five percent of the worldwide gross domestic product will be spent on IT (hardware, services and telecom). In other words, in 2011, approximately $5.6 trillion was spent on IT.

There are two components to IT spend: capital projects and operations/maintenance.  If we assume conservatively that 30 percent of IT spending is for capitalized projects, and that 30 percent of those projects will fail, that's $252 billion of waste!

But IT is like a free puppy -- the lifecycle cost of the puppy is dominated by the "operate/maintain" costs, not the initial acquisition costs. If we conservatively estimate that 50 percent of global IT spend is on "operate/maintain" activities, and that at least 35 percent of that work is urgent, unplanned work or rework, that's $980 billion worldwide of waste!

What reward can we expect through better management, operational excellence and governance of IT?  If we halve the amount of waste, and instead convert it into 5x of value, that would be (50 percent * $1.2 trillion waste * 5x). That's $3 trillion of potential value that we're letting slip through our fingers!

That's a staggering amount of value, 4.7 percent of global GDP, or more than the entire economic output of Germany.

My take: These are the most reasonable numbers I have seen on the global economic impact of IT failures. Unlike previous estimates, which considered complicated matters such as lost opportunity costs, this formula is simple and credible.

Are we ready? Understanding just how big solar flares can get

Mike's Notes

I'm gathering information about massive solar flares and their risk to electrical systems, including data centres.

  • What are they?
  • How often do they happen?
  • What risk do they pose?
  • How to build robust resiliency into a data centre
  • Is a Faraday Cage the answer?
The article below is copied from the excellent Knowable Magazine. A detailed paper about the Carrington Event is included in the resources.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Knowable Magazine
  • Home > Handbook > 

Last Updated

19/05/2025

Are we ready? Understanding just how big solar flares can get

By: Christopher Crockett
Knowable Magazine: 17/09/2021

Christopher Crockett is a staff researcher for Knowable and a freelance science writer living in Arlington, Virginia. He is thankful for the sun but wouldn’t want to see it when it’s angry.

On May 1, 2019, the star next door erupted.

In a matter of seconds, Proxima Centauri, the nearest star to our sun, got thousands of times brighter than usual — up to 14,000 times brighter in the ultraviolet range of the spectrum. The radiation burst was strong enough to split any water molecules that might exist on the temperate, Earth-sized planet orbiting that star; repeated blasts of that magnitude might have stripped the planet of any atmosphere.

It would be bad news if the Earth’s sun ever got so angry.

But the sun does have its moments — most famously, in the predawn hours of September 2, 1859. At that time, a brilliant aurora lit up the planet, appearing as far south as Havana. Folks in Missouri could read by its light, while miners sleeping outdoors in the Rocky Mountains woke up and, thinking it was dawn, started making breakfast. “The whole of the northern hemisphere was as light as though the sun had set an hour before,” the Times of London reported a few days later.

Meanwhile, telegraph networks went haywire. Sparks flew from equipment — some of which caught on fire — and operators in Boston and Portland, Maine, yanked telegraph cables from batteries but kept transmitting, powered by the electrical energy surging through the Earth.

The events of that Friday evoked biblical descriptions. “The hands of angels shifted the glorious scenery of the heavens,” reported the Cincinnati Daily Commercial. The actual impetus was a bit more prosaic: The skies had been set ablaze by an enormous blob of electrically charged gas, shot out from the sun following a flash of light known as a solar flare.

A graphic illustrates some of the ways that the sun influences space weather, including solar flares (which occur at the sun’s surface), coronal mass ejections (large amount of material erupting from sun and getting picked up by solar wind); solar wind (electrically charged particles constantly flowing from sun); and a geomagnetic storm (a disturbance in Earth's magnetic field caused by the CME).

Space weather encapsulates the prevailing conditions in the solar system caused by the solar wind and the sun’s far-reaching magnetic field. Sudden changes on the sun, such as flares and eruptions of material, are like weather fronts, bringing with them magnetic “storms” that can be felt on the planets. On Earth, this can cause stunning auroras, but it can also create havoc with electronics. The flash of light from a flare takes about 8 minutes to reach Earth; solar material expelled from the sun in a coronal mass ejection (CME) may take hours to days to travel the distance. Magnetic storms may be brief or last for many days.

Such a blob — a tangle of plasma and magnetic fields — is known as a coronal mass ejection. Upon arrival at Earth, such an ejection can trigger the most ferocious of geomagnetic storms. The 1859 storm, named the Carrington Event for the scientist who witnessed the flare that preceded it, has long been upheld as the most powerful wallop that the sun has ever delivered.

But in recent years, research has indicated that the Carrington Event was just a taste of what the sun can throw at us. Tree rings and ice cores encode echoes of dramatically stronger solar storms in the distant past. And other stars, such as Proxima Centauri, show that even the most energetic documented solar outbursts pale in comparison with what is possible.

Nevertheless, the Carrington Event offers important clues to what the sun might have in store for Earth in the future, solar physicist Hugh Hudson writes in the 2021 Annual Review of Astronomy and Astrophysics. “Danger lurks for humanity’s technological assets, especially those in space,” writes Hudson, of the University of Glasgow. In the wake of a Carrington-like event today, entire power grids could shut down and GPS satellites could be knocked offline.

Understanding just how severe solar storms can be provides insights into what the universe may sling our way — and maybe how to foretell the next one so that we’re better prepared when it happens.

Anatomy of a flare

Roughly 18 hours before the 1859 event brightened Earth’s skies, an English astronomer noticed something strange on the surface of the sun.

While working in his observatory, Richard Carrington saw two brilliant points of light emerge from among a clutch of dark sunspots and vanish within five minutes. Another English astronomer, Richard Hodgson, saw the same thing, noting that it was as if the brilliant star Vega had appeared on the sun. At the same time, compass-like needles at England’s Kew Observatory twitched, a hint of the magnetic storm about to ensue.

Before then, no one knew about solar flares — mostly because no one was tracking sunspots every clear day the way Carrington was. Decades would pass before astronomers and physicists could unravel the physics of solar flares and their impact on Earth.

Images show Richard Carrington’s original drawings of sunspots and the powerful solar flare that emerged.


In 1859, English astronomer Richard Carrington was making this sketch of sunspots (left), when he saw two beads of light emerge from the large cluster of spots near the top. Carrington drew the first appearance of the flare as two bean-shaped regions nestled in among the spots (labeled A and B in close-up at right). Five minutes later, the two white spots had drifted to the right and faded considerably (marked C and D).

CREDIT: S. PROSSER, OXFORD UNIVERSITY PRESS 2018 (LEFT) / RICHARD CARRINGTON, PUBLIC DOMAIN (RIGHT)

A solar flare is an eruption on the sun, a sudden flash of light — usually near a sunspot — that can release as much energy as roughly 10 billion 1-megaton nuclear bombs. The trigger is a sudden, localized release of pent-up magnetic energy that blasts out radiation across the entire electromagnetic spectrum, from radio waves to gamma rays.

Many solar flares, though not all, are accompanied by a coronal mass ejection, a massive chunk of the sun’s hot gas blown into space along with a tangle of magnetic fields. Billions of tons of sun stuff can billow out into the solar system, crossing the 150 million kilometers to Earth’s orbit in anywhere from about 14 hours to a few days. 

Most solar eruptions miss our planet by a wide margin. But occasionally, one gets aimed right at Earth. And that’s when things can get interesting.

About eight minutes after a solar flare, its light reaches Earth in a flash of visible light. That’s also when a spike in ultraviolet light and X-rays sprays the upper atmosphere, causing a slight magnetic disturbance at the surface. That was the twitch the magnetic instruments at the Kew sensed in 1859.

The coronal mass ejection can trigger a geomagnetic storm when it encounters the magnetic field that envelops Earth. The disturbance to the magnetic field induces electrical currents to course through conductors, including wires and even the planet itself. At the same time, high-speed charged particles spewed by the sun crash into atoms in the upper atmosphere, lighting up the aurora.

Close up of filaments erupting from surface of glowing sun.

On September 6, 2017, the sun emitted a powerful X-class solar flare — a designation reserved for the most intense flares. Seen here in ultraviolet light captured by NASA’s orbiting Solar Dynamics Observatory, the flare was one of the strongest seen in years and came amid a spate of solar eruptions that month. The glowing threads are scorching filaments of plasma ensnared by magnetic fields arcing over the sun’s surface.

CREDIT: NASA / GSFC / SDO

The 1859 flare has long been, and remains, a standout in its energy and effects on Earth. Comparably powerful solar eruptions are often referred to as “Carrington events.” But it does not stand alone.

“It’s oftentimes described as the most intense storm ever recorded,” says Jeffrey Love, a geophysicist at the US Geological Survey in Denver. “That’s possibly not exactly true, but it certainly is one of the two most intense storms.” Or three or four.

In May 1921, the sun dealt our planet a geomagnetic storm on par with the Carrington Event. As in 1859, a brilliant aurora appeared well beyond the polar regions. Telegraph and telephone systems broke down, with some sparking destructive fires.

And just 13 years after Carrington spied his eponymous flare, another solar storm came along that by some measures may have topped it. “It looks now, based on aurora and sparse magnetometer measurements, that an event in 1872 was probably larger than the Carrington Event,” says Ed Cliver, a solar physicist retired from the US Air Force.

These storms show that the Carrington Event wasn’t a “black swan,” Hudson says. If anything, the sun has been holding back in the modern era. Evidence from the more distant past points to a few solar storms that make the Carrington Event seem almost puny by comparison.

Forgotten flares

Trees have long memories. Each year of growth chronicles tidbits about environmental conditions at the time in concentric annual rings. From those rings researchers can reconstruct scenes from Earth’s past.

Some cedar trees in Japan recall a tsunami of atomic particles hurled from the sun around the year 775. Those trees recorded a significant uptick in carbon-14, a radioactive variant of carbon that trees absorb from the atmosphere. Carbon-14 emerges from run-ins between atmospheric nitrogen and cosmic rays — high-speed particles from space that pummel our planet daily. Some solar flares shower Earth with an excess of cosmic rays, which ramps up production of carbon-14. The change in carbon-14 levels recorded in 775 was about 20 times larger than the normal ebb and flow from the sun, researchers reported in 2012.

“The clear suggestion there was that super events could happen, because this was a factor of 10 — if it was a solar flare — a factor of 10 or 20 or more greater than the Carrington Event,” Hudson says.

Image shows the green glow of the northern lights hovering above a nighttime landscape.

In the early hours of March 1, 2011, a ripple in the solar wind whacked Earth’s magnetic field and triggered a minor geomagnetic storm, causing the ethereal aurora seen here over the Poker Flat Research Range in Alaska.

CREDIT: NASA / GSFC / JAMES SPANN

A carbon-14 boost in tree rings showed signs of another sizable solar event in 994. Ice cores from Antarctica showed a corresponding increase, in both 994 and 775, of beryllium-10, another product of cosmic rays — adding more certainty to the tree ring findings.

Looking farther back in time, a study of ice cores suggests a third similar event around 660 BCE. And in August (in a paper still undergoing peer review), researchers reported two more carbon-14 spikes in tree rings from around 7176 BCE and 5259 BCE, possibly on par with the 775 event.

It’s hard to directly compare these past storms with the Carrington Event, says Ilya Usoskin, a space physicist at the University of Oulu in Finland and a coauthor of the August study. The 1859 flare did not produce a particle downpour on Earth, so there are no carbon-14 counts to compare. But the 775 event appears to be one of the strongest solar particle storms recorded in the last 12,000 years, Usoskin says.

There is a catch, Hudson notes. Tree rings are laid down annually, so a few smaller flares within the span of several months might appear as one big event in the tree ring record.

But even then, any one of these smaller flares may still have been impressive. “Every one of those events would be at least on the order of three times as big as the Carrington Event in terms of its energy,” Cliver says.

That, however, is still modest compared with some other stars in our galaxy.

Super flares

If life does exist on the planet orbiting Proxima Centauri, it probably has a rough go of it.

“You really are looking at having something like a Carrington Event happening daily,” says Meredith MacGregor, an astrophysicist at the University of Colorado Boulder. Even stronger “super flares,” like the one she and colleagues spotted in 2019, may go off roughly every other day. Her team spotted that flare, possibly 100 times as powerful as the Carrington Event, after watching the star next door for just 40 hours.

With a near-constant barrage of flares, any atmosphere clinging to the rocky planet snuggled up close to the star would never have time to recover. “Yes, a Carrington Event [on Earth] would fry some electronics and would ruin GPS signals,” MacGregor says, “but it’s not going to destroy the habitability of our planet.”

A view of a star-filled sky shows the Centauri system with the brilliant Alpha Centauri A and B prominent in upper left and a much dimmer and smaller Proxima Centauri circled and labeled in lower right.


The star Proxima Centauri and its neighboring duo of Alpha Centauri A and B are the closest stars to the sun, lying a mere 4.2 light-years away. Proxima, the nearest of the trio, is a dim red orb with frequent, powerful flares that buffet the Earth-mass planet that orbits close to it. 

CREDIT: DIGITIZED SKY SURVEY 2. ACKNOWLEDGEMENT: DAVIDE DE MARTIN / MAHDI ZAMANI

To be clear, Proxima Centauri is not like the sun. It’s an M dwarf, a diminutive orb that glows red. And these tiny stars are famous for their oversized flares. But some sunlike stars can send up super flares as well.

This realization has come from telescopes in space designed to look for planets around other stars. NASA’s now-defunct Kepler telescope did this by looking for subtle dips in starlight as planets crossed in front of their suns.

Over four years, Kepler recorded 26 super flares — up to about 100 times as energetic as the Carrington Event — on 15 sunlike stars, researchers reported in January. NASA’s ongoing TESS mission, another space-based telescope hunting for exoplanets, found a similar frequency of superflares on sunlike stars in its first year of operation.

The Kepler data imply that sunlike stars experience the most powerful of these flares roughly once every 6,000 years. Our sun’s most powerful eruption in that time span is an order of magnitude weaker — but could a super flare be in our future?

“I don’t think any theory has sufficient predictive capability to mean anything,” Hudson says. “The leading theory basically says that the bigger the sunspot, the greater the flare.” Sunspots mark where the sun’s magnetic field punches through its surface, preventing hot gas from bubbling up from below. The spot looks dark because it’s cooler than everything around it.

And that is one difference between the sun and its eruptive neighbors. Super flares seem to happen on stars with cool, dark spots far larger than ever appear on the sun. “Based on known spot areas, there would therefore be a limit,” Hudson says.

The intricacies of any star’s magnetic machinations — spots, flares, etc. — are still poorly understood, so tying all these observations into one cohesive story will take time. But the quest to understand all this might improve predictions about what to expect from the sun in the future.

Flares that are powerful enough to disrupt our power grid probably occur, on average, a few times a century, Love says. “Looking at 1859 kind of helps put it in perspective, because what’s happened in the space-age era, since 1957, has been more modest.” The sun hasn’t aimed a Carrington-like flare at us in quite a while. A repeat of 1859 in the 21st century could be disastrous.

Humanity is far more technologically dependent than it was in 1859. A Carrington-like event today could wreak havoc on power grids, satellites and wireless communication. In 1972, a solar flare knocked out long-distance telephone lines in Illinois, for example. In 1989, a flare blacked out most of Quebec province, cutting power to roughly 6 million people for up to nine hours. In 2005, a solar storm disrupted GPS satellites for 10 minutes.

The best prevention is prediction. Knowing that a coronal mass ejection is on its way could give operators time to safely reconfigure or shut down equipment to prevent it from being destroyed.

Building in extra resiliency could help as well. For the power grid, that could include adding in redundancy or devices that can drain off excess charge. Federal agencies could have a stock of mobile power transformers standing by, ready to deploy to areas where existing transformers — which have been known to melt in previous solar storms — have been knocked out. In space, satellites could be put into a safe mode while they wait out the storm.

The Carrington Event was not a one-off. It was just a sample of what the sun can do. If research into past solar flares has taught us anything, it’s that humanity shouldn’t be wondering if a similar solar storm could happen again. All we can wonder is when.

What if

Mike's Notes

This is a note to self; there are some questions I need to answer.

I'm doing some helpful free "start-up" training at NZTE, CreativeHQ, Startup Aotearoa, etc., which involves thinking about some hard questions and putting words onto several canvases. The people are all excellent, making me do a lot of thinking.

Pipi is not a simple app. It uses a novel architecture to help solve enormous, complex, and challenging problems.

How do I explain to anyone interested in what Pipi provides?

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/05/2025

What if

By: Mike Peters
On a Sandy Beach: 20/02/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

  • A complete enterprise SaaS system took 24 hours to automatically deploy for a customer.
  • Built out of reusable modules that automatically sync with no limit on the number of modules.
  • New modules can be simply and quickly created using no code.
  • It can start small and cheaply with minimal risk with one module, then add more as needed.
  • No sales engineers.
  • All self-service.
  • Fully configurable by their DevOps team using no code.
  • The enterprise SaaS was 100% open-source.
  • Its underlying industry model was constantly improved by the users of all deployments.
  • Industry Ontology and standards-based.
  • Customer data stays with the customer and is invisible to the platform.
  • Any human language or writing script can be used.
  • Community-provided translation and localisation
  • Its code base was completely obfuscated (all UUID).
  • Each deployment had a unique code obfuscation.
  • Only the UI, API and stored data use actual words.
  • The platform is a closed-source black box with all parameters visible.
  • A unique enterprise SaaS system was fully delivered on time and on budget.
  • Costs are cut by an order of magnitude.
  • Long-term low-cost of ownership.
  • It can scale simply.
  • Able to make use of existing tools like Kubernetes, Docker, etc.
  • Designed to run on most Cloud providers, giving users options and data sovereignty.
  • Encourages an open ecosystem without moats, including 3rd party support, training, plugins, etc.
  • Had a fully-synced closed-source visible digital twin for experiments and system learning.
  • It can be integrated via API without restrictions.
  • It didn't need a super-computer with thousands of cores.
  • The whole thing is owned by a public good foundation, so there are no investors, corporate highjacking or enshittification risks.
  • Public open handbook.

Open questions

  • What kind of problems does Pipi solve?
  • Why do these problems exist?
  • Why solving these problems is essential?
  • Would it be beneficial to society?
  • What's wrong with the existing alternatives?
  • Would people use it?
  • Would enough people pay to use it to make it viable?
  • Would it reduce the waste of software failure?
  • What kind of Foundation would be needed?
  • How would the developer community be supported?
  • How would R&D be supported?