The software development cycle can be extremely sensitive, with many factors contributing to leaving it rather vulnerable to disruption and delay. There’s client feedback to review, bugs to fix, updates to schedule, data to migrate, and any number of other things capable of sabotaging milestones and sinking entire projects. Project Management Agile vs Waterfall.

For this reason, getting the management of the project just right is absolutely vital. Making the most of available resources usually accounts for the difference between failure and success. But what kind of project management is suitable for a particular project?

Well, there are two approaches you’ll run into time and time again across the business world: traditional project management, and agile project management. Each one has strengths and weaknesses, and which one you should use depends wholly on the context. Let’s dig deeper into how you can choose the right approach for your project.

‘What Is Traditional Project Management?’

A traditional project management setup sees a project overseen by a dedicated manager who nigh-unilaterally governs its configuration, assigns the workload, and generally serves to protect the project as it was formally set out, both inside the company and when dealing with the client. They will generally have a background of working in management.

It also requires that a comprehensive project plan be approved before any work is done, including a detailed high-level breakdown of the agreed objectives, deliverables, timescales, milestones, costs, penalties, risks, and anything else that seems relevant. At the point of delivery, this plan is reviewed to confirm that the objectives have been achieved.

The intention of getting everything set out upfront is to avoid the perils of miscommunication during the project and protect both the developer and the client from the the dangers of starting a project on questionable pretenses and never finishing it as a result.

‘What Is Agile Project Management?’

An agile project management setup, on the other hand, sees a project overseen by a product owner who gives the team their backlog (identifying the tasks, prioritizing them, and explaining them in detail), assesses the adequacy of the delivered solutions, delivers approved solutions to the client, and retrieves feedback. In many cases, this role is filled by a developer.

In this kind of setup, a full plan isn’t required before beginning, as the work is broken up into worthwhile chunks (typically carried out over set periods of time) and costed accordingly to allow for a greater degree of flexibility. The developer starts with one item, gets it done, and then tackles further items if both they and the client wish to continue.

The idea is to keep the project in a state of consistent and meaningful improvement, staying totally focused on spooling out pieces of usable work in whichever order suits the client’s requirements and the capabilities and resources of the development team.

‘What Are the Advantages of the Traditional Approach?’

As I see it, there are two main advantages of the traditional approach. Firstly, and most boringly, it’s a long-standing institution. Many long-time business owners are very reluctant to deviate from business structures that have worked for them before.

As such, introducing another approach invites questions and skepticism that can cause problems if not handled adeptly, particularly when you’re pitching a format that requires more input from them. They may want to just outline their requirements and leave you to figure everything else out, not understanding or considering that it will affect the quality of the work.

Secondly, it offers a degree of financial security to an agency with full-time employees to pay and resources to cover. It’s a tricky thing to address, but a struggling agency won’t necessarily have the confidence that they could make as with an agile approach, and may feel that nudging a client towards a large commitment is worth it regardless of the long-term consequences.

‘What Are the Advantages of the Agile Approach?’

As its name suggests, the agile approach was developed to make projects more adaptable, so it’s no surprise that it does just that in practice. It equips the developer to consistently get things done by emphasising the importance of incremental progress.

The relative rigidity of the traditional approach makes it quite brittle— a sufficiently-large bump in the road can cause it to break entirely, and it’s not uncommon for project requirements to have changed significantly by the time of final delivery, leaving a solution that isn’t fit for purpose and causes both parties to feel aggrieved.

Using an agile model, that doesn’t happen. Any given period of work doesn’t last long enough for there to be a meaningful shift in requirements, and any changes to the client’s overall direction can be accommodated by the feedback reviews between deliverables.

And as a result of the increased frequency of input from the client, the development team is going to have a better understand of what they’re trying to accomplish, and the quality of work is likely to be much higher.

‘Is Agile The New Standard?’

Given the rise of startup culture and the increasing number of commercial juggernauts who rely on agile methodologies, a case can certainly be made that agile development is the new standard in project management. I really like the way Harley Finkelstein (currently the COO of Shopify) described the agile approach in an interview with Mixergy (I’ve heavily paraphrased for brevity, but the thrust is unchanged):

“In software development, the tenet of done is better than perfect allows you to write certain code to create a certain application and then let users test and provide you with feedback. The resulting iterations are extremely valuable. Often, I actually don’t even realize what the sweet spot of a deal is until very late on in the negotiation process. And because of that, I think the ability to move and change, and pivot your interests and objectives, is extremely important.” (See full article here).

While we’re not in a position to know how much of Finkelstein’s firm’s immense growth into the dominant ecommerce hosting solution can be attributed to operational flexibility, it’s easy to see how an enterprise looking to scale so rapidly would benefit from a lot of freedom in its approach.

In many ways, the agile manifesto sets a precedent for the forward-thinking revision of established business practices that has made strides in recent years— look at the move towards product thinking in the UX field or the automation wave in the wider tech world that continues to produce versatile suites like Salesforce or Moosend (as well as solutions that link those suites, like Automate.io).

‘Is Agile Management Right For Me?’

In general, if you want to commission a software development project and you can commit to working closely with your chosen developer on a regular basis, you will benefit from allowing and supporting an agile management style.

The increase in communication, visibility of deliverables, and fast identification of anything that doesn’t fit requirements will produce consistent results— and you’ll be dealing with developers who really understand your project, instead of questionably-useful managers.

There will always be cases in which the production of a full high-level plan is justified before beginning, sure; but the more open companies are to being a less restrictive in how they approach development deals, the more they’ll find that a little flexibility goes a long way.

Victoria Greene is an e-commerce marketing expert and freelance writer who often extols the virtue of flexibility. You can read more of her work on her blog Victoria Ecommerce.