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 somewhat agile. According to PMI, to be successful in the future, our organizations need to be agile, but also focus on the right technology and secure relevant skills. You can read further:
“For the first time for Pulse, executive leaders identified which factors they see as the most important to achieve success in the future. The top three were: organisational agility (35 per cent), choosing the right technologies to invest in (32 per cent) and securing relevant skills (31 per cent).”
So let's focus on how the organization 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 worked on unique projects, such as great monuments and buildings that we can still see today. Companies were inventing new products such as the first cars, airplanes, 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 changed 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 that we know and use to this day - the Gantt chart. It is a chart with a 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 the plan for their tasks and how these are 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.
The project Manager leads the work of the software project team, which usually includes roles such as developers, testers, business analysts, and product designers.
In 2001 seventeen people met in Utah (USA) "to talk, ski, relax, and try to find common ground". The result of this meeting, we known 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 evaluated 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 be evaluated, as we are living in a changing environment and Project Managers will keep looking for project management methods that will address risk management, and increase the performance of delivery, and quality of the deliverables.
We may divide approaches to project management into two: waterfall and agile. The 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 present 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 visualize it. On the board, each team can define their steps in a process.
When using Kanban for projects, it's worth setting a limit on the number of tasks that can be open at the same time - this will reduce the WIP (Work In Progress). In Kanban, teams may work in iterations, which is optional; however, the overall approach does not have strict timeframes, such as Scrum Sprints. A team may also choose to estimate tasks that are part of the Kanban Board - this is optional and depends on team preferences. Kanban offers a lot of flexibility in the way the team sets up the board and works. The planning phase is minimal 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 timelines. However, even with that flexibility, Kanban can 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 in projects.
Iterations in Scrum are called sprints and may have different durations, usually from 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 discuss the progress the team made, set a plan for the day, and address any issues. To ensure that the software project team identifies problems at the early stages and has 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 progress made to the client. To control project progress, there are metrics such as the Burndown chart or velocity chart. When choosing Scrum for your organization, it's best to follow the framework in its original version. If you randomly skip some ceremonies or artifacts, 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 the 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 organization.
The main difference when comparing, for example, to Scrum is that FDD focuses on utilizing the effort of a team and resources to deliver features that are immediately valuable for a client.
Waterfall methods are based on a cascade approach, which puts phases in sequence. The planning is very detailed and happens at the beginning of a project; hence late findings and 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 timelines.
An 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.
Monitoring & Controlling|
Kanban does not specify what planning is.
Nevertheless, teams may choose to provide estimations of activities on the Kanban Board, while the first column will be the “To Do” list.
Tasks are done according to the 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 - its duration counted from the 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.|
Planning takes place before each sprint. The team commits to sprint scope based on available velocity.|
The project is executed in iterations, called sprints, with a usual duration of 1-4 weeks.|
There are metrics in Scrum, such as the Burndown chart, and 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.|
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 the 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 inspections.|
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 plans, 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. The project Manager is responsible for checking on project progress vs detailed plan, roadmap, and milestones.|
The 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. The Project Manager needs to ensure that all stakeholders, including team members and the 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 artifacts 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 a 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 regardless 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 execution in projects. What may change is the way we put those phases in interactions, or how in detail those phases are. A good Project Manager is responsible for the choice of the project management framework. To do so, I advise debriefing the organizational strategy of a client, analyzing environmental factors, and looking into the business value coming out of it. The way a Project Manager will manage your software project will have a direct impact on project performance, and ultimately, your business success.