It’s November and you’ve got a killer idea for an app.
It will serve up real-time updates on your city’s dozens of outdoor pools: when they’re open, when they’re not, how crowded they are — even the quality of the water.
You plan out each phase of development. With a rigid schedule, you’ll be done in mid-June, just in time for the first hot weather weekend of the summer.
But then you hit some snags. Maybe it turns out to be harder than expected for your internal team to gather municipal data on the pools. Or perhaps your development team created a prototype that doesn’t have the user experience you envisioned.
Now all of a sudden you’re not going to meet your June deadline, and the cost of the project is far more expensive than you budgeted.
Could a different project management approach have helped you avoid this situation? The answer is… maybe. Here’s why.
Why choosing a project management approach matters
The project management methodology you choose for your software project will affect how your teams work together, how you manage costs, how fast the work progresses, whether you can iterate, how you incorporate feedback, and how you manage unexpected changes to your product.
When it comes to software, there are two main approaches that guide most projects: Agile and Waterfall.
We’d love to tell you which is superior but spoiler: it’s not that simple.
Both approaches have their pros and cons.
Ultimately you want to work with your development team (if they’re not rigid about process) to pick an approach based on the unique requirements of your project — the features and functions of the app or software you need, the problem you’re solving and your specific business or organizational needs.
What’s the difference between Waterfall and Agile?
Waterfall is a fairly sequential approach to project management.
Each part of the project is divided into phases and those phases tend to be well-defined before any work begins. Each phase acts as a gateway to the next one and it’s usually impossible to skip ahead.
Small tweaks may be feasible, but it’s generally difficult to make any drastic changes to your plan. But no drastic changes mean the budget is also less likely to balloon.
The way we traditionally build houses is a good metaphor for a Waterfall approach. Each phase is linear and scheduled: you pour the foundation, then you frame the home, and then you add insulation. It’s impossible to skip ahead to installing windows if the walls of the home don’t yet exist.
And while you may be able to change the odd detail — paint colours or door handles, for instance — fundamental changes just aren’t possible.
In software, if you have a firm idea of what you want to accomplish (maybe you already have UI and a set of features nailed down), Waterfall could be the right approach.
An Agile approach is more iterative. If the requirements of a project haven’t been nailed down yet, Agile is one way to uncover them.
In Agile, teams start building a specific part of the product during a set period of time, called a sprint (they’re often a couple weeks long). After each sprint, the teams check in with each other to see if they’re building and designing the right thing and to get feedback from the customer. It allows for plenty of collaboration and flexibility, and also requires a lot of communication.
What you uncover in each sprint will determine the trajectory of the project. You can make changes while they’re still low cost and add to the list of requirements without scrapping something your developers have already built.
At the same time, scope can steadily increase, because it wasn’t well defined in the first place. Within Agile, there are different ways of working, including Kanban and Scrum.
If we’re sticking with the home building analogy, with Agile, you may discover that you want to build a detached home, when you initially thought you’d only be paying for a duplex.
Figure out the right approach — and the right development team — for your project
Every client is different, and each project has its own unique requirements. If a development team is only open to employing a singular or very rigid project management approach, that may not be ideal.
Because even when you and your development team do pick an approach, together you want to be flexible and adaptable enough to evolve that base process if required.
At Vog, we’re always asking clients what you need: what are your project’s requirements? How much collaboration are you ready to commit to? How fixed is your budget? What business problem are we helping you solve?
When we understand who you are and what your goals are, we can recommend a project management approach (be it a traditional Waterfall or Agile approach — or a modified take on one) that matches you, instead of cramming you into a mold that doesn’t feel quite right.