Question: As It Applies To The SDLC (software Development Lifecycle) And Briefly Discuss How You Might Eliminate Or At Least Reduce The Impact Of The Above Potential Project Failure Risks In The Swing Cartoon Below. Your Discussion Should Be Written In Terms Of The Key Systems Analysis And Design Tools, Methodologies, Management Methods, And. A tree swing cartoon or tire swing cartoon is a humorous graphical metaphor that purports to explain communication pitfalls in the division of labor in the development of a product. It depicts how different departments implement or describe a tire swing attached to a tree, and how different it is.

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

• The 'tree swing' cartoon has been used to explain or satirize perceived discrepancies in IT project management as early as the 1970s, with its earliest known iteration published in the March 1973 issue of University of London Computer Center Newsletter (shown below, left).
• A tree swing cartoon or tire swing cartoon is a humorous graphical metaphor that purports to explain communication pitfalls in the division of labor in the development of a product. It depicts how different departments implement or describe a tire swing attached to a tree, and how different it is from what the customer actually intended.

Tire Swing Software Development

According to the Project Management Institute, in 2007 61% of all “IT” projects failed or were halted before completion. In 2008, more than 75% of all projects exceeded budgets by 30%. All too frequently, IT projects fail to meet customer or user expectations. There are many risks inherent with creation in an enterprise IT environment: that the client is not sure what they want, that requirements were not properly documented, that change-orders were requested, that desired functionality was not possible or simply that the budget was not sufficient.

Cartoon Software Development Tree Swing Game

Cartoon Software Development Tree Swing Video

Rather than accepting these risks as part of the cost of software delivery, the Agile methodology seeks to tackle those risks head-on with an approach of iteration, review, user acceptance testing and, most importantly, communication.
In some cases the customer may know what they want but not what they need. As Henry Ford said, “if I had asked customers what they wanted, they would have said a faster horse.” The difference between what a customer wants and what they need may be substantially different and likely carries a substantially different cost as well.
In “Waterfall” practices, developers and consultants obtain all the documentation up front, because they want to make sure that the project is built just the way the customer want it. Why does this not work every time? They discussed how they wanted it done, they laid out plans; why is it taking so long?
The problem is communication; a “Waterfall” approach may get what a client wanted, but it may not always get what they needed. Also, the “Waterfall” approach is not designed for changing expectations. As Supreme Court Justice Potter Stewart once said “I can’t define it, but I’ll know it when I see it” (paraphrased). It falls on consultants and developers to find out what clients need, without taking more time or money. How do we do that?
The short answer – Agile. The long answer – ask, more and more, until the development process becomes a joint-effort between the stakeholders and the creators. Being wise comes from asking questions, while being smart comes from asking the right questions. The more the customer and their firm can be involved in software creation, the more they take ownership of the software and, most importantly, the more the software becomes what they need.
The Agile methodology has done a good job of bringing stakeholders closer to the project and allowing customer interactions with engineers to create beautiful software that matters. It is still evolving as more people can see the benefits of shorter feedback cycles and smaller batching, even moving to continuous delivery. Like Wayne Gretzky said, “a good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.”
This post is a collaboration between Max Milhan and guest contributer, Chase Doelling.
Chase is the Product Owner of Agile University at Rally Software Development, overseeing 70+ national Agile training courses with 1100+ attendees in coordination with 45 trainers. Chase is a CSM & CSPO and is obsessed with finding better ways to do everything.
You can see what he is up to at www.chasekaizen.com
Additional Reading:
Rally Software
Chase Kaizen