By Sid Richardson, PMP
Raise your hand if you’ve run a software project using the Agile Methodology and have run a software project using the more traditional waterfall project management methodology? I’m sure there are many of you!
Having worked in project management for nearly 30 years, I have run software projects using a variety of different methodologies and I can certainly appreciate the benefits that they all bring to the table.
One true constant in life—and in software development—is change, and I’ve seen my fair share. Here’s what I’ve learned along the way.
The ‘80s were RAD
In the mid-1980s, a software development methodology called Rapid Application Development (RAD) began to take off.
James Martin developed the RAD approach at IBM and formalized it in 1991 by publishing a book called Rapid Application Development. The RAD approach was based on working closely with the customer and prototyping solutions quickly to deliver a final product. The intention was that there would be less effort placed on the planning aspects and more on the customer collaboration aspects.
While RAD was not necessarily a true project methodology for software development, I believe it led to an easier buy-in to the Agile project methodology many of us use now.
Meeting the Requirements
When I was working in Europe in the early-to-mid 1990s, there was a heavy emphasis on formal approaches to project management and software projects. This may sound strange—or it may provide flash-backs for some of you!—but I remember a time when absolutely no analysis or design work was allowed to begin until the user requirements (typically volumes of paper in large bound files) were received in hardcopy form with sign-off by senior company executives.
Can you imagine working in that type of environment?
The traditional waterfall approach to software development projects was rather rigid, but I can understand the reasoning—the leadership wanted to have a high level of confidence in what would be delivered.
Fragile Agile
Fast forward to almost 20 years ago and many organizations encountered internal pushback and some challenges with the adoption of Agile as a software development methodology. The common joke thrown around in the middle of an Agile rollout was that it was “Fragile.”
Since the requirements in an Agile methodology are more dynamic, things eventually settled down and as someone said to me recently, “I guess we’ve come into an age of sticky notes and Sharpies.”
Design on My Mind
At KAI Partners, we have recently started using Design Thinking. Design Thinking provides a creative, solution-based approach to solving problems and is also sometimes known as human-centered design or user-centered design. It’s on the side of creative problem solving, which—being a creative type of guy—is why I gravitate toward it.
Design Thinking encourages organizations to focus on the people or the customer—and it’s the people-centered focus that leads to better products, services, and processes.
While it’s not a software development methodology, Design Thinking can be used as a problem-solving tool to accompany almost any software development methodology you choose to use.
Is there a Perfect Approach?
So, with all these different methodologies, is one better than another? Well, it depends on the project at hand!
One of the common drawbacks to the RAD approach of the 1980s was the lack of scalability. RAD typically focused on small to medium-sized projects and teams. Then Agile came along in the early 2000s and, as a lean philosophy, could certainly be applied at an enterprise level.
What I think works best is a blended methodology that combines the best features of a variety of different approaches.
If the last 30 years in project management and software development have taught me anything, it’s that there are components and approaches of many different methodologies that—when combined—can make a robust and flexible way to deliver high-quality, timely products to the customer.
And, considering that a new methodology will likely make its way to the surface soon, we can’t get too comfortable. Luckily, as project managers and agents of change, we are used to the continual cycle of change and it will be up to us learn the new methodology, prepare our teams, and adapt our work accordingly.
Need support on your next project? KAI Partners can help your organization implement the software development methodology that works best for you and your needs!
About the Author: Mr. Richardson’s passion is Data Warehousing, Business Intelligence, Master Data Management and Data Architectures. He has helped Fortune 500 companies in the US, Europe, Canada, and Australia lead large-scale corporate system and data initiatives and teams to success. His experience spans 30 years in the Information Technology space, specifically with experience in data warehousing, business intelligence, information management, data migrations, converged infrastructures and recently Big Data. Mr. Richardson’s industry experience includes: Finance and Banking, government, utilities, insurance, retail, manufacturing, telecommunications, healthcare, large-scale engineering and transportation sectors.