What the Software Industry Can Teach Everyone Else About Curbing Failure and Delivering Value
Not to be blunt, but this project you’re working on, it is likely to fail. I’m sorry to break it to you, but it’s probably not going to turn out. It is beyond debate I’m afraid; business projects are prone to failure – particularly large and complex projects. There is some irony in that, no? The more you hope to achieve, the more likely you are to be unsuccessful. Cost related to failed projects on the national GDP and our collective productivity is massive. This cost doesn’t even include the careers detoured or jobs lost on the fiery embers of failed projects.
Again, excuse my frankness on this matter, but us IT/software/tech folks at this point are pretty well versed in the statistics. We know first-hand how big, expensive projects can fail. You’ve probably seen it; our reliance on technology in every aspect of our lives brings these IT failures to the forefront. But it is inaccurate to believe that failed projects are limited to technology. This dilemma is cross-cutting and affects your business just as much as it affects Uber, Facebook, and Youtube. Just to air everyone’s laundry without prejudice, here is a list of infamous non-software project failures:
- The French Panama Canal where the French attempted to construct a canal in Panama under the impression it would be easier than it was to complete the Suez Canal. The effort failed, and it cost $287 million. Two hundred and eighty-seven million dollars in the 1800s! Also, sadly more than 20,000 people died during the effort.
- Marble Hill Nuclear Power Plant in Indiana was abandoned unfinished in 1984 after spending $2.5 billion on the project.
- The Berlin Brandenburg Airport took 15 years to plan, began construction in 2006 and was initially expected to open on Oct 30, 2011. Now, seven and a half years later, the new scheduled opening is in 2020, and the current cost of the project is close to 50% above the approved budget of 5.4 billion euros.
- The Rio de Janeiro Olympics which were plagued by inhospitable living conditions, inadequate gaming facilities, political and social unrest, and a threat of a Zika outbreak.
This is just a short list of failed projects. The actual list, of course, is too long to enter here. You don’t want to end up on this list! But, alas, it is true that fewer than a third of all business projects are completed on time and on budget.
Have you been part of a project that either was not completed at all, went dramatically over budget, or finished with a product that no one wanted? It’s a terrible and disheartening position to find yourself. Why does this happen? How do we fix it? Well, the technology industry has been working to address the issue by looking at the processes we use to complete projects.
YOUR PROCESS IS FAILING YOU
In software, Waterfall has been the dominant product development practice for the past half-century. Many professionals and organizations outside of technology use Waterfall techniques to complete projects without knowing it is Waterfall. It’s just the process. Waterfall is a methodology for developing products that organizes work into large sequential steps. The process typically flows in one direction, which is forward – thus the term Waterfall. For example, the steps could be design, implementation, testing, deployment, and release.
The sequential approach of Waterfall means taking big steps instead of a more iterative and incremental approach. Big steps are more likely to fail. For one reason, it requires you to predict outcomes sometimes months or years ahead of time. Surely, predicting the future is a challenge; bad predictions lead to bad products, and bad products lead to failed projects.
With deployment and release as the final steps of the Waterfall sequence, feedback from stakeholders is limited. You primarily get feedback at the beginning and end of a product development cycle. In between, there could be months, even years. You see the problem here: this lack of feedback over a sizable period leads to a disconnect from current customer requirements and causes you to deliver a product of low business value.
In many ways, conventional project management solidifies the shortcomings of Waterfall. Project management is almost exclusively about delivering on time and managing resources versus delivery of a quality product that delights customers. It is about “just getting it done” on time. I bet we all, no matter what industry, have been in the terrible position operating under that slogan.
Waterfall was initially designed to create software much in the same way Henry Ford constructed automobiles. Given that, and these sorts of statistics (50% failure on large projects!), it is past time to reevaluate Waterfall as the de facto solution. Can you afford to continue in this manner? Failed projects help competitors, waste resources that are better spent on successful projects, demoralize employees, and harm your brand.
INCORPORATING A SCRUM FRAMEWORK TO CURB FAILURE AND DELIVER VALUE
So, how is the software and technology industry moving away from failed projects that “just get done,” toward curating a methodology for success and creating valuable products for their customers? Agile, most notably, Scrum has been the most impactful in inciting change in this direction.
Scrum is a process framework for resolving complex problems iteratively and incrementally to a create a high-value solution that elates customers. Scrum directly addresses many of the shortcomings of Waterfall with project management.
Scrum is:
- Empirical instead of predictive
- Iterative instead of sequential
- Concentrated on gathering continuous feedback instead of gathering in stages
- Value-focused instead of deadline-focused
- Self-organizing instead of control and command
EMPIRICAL: BASE YOUR DECISIONS AND PROCEDURES ON EXPERIENCE AND EXPERIMENT
What are you doing on September 21, 2021? Where were you yesterday? If the first question is easier for you to answer, go ahead and skip ahead to the module on magical people. For the rest of us, we already discussed how difficult it is to predict the future. But we can look backward with certainty. In Scrum, decisions are made based on experiment and experience. This is what it means to be empirical. For practical reasons, product development often requires a planning horizon. If so needed, keep the planning horizon to a limited amount of time.
ITERATIVE: ORGANIZE YOUR WORK INTO SMALLER STEPS
Scrum is iterative and incremental; not sequential. Instead of planning work in large stages, such as design and implementation, organize work in small steps (we call them sprints) where there is the opportunity for continuous feedback – especially stakeholder feedback. Taking small steps will make you nimble where you can adjust to market conditions and focus on delivering a product of high value. Typically in Scrum, sprints last one or four weeks and include a lot of broken down tasks. By the end of the sprint, you should have something to release.
CONTINUOUS FEEDBACK: STAY ALIGNED WITH CUSTOMERS AND STAKEHOLDERS
An important part of Scrum is the “daily Scrum.” This is short meeting (15 min), usually at the beginning of the day that allows each member of the project team to give a quick update on their status. The daily Scrum also helps frame the work of the upcoming day. Another event in Scrum is the Sprint Review. At the end of your one to four-week project sprint, your team gets together for an informal meeting. In the Sprint Review, your team shows what they have accomplished during the sprint to stakeholders of the project.
CUSTOMER VALUE: THIS IS YOUR PRIMARY FOCUS
Scrum’s focus is on delivering products of high-value. The goal should be more than simply getting a product or project completed. You want to deliver the most competitive product possible based on customer requirements. This requires continuous feedback and integration of the customer into the process – both of which are cornerstones of Scrum.
SELF-ORGANIZED: EMPOWER TEAM MEMBERS TO SELECT AND HOLD RESPONSIBILITY FOR THEIR WORK
Scrum development teams are self-organizing. A development team is anyone that contributes to or helps complete a product or project. No one tells the development team what to do. They estimate and select their work. This approach empowers development teams to take full responsibility for their work. When someone (i.e., the Project Manager) tells them what to do, they are much less accountable for their work. This does not only apply to software development teams but your team too. Empowered teams are much more successful.
STOP WASTING TIME AND MONEY AND DELIVER VALUABLE PRODUCTS
There is only one reason the continue with a Waterfall method – low expectation. Stakeholders will be pleasantly surprised when you occasionally finish a project on time and on budget working with a Waterfall process. I suggest a different approach. Captivate customers with successful products and instill a culture of high expectation and value. Instead of wasting resources on the occasional successful projects, start incorporating Scrum into your process today. Scrum has proven to be hyper-effective for us, as well as, other IT organizations. We intend to share this practice with you whether you’re an educational or financial institution; a marketing or production team; or interested in using Scrum to help manage your business. This article is the beginning of a series of posts related to Scrum and Agile for Non-software projects, so stay tuned for more information, tips, and tactics to introduce the Scrum Framework into your organization. Contact us, or comment below with questions or requests for more information as we go along.