99.5% of large projects failed to deliver as promised. This is how to prevent it.
According to a research by Bent Flyvbjerg and Alexander Budzier on a sample of 1,471 IT projects showed that the average cost overrun was 27% - but one in six of the projects in the sample showed a worst-case scenario, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%.
99.5% of large projects failed to deliver as promised.
According to the famous textbook, Systems Analysis & Design 5th Edition - An Object-Oriented Approach with UML, 42% of all corporate Information Systems projects were abandoned before completion, 53% of all US government Information Systems projects were abandoned. Systems that are not abandoned are often delivered late, 80% of projects were over theer allotted time constraints, 72% were over budget, 55% contained less than full functionality.
Over the years I've talked to a lot of expert project managers, read dozen of books and articles on topics. There are 4 rules if followed can make your project delivery on time and under budget.
Far too many projects proceed based on undiscussed assumptions. That’s dangerous. As the adage has it:
"Don’t assume. Verify." "Always ask WHY?."
Conflicts about a project's ultimate objectives may be hidden by assumptions. As a result, the initial conception of the project may be off. And without clear agreement on the goal, it will be at greater risk of wandering off course when it encounters inevitable problems and complications. We may learn what the customers truly want rather than what they believe they want by asking thoughtful questions at the beginning of projects and paying close attention to the responses. By carefully listening to the customer, we can create something for them that they are unaware they desire.
Starting with questions, and really listening, feels unnatural. People suffer from availability bias, letting their thinking rush ahead based on whatever information they already happen to have. Asking questions puts a stop to that. “We are being curious, curiosity leads to invention.”
This is a concept that seems to be lost on some or just not well understood. The basic premise is that to be fully responsible for a project you need to have full authority over that project. That is, if you do not have authority over something like the ability to organize manpower for a task for instance then you can not be responsible for that task. The responsibility always falls on the person who has the authority to make the decision.
When I was working as a UX Designer for a firm, I was tasked with redesigning the task scheduling module of a JIRA-like project management software. After significant market research and multiple iterations, I came up with a design that was significantly more user-friendly and modern than what our competitors had. I wanted some specific UI Developers to work on the design as they had the necessary expertise to bring that vision to reality. There’s a tendency to marginalize creative people. I was told, 'OK, us big business guys know how to do this, just give us the design, and we’ll take it from there.' The project eventually took 6 months instead of the initially planned development time of 3 months. I become a part of coding team during 4th month of the project as well.
Control is indispensable. As an executioner, you must have it, and keep it, from beginning to end. Without control, the project is bound to go directionless.
Modern software project development has come a long way. No longer we are constrained by a simplistic waterfall or spiral model of development. Everything needs to be agile. When I was working for a multinational consultancy, we had International Market Centers as our client. They wanted us to build a platform that allowed businesses to easily list their products and manage them for in-person exhibitions. We had 6 months to deliver. Even before we started development, we showed dozens of concepts to client. We discussed every edge case. The outcome was were no change requests, and that’s a pretty unheard-of result for a very large project.
At key stages, when the project must commit to design decisions before work advances, the client must give approval. In this way, the design is enriched and strength- ened by the client’s perspective, while the meeting of minds that begins the project continues, iteration after iteration, following the maxim, “Try, learn, repeat.”
A successful project planning process consumes a great deal of time for everyone involved. For Execution Managers eager to have something to show for their efforts and get to the finish line, extended planning can be frustrating, even unnerving. For them, planning is pushing paper, something to get over with. Only developing and releasing are progress. If you want to get things done, they think, start doing it.
The sentiment is easy to understand. But it is wrong. When projects are launched without detailed and rigorous plans, issues are left unresolved that will resurface during delivery, causing delays, cost overruns, and breakdowns.
A scramble for more time and more money follows, along with efforts to manage leadership expectations. With leaders distracted in this manner, the probability of further break- downs—more scrambling, more delays, more cost overruns grows. Eventually, a project that started at a sprint becomes a long slog through quicksand.
The issue with software development is that it's actually, literally, impossible to predict everything that's going to happen. Raw developer estimates are wrong 90% of the time. There have been whole books written on the subject, all of which have 1 common solution to this problem: extensive planning and planning for failures.
The rules above attempt to convey meaning that can never be entirely put into words. Those of us who lack experience with following rules of this kind must keep that limitation in mind. The rules indicate directions of travel, but they are not road maps. To bring them fully to life, and to make decisions as adeptly as true experts, we must cultivate the underlying tacit knowledge: by doing.
Tweet to me at QM_Ashwin