Why is Big Project more Fragile

Effective people-oriented management discipline, EA-driven governance practice, and high mature organizational capabilities. etc. are all KSF-Key Success Factors. 

IT management understands the basic KSFs for IT projects such as commitment, stakeholder involvement, SMART requirements, progress tracking and a few more. Most enterprises are good at doing projects between three and nine months. Statistically, the large projects requiring years of implementation or millions of budget fail significantly more often than regular small projects, why is the big project more fragile, and how to improve overall IT project from EA perspective?

No one factor is usually at fault; there is usually a snowball into the failure. Scope missed, features added by creep, development component delivery misses to testing, arbitrary date windows all contribute to dissatisfaction in the early phases of a project. To keep dates, features fall by the wayside and your program becomes back-loaded with delivery, increasing the pressure as costs rise and ROI starts to falter. The high-level categories of key failure points include.....
-change in business priorities
-inability to show incremental progress
-inability to scale effectively
-change in executive sponsorship
-key dependencies on modernization
-immature organizational capabilities 

Most large projects are that the nature of the challenge is not understood. And the nature of the challenge is people, not technology. These changes also require a significant change in the lives of the people involved. There are a few people oriented major reasons for projects to fail:
1). Lack of the right talent with mixed strength and skills working on the project. No technique, the process will save the project if you do not have a certain percentage of right talent.

2) People Issues: Every factor about large projects is rooted in the fact that people need to understand what is changing, what the impacts of those changes are, how they fit in the new world, and how they can participate in the change. Can they learn the new technology or will they be let go at the end? Will there be room for these employees in the new world. How does this affect their perceived expertise? All these things lead to people being afraid to commit to the new solution.
2). Poor Management, managers micromanage when they have no knowledge of what they are micro managing. They also make promises without checking with the team, do not supply the necessary resources, or engage the team to deliver, and lack of clear communication upon the people concerns listed at 2).

Every organization has a tolerance for the variance which, when exceeded, produces a failure scenario and results in a structural impact to, if not cancelation of, a project. Larger projects are usually associated with strategic imperatives and viewed as critical path elements on the route to enterprise transformational goals. This often results in heightened concerns about a project's success at the same time that its scope and complexity exceed the sponsors' and stakeholders' experience and understanding. As you might imagine, this confluence of factors, if not tightly managed, leads toward unnecessary tension and poor decision-making. One other thing to consider is that even well-managed projects are assemblages of interconnected parts and need constant small corrections to stay on track. When small disparities between expected and actual results occur on a small project with fewer work packages and, presumably, a lower integration burden, the overall impact is manageable. 

The small things are what cause all the problems. If engaging in a large project, it is usually about transformational change, not incremental change. This is true whether the change is technical or process oriented. And transformational change is expected to change the way the work is done. This, in turn, means that you are asking people to identify, estimate, and work to change systems in a way they have no experience with. So the first effect is that all your estimates are wrong. The next impact is that almost all of the transformational change is not designed. You think you can lay out a high-level "big system" blueprint without addressing the small things. The small things are what cause all the problems.

There big projects that should never have become big projects. Most often these are caused by neglect. Big project fail because the “big project process” isn’t understood. EA is a process. From an EA perspective, the best support may be to ensure that scope and requirements are understood early on. The input to the application or solution architects to ensure that flexibility in the components is part of their delivery and that any design decisions that need to be addressed are dispatched quickly and create the most flexible solution. Generally speaking, smaller projects with fewer deliverables and shorter dates will generally better focus and complete 'on time'. The development teams work urgently from day 1 and there is little desire to spend long windows debating solutions. The scope is tighter and generally is less prone to creep.

Risks need to be identified and risk mitigation efforts must be factored in, this is serious EA territory. The EA needs to work with the business and the solution architects who will be directing the battle plan. The EA needs to be fully aware of the complexities of the technical implications so that the solution, being designed by the solution architect, fits into the overall strategy that’ll win the war. In essence, each battle plan describes a set of “interfaces” that join the battle plans together. It should be noted that most massive technology projects are core portfolio investments that enable key business capabilities that most companies can't live without - so they ultimately get delivered because they have to. Sometimes they get finished but have greatly diminished value due to the rapid change of business. Most modern EA-based IT modernization strategies are designed to deliver incrementally over time to chunk up the risk of failure. 

Therefore, the effective people-oriented management discipline, EA-driven governance practice, and high mature organizational capabilities. etc. are all KSF-Key Success Factors to make IT project anti-fragile and improve the overall success rate of its project portfolio.