The debate of classic vs agile project management can be long and draining, especially when the purists are involved. Unfortunately, there is no right way and humbly, as long as it gets the job done, either or works.
We will focus on two main components:
- First the difference between classic and agile project management during the management workflow
- The second which should you choose based on a selection of key variables that I usually use
The difference between classic and agile project management
We will focus on your normal down-to-earth project management lifecycle. If you are expecting a detailed technical overview, let’s leave those for the HBR cases.
I consider 4 core components:
- Planning
- Implementation and control
- Deliverables
- Maintenance
Planning
Planning in agile project management is done on a fragmented sprint-based approach.
- You keep yourself flexible on the priorities that you have depending on how the product develops.
- You have a general overview and a strategic roadmap, but the implementation roadmap is defined on a sprint by sprint basis.
- It is perfect when you do not have a clear view of how you will get to your goal.
In classic project management you have detailed planning done beforehand:
- You have defined who will work and have a clear implementation roadmap already done and approved
- Changing priorities means that you will change the project which will require clear approvals
- It is perfect when you do have a clear view of how you will get to your goal.
Implementation and control
Implementation in agile project management is usually done based on backlog prioritization with the focus on being reactive to issues and problems.
- The team is controlled through the daily standups where based on the brief discussion, key risk points are defined and decisions are made.
- It is a self-organized team with the goal of a better product as opposed to a clear product goal. Changes are made along the way.
- Constant communication is necessary to adjust product and process-related issues.
Implementation in the classical project management workflow is based on the planning rulesets defined.
- You follow clear-cut guidelines on changes and risks based on a specific project management methodology that you are using
- You have a team hierarchy and communication is done through that hierarchy
- The project manager is the one that has the “full overview” of what is going on and acts as the key direction/task definer.
Deliverables
Deliverables in agile project management are small increments of the product to match the defined sprint requirements. At the end of each iteration, you will have a better product, that is usable and deployable.
Deliverables in classic project management are defined in the planning stage. Whatever you have agreed with your stakeholders, this is what they should get. Usually, it means a big product at the end of the project timeline.
Maintenance
I am sorry, but classic maintenance does not work. There is no way that you should maintain a classic approach, as you have to be reactive to your bugs and your cant really plan them.
Agile it is.
Which project management style should you choose?
The answer to this question can be complex, yet I can at least nudge you in the right direction.
I have two questions that I always try to answer in my mind:
Do I know what you want to do, specifically?
Do you have a clear roadmap in your mind on how your product will be or do you generally know where you want to be, but you don’t know how you will get there?
If the first then classic. The latter then agile
Are the people in your team experienced in agile or not?
If the people in your team (including you and your stakeholders) are experienced in agile, then this helps you with the decision makings. But if your stakeholders want to have Gantt charts and deadlines of delivery, then your approach is clear.
If the first, agile. Else classic.
Hope this makes it a bit more clear.
