Common Project Management Approaches to Software Engineering
Content Map
More chaptersHow should we manage a software engineering project? What’s the best way to run a software team? Project management approaches provide answers to these questions.
What Is Software Engineering Project Management?
A project management approach, or a methodology, outlines a roadmap to tackle a software engineering project. No consensus exists on which project management approach might best fit a software project. It depends on how a software team works and the nature of the engineering project. Here are the most common types of project management across Big Tech and non-tech companies:
- Waterfall
- Scrum
- Kanban
These approaches can be divided into two big categories: Waterfall and Agile. Read here for a comparison of the two.
Waterfall Project Management
The Waterfall project management approach has a linear and rigid structure. The software project is completed in sequential stages, with the team fully completing each stage before moving on to the next, until all the stages are executed. There is no turning back or skipping.
There are five distinct stages:
1. Planning
2. Designing
3. Implementation
4. Testing
5. Delivery
Planning
Gather all the necessary parts for the project. This includes project requirements, stakeholders’ expectations, available resources, essential personnel, and risk assessment. Roles are assigned to people, with a set of responsibilities and specific deliverables. These roles include the critical team members in a software development project and other stakeholders, such as the client, legal, marketing, and operations. Make sure they receive clear communication about the project right from the start. The clearer the communication is at this stage, the more chance the project will be on time and on budget.
Since the first stage sets the scene for the entire project, it’s okay to spend a lot of time and effort on it, because this approach doesn’t allow the flexibility for significant changes down the line.
Designing
Go into the specifics of the project’s milestones and expected deliverables. Flesh out the timeline, budgets, and allocate the resources for each step. Also factor in unexpected risks and any possible preparation. You should document each step so that there is a single point of reference to minimize confusion.
Since this is the stage before execution, it’s recommended to have a kickoff project meeting with all the stakeholders involved. Answer their specific questions about the what and the how of the project, and make sure they are all clear about the documentation.
Implementation
Carry out each phase of the project, step by step. This stage should take up the majority of your project. Depending on the project, the steps and the deliverables vary, whether it be developing a web app or a mobile app.
Remember to keep good records of your activities to keep the stakeholders in the loop. Thorough documentation not only improves your transparency and accountability with the stakeholders, but also allows your staff to learn from precedent with subsequent projects.
Testing
In this stage, we test the viability of the software product. There are many types of tests to run, and for a large project, a testing team and a QA team will work together to ensure the software meets expectations and compliance standards. A well-executed Waterfall approach often produces a rigorous project, so this stage should not take too long. On the other hand, the delay in testing could be risky when your testers discover a bug that requires the project to start from scratch.
Delivery
The software product is delivered to the client, launched, and starts getting users. Like testing, effective project management would reduce the pressure at this stage. On the other hand, a rushed delivery with minimal testing that neglects major issues would fail. Whether success or failure, you should hold an action review meeting at the end to learn from the whole experience and improve next time.
Overall, the Waterfall approach requires extensive documentation: all the stages are clearly defined, everyone is clear on what to do. It allows little room for backtracking or re-iterating. It also requires efficiency since the full completion of each stage is non-negotiable to move forward. Waterfall software projects are led by highly experienced project managers who can manage people and projects, with the foresight to prepare for possible issues.
When should we adopt the Waterfall approach for software engineering projects?
Due to its clarity and rigidity, the Waterfall approach is ideal for small projects with clearly defined scopes and well-documented precedents. It should not be the first time your team has done this type of software project. The people in crucial roles should know precisely what to expect at each stage, and be well-prepared for it.
Scrum Project Management
Scrum is often confused with Agile, but they’re different. Agile is a project management philosophy that follows a set of values and principles favoring flexibility and continuous iteration of the software development lifecycle.
Scrum is an approach within Agile. The key distinction that sets Scrum apart from Waterfall is flexibility. Scrum breaks away from the rigid, step-by-step instruction of Waterfall, allowing team members and stakeholders to make the changes as needed.
According to Scrum.org, Scrum does not have a project manager role. The work is divided into three primary roles: the Product Owner, the Scrum Master, and the Development Team.
The Product Owner leads the project and represents the end user. They define the product and communicate with the stakeholders.
The Scrum Master facilitates a team’s workflow and streamlines their processes. They may do so by facilitating daily Scrum meetings, leading sprint planning meetings, and conducting retrospective reviews at the end of each sprint.
The Development Team in the Scrum approach is self-organizing. They do not like top-down hierarchy like in the Waterfall approach. They work together to devise the steps to develop the product and make the major technological decisions.
Instead of the lengthy steps in the Waterfall approach, a Scrum team works in sprints. Sprints are small, manageable chunks of the projects, with tasks assigned to each team member. Each sprint takes 1-2 weeks. The team holds daily scrum meetings to update everyone on daily progress, and a restropective meeting at the end of a sprint to debrief and get feedback on the last sprint. The whole team is responsible for tracking progress. Each sprint has its own deliverables that the team focuses on delivering. With each sprint, they gradually work towards reaching each significant milestones in the project timeline.
The Scrum approach enables teams to mitigate a weakness of the Waterfall: unforeseeable risks and changing requirements. The team does not ship an entire completed product; they deliver works in progress, which are increments of the product by the end of each sprint. The stakeholders can provide feedback and report issues on these incremental deliverables, which the team adds to their backlog for subsequent sprints.
When Should We Adopt The Scrum Approach for Software Engineering Projects?
Scrum is probably the most common approach adopted by outsourcing vendors, thanks to its adaptability to client feedback and changing requirements, facilitating effective cooperation between the client and the vendor.
However, please note that changing requirements when it’s too late is also a major source of headaches for software development teams. A team lead’s leadership skill is judged by their ability to negotiate changing requirements for their team. This applies across the board for every project management approach.
Kanban Project Management
Kanban software project management is another approach in Agile. Like Scrum, it’s also a simple method that champions flexibility with a visual board - the Kanban board.
The Kanban board is divided into three columns: To do, Doing (or In Progress), and Done. A team member starts by adding tasks to the column To Do. When they begin working on the task, they move it to the column Doing. When the task is finished, move it to the column Done.
Like Scrum, the Kanban approach also breaks down the project into smaller chunks and implements continuous incremental changes. Unlike Scrum, Kanban promotes focusing on one single task at a time. A principle of Kanban is to limit Works in Progress (WIPs). This means putting a maximum cap on the tasks in the middle column (Doing), and the remaining unfinished tasks stay in the To-Do column. When a project is in full swing, the center column likely has the least tasks.
If a requirement is changed, then the change is considered a new task and will be added to the column To Do. The team only moves it into Doing as capacity becomes available (when the WIPs fall below the maximum cap). This limits the stressful impact of a requirement change and allows the team to prioritize task completion.
When Should We Use The Kanban Approach for Software Engineering Projects?
The Kanban approach is best for a software team that wants to focus more on the tasks and less on managing the project (meaning fewer meetings). For client projects that require transparency, accountability, and stakeholders’ input, Kanban is often used in conjunction with Scrum.
Kanban is the best fit for software teams when:
- They want to start a new approach without upsetting current processes.
- They have a continuous workflow and want to maintain daily consistency.
- They only need to track implementation, not requirements.
- Team members have full flexibility in how they do their work.
- The team has no clear roles.
- The team doesn’t engage with stakeholders except for a monthly meeting.
Kanban won’t be as beneficial for projects with a range of features, clearly defined roles, and a need for accountability and reporting to stakeholders. Projects that require constant adaptation to external requirements, such as developing MVPs and releases in cycles, likely won’t find winning benefits from the Kanban approach.
Other Software Project Management Approaches
Thanks to its flexibility, there are many other approaches under the Agile umbrella, and they can be combined. These include, among others, Scaled Agile Framework (SAFe), DevOps, and MLOps.
Scaled Agile Framework (SAFe) is best for projects that need to scale up from a single team. It is a good fit for large enterprises and scaling startups managing large-scale projects.
DevOps is a step-up from Agile that encourages collaboration between software development and IT operations. Bridging the gap between software and hardware, the best benefit of DevOps is to shorten the software development lifecycle.
MLOps enables DevOps teams to deploy machine learning (ML) models in developing AI-enabled software. MLOps also improves ML models faster.
Wrapping Up
Choosing a project management approach is like choosing a path to get to the end goal, which is successful project delivery. It’s the journey, not the destination. Therefore, there is no fixed rule saying which one is better than the other; the choice of approach depends on the particular needs of your project and your company. A good software engineering team should be able to advise you on what may work best for your objectives.
Technical/Content Writer
Technical/Content Writer
