In February 2020 PMI published PMI Pulse of the Profession that says: “Work has changed. So must the way the world thinks about projects.”
We continuously need to improve our ways of working and develop our skills, but 2020 gave us a harsh lesson that we also need to be in some way agile. According to PMI, to be successful in the future, our organisations need to be agile, but also focus on the right technology and secure relevant skills. You can read further:
So let's focus on how the organisation can ensure agility in the management process for software delivery.
Understanding Project Management in Software Development - part 3
This article is part 3 in a series about project management methodologies, roles in a project team, and efficient models do deliver software projects. How does the Project Manager see the phases of the software life cycle? Which is best and why? These questions will find answers throughout the post.
Many years ago, people were working on unique projects, such as great monuments and buildings that we can still see today. Companies were inventing new products such as first cars, aeroplanes or phones. There were projects managed during times without Gantt charts, Agile Frameworks, Prince2®, Critical Path Method and many other tools, techniques and frameworks that we know from today’s project management. Let’s look back to see how the approach to project management has been changing over the years and how it impacts the phases of the project. It’s not a complete history of project management, but just a couple of examples.
At the beginning of the 20th century, Henry Gantt created a tool, which we know and use until today - Gantt chart. It is a chart with: timeline on the x-axis and activities on the y-axis. We see all actions as bars with marked dependencies. The great value of this chart is that project managers can apply it to different industries, which may be a reason why it became so important to the project management world. Gantt charts help engineers to understand what is the plan for their tasks and how are those dependent on other tasks. It presents how phases of the project are planned within time and when a project team will complete a part of the work throughout the project.
In 1975 Simpact Systems Limited developed a standard named PROMPTII, which has been adopted by the UK Government to all IT projects in 1979.
The lifecycle of PROMPTII included the following phases:
In 1989 PROMT II was renamed to PRINCE and the acronym was changed to Projects In Controlled Environments. Then in 1996, Simpact Systems upgraded the methodology name to what we know as Prince2®. A lot of companies nowadays use Prince2® as a project management process in the software industry.
Project Manager is leading the work of the software project team, that usually includes roles such as developers, testers, business analysts, product designer.
In 2001 seventeen people met in Utah (USA) "to talk, ski, relax, and try to find common ground". The result of this meeting, we know today as The Agile Manifesto.
Source: Agile Manifesto
Agile is like an umbrella - methods and approaches that follow The Agile Manifesto may be called agile. Thus, to get there may take decades for stakeholders.
Those are just three examples, but we may see how the approach to software delivery evaluates over the years. Some project managers still apply methodologies such as Prince2®; however, nowadays, the trend on software delivery moves to agile approaches.
I believe that this will continue to evaluate, as we are living in a changing environment and Project Managers will keep looking for project management methods that will address risk management, increase the performance of delivery, and quality of the deliverables.
We may divide approaches to project management into two: waterfall and agile. Waterfall model is also called a cascade approach in which phases take place one after another. For example, the project starts with estimation, then moves to development followed by testing, user acceptance tests and release to production. On the other hand, there are agile frameworks, such as Scrum, Kanban, FDD, which presents a more lean and iterative approach with project phases repeated in cycles.
Kanban is a lean approach to software development. The team follows the process they have and uses the Kanban Board to visualise it. On the Board, each team can define their steps in a process.
When using Kanban for projects, it’s worth setting a limit of tasks which are open at the same time - this will reduce the WIP - Work In Progress. In Kanban, we may work in iterations, which is optional; however, the overall approach does not have strict timeframes, such as Scrum Sprints. A team may also estimate tasks, which are part of the Kanban Board - this is optional and depends on team preferences.
Kanban gives a lot of flexibility in the way the team will set up the board and work. The planning phase is minimal when compared to other frameworks, which may be an advantage for some teams. Controlling the progress is also limited, as it is not possible to compare roadmaps or timeline. However, even with that flexibility, Kanban may be an excellent approach for big teams.
Scrum, when compared to Kanban, adds more structure as there are predefined processes that the project should follow. The below graph presents how Scrum should look like in projects.
Iterations in Scrum are called sprints and may have different duration, usually form 1 to 4 weeks. Each sprint starts with a sprint planning meeting, during which the team agrees on sprint scope. During the sprint, there is a daily meeting for the team to speak about the progress the team made, set a plan for the day and walk-through some issues.
To ensure that the software project team identifies problems at the early stages, and there is a continuous improvement process in place, team members meet for a retrospective meeting after each sprint. There is also a sprint review meeting to present to the Client progress made during the sprint. While to control project progress, there are metrics such as the Burndown chart or velocity chart.
When choosing Scrum for your organisation, it’s best to follow the framework in its original version. If you randomly skip some ceremonies or artefacts, it may impact the timeline, cost or budget in the long term. For example, if a project team misses a retrospective, there will be no direct impact on the project; however, the process may be ineffective, which won’t be improved during the project. That may result in overall poor performance and impact on the project.
Nowadays, we may see an increase in popularity of approaches that combine techniques from Kanban and Scrum, such as Scrumban. This shows how we are creatively looking for solutions that will fit our organisation.
FDD is an agile approach to project management, which focuses on features. The main goal of FDD, similarly to other agile methods, is to deliver working parts of a product in regular cycles. Below graph presents the overall FDD process model.
The main difference when comparing, for example, to Scrum is that FDD focuses on utilising effort of a team and resources to deliver features which are immediately valuable for a client.
Waterfall methods are based on a cascade approach, which put phases in sequence. The planning is very detailed and happens at the beginning of a project; hence late findings, changes to the scope may significantly increase the cost of a project. Moreover, it extends the time to market, because release to production (or actual delivery) happens at the end of the process.
Skipping any of the execution phases in the management process may impact key performance indicators such as project costs and timeline.
The example of waterfall methodology is Prince2®.
The described approaches have some similarities, but each is different at the same time. The most important thing for Project Managers is to know what are the differences between them and what will best fit their projects.
|Planning||Execution||Monitoring & Controlling||Testing|
Kanban does not specify what planning is.
Nevertheless, teams may choose to provide estimations to activities on the Kanban Board, while the first column will be “To Do” list.
|Tasks are done according to flow on the Kanban board. There may be iterations introduced.||
WIP - Work in Progress - is one of the metrics that help to control the amount of work taken at the same time. Cycle time - it’s duration counted from beginning till the end of work on the task.
Estimations - team members can provide estimates for tasks and control their execution.
|Testing might be a step in a process and separate column at Kanban Board.|
|Scrum||Planning takes place before each sprint. The team commits to sprint scope based on available velocity.||Project is executed in iterations, called sprints, with a usual duration of 1-4 weeks.||There are metrics in Scrum, such as Burndown chart, Velocity chart, or checklists like DoD or DoR.||Testing takes place in every sprint. The goal of a sprint is to complete and demonstrate a working and tested product.|
|FDD||Planning focuses on features and defining tasks for features. Also, the team discusses and agrees on which order to implement features.||Projects are executed according to feature concept. FDD focuses on continuous delivery, hence working and complete features are delivered usually every two weeks.||
Parking Lot Diagram is used to report on project progress based on significant functionalities.
There is also a Feature Complete graph, but Project Managers may also use Cumulative Flow Diagrams to control progress.
|In the last process in a model, there are unit tests and code inspection.|
|Waterfall||Planning takes place at the beginning of a project, and it’s rather detailed for the whole project. It may include the creation of roadmaps, milestones, budget plan etc.||Execution takes place after the planning phase. There are no iterations in the execution - the whole product is built in this phase||Monitoring happens at the same time as the execution of a project. Project Manager is responsible for checking on project progress vs detailed plan, roadmap, milestones.||Testing phase takes place after development is completed, which may result in late found bugs that impact the performance of the system.|
Choosing the right delivery framework is an essential part of project management. Project Manager needs to ensure that all stakeholders, including team members and Client, understand the project execution plan.
Software delivery is rapidly changing, so to make the best use of all available techniques, methodologies, frameworks and tools, it’s good to consider hybrid approaches. Those become more popular in software development and use practices and artefacts from different frameworks. By choosing a hybrid approach, Project Managers adjust the delivery framework to the project environment and Client requirements, which helps to decrease the time-to-market, be flexible on the scope and increase delivered business value.
Before the development, the very first interaction with a Client takes place. It plays a vital role in delivery. The delivery team meets the client, debriefs the problem that the client is facing and understands the environment in which the client operates. On the other hand, the client meets the delivery team and learns about ways of working and company values.
After that phase, there are usually workshops or consulting steps during which the client receives tangible assets such as technical artefacts, backlog, wireframes or UX materials after workshops. There are a lot of techniques to run workshops; hence always the plan for workshops is customised for a specific client. We share it early enough, so the client has time to prepare the homework. You may find more about the workshop phase here.
Depending on the project, that phase may have different duration as well as there may be a couple of workshops required. Nevertheless, after that part, if the client would like to proceed and develop the product, we move to the software development phase.
Looking at projects from phases perspective, we will see that most projects follow the same processes, such as: initiating, planning, executing, monitoring & controlling and closing.
PMBOK® Guide named those five groups as process groups or project life cycles. Those processes interact with each other. For example, monitoring and controlling is present in a project throughout the whole project lifecycle. It’s almost similar to project execution and planning, but those have their peaks depending on the timeline.
Source: PMBOK® Guide
Below graph shows another way of presenting the process groups and their interactions.
Source: PM Knowledge Hub
Even for agile projects, we can still see the same phases occurring. There are initiation and closure of an agile project. We have to control it as well as execute it. Running an agile project does not mean lack of planning - actually there is a critical planning aspect in agile development, but it happens in iterations.
The conclusion is that phases such as planning, executing, controlling, and closing will happen in all projects despite the fact of which methodology or framework we use. Even if we look back in time to the beginning of the 20th century when Henry Gantt created the Gantt chart - it was a tool for planning.
I do not think it is going to change, as it’s hard to imagine a complete lack of planning or executing in projects. What may change is the way we will put those phases in interactions, or how in detail those phases are.
Good Project Manager is responsible for the choice of the project management framework. To do so, I advise to debrief the organisational strategy of a client, analyse environment factors and look into business value coming out of it. The way Project Manager will manage your software project will have a direct impact on project performance, and finally, your business success.