Understanding project management methodologies

While working on a project, project managers use different techniques and tools to keep their project organized and to get them delivered on time. One of the most critical decisions a project manager takes is selecting an appropriate project management methodology. We learned about common project management phases in the last topic. While implementing those phases, project managers need to follow specific practices to plan, manage, and execute the project, and this is what we call the project management methodology.

We can also call it a model that can be applied to project management to achieve a project goal within the set project timeline and budget. Project management methodology helps managers to manage their projects from the initial stage to delivery of the project. It helps the manager to set up a protocol for different activities. For example, how the project team will communicate, how tasks will be assigned to team members, setting up quality control, managing the project timeline, and delivering project output.

No doubt using project management methodology provides many advantages to an organization by standardizing its business processes, setting up communication rules, setting up guidelines, and reducing the risk of project failure. Companies can follow different methodologies for project implementation, but which project management methodology will be used for a project depends on the project manager. Project managers use project methodologies based on their past experiences and industry requirements because not all methodologies can be used in every project. For example, while working on the construction project, a particular project methodology may be more helpful than one that is common for software projects.

The various project management methodologies that we will be looking at are listed here:

• Waterfall
• Spiral
• Agile
• Scrum
• RAD
• Microsoft Sure Step
• Kanban
• Feature Driven Development
• DevOps

We will be studying each of these methodologies in the following subsections.

The Waterfall methodology

This is one of the most popular and simplest methodologies used for project management. In this approach, a project is divided into sequential tasks that are then carried out one by one until all tasks are completed. This is similar to a waterfall, where water flows from top to bottom, hence the name. In this methodology, you can't move back to the previous phase. Instead, the only possible option is to go back to the initial phase and start again. The output generated from one stage becomes the input of the next stage.

In the Waterfall methodology, comprehensive documentation is done in every phase, which is very helpful when carrying out maintenance or when a new member joins during a project. They can easily refer to the documentation to learn about project details. The Waterfall model divides a complete project into six different stages. We can understand how these stages are implemented one by one by using the following diagram:

Let's discuss these stages in detail:

1. Requirement Analysis: This is the first phase of the Waterfall model. In this phase, we find out what is required. This phase needs a lot of interaction with the client to understand their requirements in detail. Various techniques are used to identify requirements, and we will be discussing these techniques in later chapters. All of the requirements are recorded properly in the necessary documents. Once project requirements are known, the feasibility of the solutions is discussed. All of the requirements are analyzed properly and different possibilities are considered for developing a potential system. In this phase, any existing infrastructure that clients have, such as existing servers, are also analyzed for potential use in the new system.

2. Designing: In this phase, the blueprint of the final output is prepared based on the project requirements generated in the first steps and then an appropriate technology is selected. All of the functional and technical design documents are prepared in this phase along with the system architecture. Once all of the design documents are ready, the project moves to the next phase.
3. Coding: In this phase, code is developed by team members based on design documents. Team members work on the individual modules, which are integrated with other modules once completed. Team members also perform unit testing of their code to avoid any design time or runtime errors.
4. Testing: Once all of the modules are developed, they are tested against the requirement document generated in the first phase by the quality team members. The quality team first prepares test cases using requirements, and then manual or automated testing is performed later on. Manual testing is done by a QA team member manually without using any testing tools or script, whereas automated testing is done using tools and scripts. Automated testing is useful for retesting test cases after code changes or any upgrades.
5. Deployment: In this phase, the final output is verified by clients and this involves user acceptance testing involving end users. An end user performs function testing to make sure that the project output is based on their expectations. End user training sessions are also conducted in this phase.
6. Maintenance: In this phase, post-deployed changes are implemented. This includes fixing any client-side issues, adding more functionality to a project, or upgrading software patches, if required.

Waterfall is a common method of the software and construction industries. This methodology emphasizes further collection of all of the requirements in the initial phase and documenting them properly to use them in later phases. This model is easy to understand as projects progress through easily understandable phases, one by one. However, this model can't be used for projects where it is difficult to find out all requirements at the initial stage. This is because it is very difficult to add new requirements once a project is initiated.

The Spiral methodology

This is another very old model for project management that can be considered as a combination of the Waterfall and iteration models. In the Spiral model, a list of requirements is identified for each iteration, which is known as a spiral. The output of every spiral is a small prototype of the project. The client can review this prototype and provide feedback. Similarly, requirements are identified for the next spiral. This process is followed until the project is complete and ready for delivery. As we can see in the following Spiral model diagram, a small prototype is developed in each spiral:

There are four phases in the Spiral model. Let's discuss these next:

• Determine Project Objective: In this phase, requirements are gathered from the client and a feasibility study is carried out against those requirements. Any existing infrastructure is also analyzed for use in a potential system. All of the planning is done in this phase which includes preparing a project schedule and resource allocations for each spiral.
• Find and Resolve Risks: In this phase, as the name suggests, all requirements are visited to identify any potential project risks. Proper documentation is done for all of the risks and these risks are resolved using the best possible options.
• Development and Testing: All of the development and testing is done in this phase. A small prototype of the system is developed and tested before delivering it to the client.
• Review and Plan for Next Iteration: In this phase, customers review the prototype and provide their feedback. After the review, the next spiral requirements are planned.

This model is suited for large projects where clients can review project progress after every iteration and provide feedback about a prototype. It also allows for requirement changes after the project is initiated. Project risks are identified at early stages and fixed to avoid project failure. However, this model can't be applied to small projects and risk analysis requires more experienced resources.

The Agile methodology

This is a very common project management methodology used nowadays, especially for managing software development projects. This model is best suited when complete requirements are not clear when initiating a project but project stakeholders have an overall idea of what they are looking for. The Agile methodology basically implements the idea of developing software in many iterations; every iteration uses the complete Software Development Life Cycle (SDLC) process and stakeholders are also continuously involved in every iteration to provide their feedback.

In this model, the project moves to the next level in iterations and project tasks are performed based on their priorities. The project tasks' priority list is known as the product backlog in Agile. Team members work collectively on the product backlog and provide estimations for the tasks based on their priorities.

SDLC is a process used by software development companies to develop software. It is divided into many phases, beginning with requirement gathering and ending at the maintenance phase.

We can define an Agile methodology using the following diagram, which explains the high-level Agile methodology process:

Agile methodology helps teams to deliver a much better product quickly using small iterations compared to other methodologies. The Agile methodology uses the following main principle:

1. Continuous team interaction
2. Working module with documentation
3. Continuous collaboration with stakeholders
4. Responding to changes quickly

Agile methodology maintains continuous team communication that involves every team member from developer to customer. An Agile team is not managed by just a project manager; instead, the team management is the responsibility of every team member. Daily calls, known as Scrum calls, are held to discuss project progress and any roadblock. After every sprint—which normally ranges from one week to four weeks—a working model is released with complete documentation.

End users perform user acceptance testing after every sprint and continuous interaction with stakeholders also ensures that the project is going in the right direction. The working model that is released after a sprint is always based on customer expectations. Agile project management addresses the response to change quickly. Using this principle, project teams respond quickly to customers, end users, stakeholders, and market trends, ensuring that the final product is helpful to the end users and that it is something that they really want to use.

Today, Agile is used as a framework for other methodologies such as Scrum and Kanban, where the whole project is managed by continuous iteration and collaboration. There is no doubt in saying that Agile can help teams to increase flexibility and collaboration, which ultimately results in a more successful project where the end goal is not clearly defined during project initiation.

The Scrum methodology

Scrum is basically used to implement the Agile methodology, so we can also call it as a subset of Agile. Using Scrum, we deliver incremented products to customers after every sprint of one to two weeks. Once the sprint is over, every team member meets to plan for the next sprint. Some high-level activities involved in Scrum are sprint planning, daily stand-up calls, sprint reviews, and build releases after every sprint. Scrum is normally used when requirements are changing very rapidly. The following diagram represents the complete common steps performed in the Scrum methodology:

Let's now discuss common phases included in the Scrum methodology.

Product backlog

The first phase is to collect customer high-level requirements and prepare product backlog. Customer requirements are ordered based on their priority in a product backlog. These requirements are prioritized by the product owner. The product backlog includes all of the features that the customer expects in the final product. These requirements are termed user stories.

A user story provides details about the requirement from an end user perspective, focusing on what they want to do or what feature they want to have in a product. These user stories do not include the complete set of requirements—instead, they only include features that customers have in their mind at the time of starting a project. The customer expected feature list can be changed during implementation, but the product backlog still acts as a requirement document for the Scrum process for implementation. This document is used as a base document for sprint planning.

Sprint planning

After the product backlog is prepared, the next step is planning a sprint. Sprint planning is done after every sprint is over. In sprint planning, the Scrum team selects a list of requirements that will be included in the current sprint. Some of the following questions are answered in sprint planning:

• What is the goal of this sprint?
• Which product backlog items will be included in this sprint?
• What will be the time estimation for the user stories to include in this sprint?
• Who is available for this sprint?
• How we are going to deliver incremental builds after the sprint?

The output of sprint planning is sprint backlog and time estimation. Selected requirements from product backlogs are included in the sprint backlog based on their priority, effort estimation, and team capability. Scrum methodology gives flexibility to the team regarding the user stories implemented within the current sprint as sprint backlog items can move from one sprint to another. If any sprint backlog items are not completed during the current sprint, they are moved to the next sprint.

Daily standup

During the sprint, team members meet over daily Scrum meetings, which should not go over 15 minutes. These Scrum meetings are managed by Scrum team members. The Scrum Master acts as a team coach who motivates every team member to give their best performance. In daily meetings, team members update the team on the status of their tasks, the next task that they are going to work on, and they discuss roadblocks if there are any. Daily calls help teams to get updates about the status of user stories. Any potential issues can be identified in advance and the team works collectively to resolve them.

During daily standup calls, a burndown chart is updated based on the team's status. A burndown chart can be considered an output of daily Scrum calls, which helps every team member to understand how many tasks are remaining.

Sprint review

The sprint review is done at the end of every sprint. In the sprint review process, a demo of the completed user stories is presented to the Scrum team, stakeholders, and end users. Stakeholders and end users provide their feedback after the demo and the Scrum team acts on the feedback accordingly.

Backlog refinement

Once the sprint is over, the next step is to refine the product backlog. During this process, new user stories are added to the product backlog and unnecessary user stories are removed from it. User stories' priorities can be changed by the product owner if required.

There is no doubt that the Scrum methodology helps us to implement projects quickly. Larger projects can be divided into multiple sprints. It is very flexible in terms of how easily it accommodates new changes. For example, if stakeholders request a new feature, a product owner can easily add them to the product backlog. But sometimes, this becomes a risk for the project when stakeholders keep requesting new functionalities.

RAD

Rapid Application Development (RAD) is another methodology that is used to implement Agile. RAD is very popular nowadays where the main reason to use this methodology is to build a working prototype of the system quickly and efficiently. This methodology is also very flexible in terms of accepting changes during the development process. Here, less time is spent on planning and the main concentration is on developing a prototype using iterative steps, which helps project managers and stakeholders to accurately measure project progress.

They can provide their feedback after using a prototype and teams incorporate them quickly. The following diagram explains how RAD methodology is used for projects:

Let's discuss the common phases used in RAD.

Requirement planning

In this phase, requirement gathering and planning is done for the project. In RAD methodology, the planning phase is shorter compared to other project methodologies. Requirements are gathered to understand what customers are looking for in the final product. Current business processes are also analyzed in this phase. Once requirements are gathered, the project moves to the next phase after taking approval from the customer against requirements.

Developing a prototype

In this phase, the design and development of the prototype start. A team works on the requirements gathered in an earlier phase to prepare the UI and data model. Then, they customize the UI based on customer feedback. It is very important to take the approval of the customer for UI before jumping to the development of the code. Once the design and data model is completed, the team starts writing code for requirements.

After unit testing, a prototype is demonstrated to all team members including stakeholders. Stakeholders provide their feedback, and they then communicate to the team which functionality works well and which failed. Then, the team works on the refinement in the prototype based on the feedback provided. This phase is implemented in many iterations depending on the requirements. After incorporating all of the feedback and requested changes, the project moves to the next phase.

Testing

In this phase, the QA team performs system and integration testing to make sure this new prototype will work well with the existing system. Most of the issues are already fixed in an earlier phase based on customer feedback. In RAD, each prototype is tested independently, which reduces the overall testing time. In this phase, the development strategy is also tested to make sure that deployment goes smoothly.

Release

This is the final phase of RAD, where the final product is released for end users. This phase includes end user testing, data migration, and the changeover to the new system. Customers can log any issues faced after release.

RAD helps to achieve more in less time. Quick iteration can accommodate new changes requested, so the final product is always based on customer expectations. As integration testing is already performed, it is less common to face any integration issue during project release. However, this methodology can only be used for product development where a module can be developed independently and it requires shorter development cycles.

Microsoft Sure Step

The Microsoft Sure Step methodology is developed by Microsoft to implement Dynamics products for customers. The Microsoft Sure Step methodology has built-in processes and the disciplines necessary to implement Dynamics solutions. It also includes built-in document templates required for various tasks during Dynamics implementation with a set of guidelines and best practices for successfully implementing Dynamics. Microsoft Sure Step classifies projects into categories that we will discuss in the following subsections.

Microsoft Sure Step – projects

This provides information about different users involved in Sure Step projects, including the customer as well as the consulting side. We can understand the Sure Step methodology project using the following diagram, as well as see details regarding the different phases and the project:

In the preceding diagram, we can see that we have different project categories in the Microsoft Sure Step methodology, so let's discuss these projects one by one to understand more about them:

• Standard: Microsoft Dynamics implementation for a single customer site comes under this category. This project requires moderate-to-complex customization on Dynamics applications.
• Enterprise: Microsoft Dynamics complex implementation for a single site or multiple sites comes under this project category. As these are complex implementations, it requires a decent amount of effort to develop Dynamics solutions. This project is larger in terms of scope compared to other project types.
• Agile: Projects under this category use iterative approaches for implementing Microsoft Dynamics applications. In these types of projects, not all requirements are known when the project begins, so new requirements can be added during the implementation process. The whole Agile project is divided into multiple iterations.
• Rapid: Microsoft Dynamics implementation projects with limited scope come under this category. Most of the requirements under this project can be achieved using the out-of-the-box capability of Dynamics applications.
• Upgrade: If the customer is already using Microsoft Dynamics applications and they want to update it to the latest version, they are regarded as upgrade projects. Microsoft Sure Step provides project supporting documents based on different industries. These documents are based on the selection of the specific project.

Now that we know a bit more about projects, let's look at the phases.

Microsoft Sure Step – phases

The Microsoft Sure Step methodology also implemented a series of phases. Every phase has its own importance. Let's have a closer look at these phases one by one:

• Diagnostic: The main objective of this phase is to find out what is required. Customer requirements are gathered and appropriate Microsoft Dynamics applications are demonstrated to the customer based on their key requirements. Sometimes, a small Proof Of Concept (POC) is also built to show the capability of Microsoft Dynamics products. All of the requirements are collected in a requirement specification document. Once requirements are captured, the project moves to the next phase.
• Analysis: In this phase, the requirement documents produced in an earlier phase are analyzed properly and a feasibility study is done for customer requirements. Fit gap analysis is done to compare customer requirements with Microsoft Dynamics functionality and gaps are identified where customization and development are required. This phase also sets up a change control plan, which identifies how new requirements will be added to the project scope if required.
• Design: This phase is used to prepare the design and configure Microsoft Dynamics applications based on the requirements. The team works on both the function and technical design of the application. The screen layout of the application is prepared and approval is taken from the customer. The technical design document is prepared in this phase, which has details of any customization and development required.
• Development: In this phase, code development is done and the system is built based on the technical design document. If the system requires integration with a third-party system, that is also built in this phase. Once development is done, all of the system modules are tested by QA team members. If the current system requires any data migration scripts or procedure, this is also developed in this phase.
• Deployment: In this phase, a Microsoft Dynamics solution installed on the customer location QA servers and UAT is performed against all of the requirements to make sure the final product is based on customer expectations. Key users are trained in this phase to use the new system. A go-live checklist is prepared, which includes critical configuration for production deployment. Finally, after the UAT is completed, production cutover is performed based on the previously decided cutover timings to release the project for end users who will be using the systems in their day-to-day work.
• Operation: This phase is the last phase of the project, where the final review of the system is done and the post-deployment support strategy is decided.

The Microsoft Sure Step methodology takes less time to implement Microsoft Dynamics for the customer as it includes a set of tools, required templates, and best practices.

Kanban

This is another popular project management methodology that follows Agile methods for managing projects. It uses a visual method of managing projects as it moves through the process. In this methodology, work items are represented with the help of a Kanban board, as shown in the following diagram, which allows team members to see the state of every piece of work at any time:

Work items denoted by numbers in the preceding diagram are displayed using Kanban cards. In the preceding Kanban board, we can see the current status of all work items. To Do is a list of pending items that are not started yet, whereas In Progress items are those that are under development. The Finished queue shows all of the items that are completed. Kanban uses the following basic principles:

• A visual board for project activities
• Work on limited project activities at a time
• Flow management for activities
• Implementing feedback
• Implementing collaboration between teams

Work items in this methodology can be re-prioritized based on the stakeholders' requirements. Kanban work items are never bound to a specific iteration, so this provides flexibility to developers. Team members collaborate with each other to improve the flow of work in the Kanban board throughout the project. This methodology is best suited for projects with small teams.

Feature Driven Development

Feature Driven Development is another project management methodology that comes under the Agile family, which means it also follows an iterative and incremental development process. In this methodology, client requirements are presented as features that become the basis of product development. We can consider features such as user stories in the Scrum.

The following diagram explains the phases of the Feature Driven Development methodology:

Let's discuss these phases in more detail:

• Develop an Overall Model: In this phase, an overall model of the solution is prepared, which explains the high-level functionality of the solution. It does not provide all project details at this stage. This phase helps the team to understand the overall goal of the project.
• Build a Features' List: Once the overall model is ready and team members have an understanding of the project goal, all customer requirements are divided into features. In this phase, a features list is prepared, which is used as a basis for the whole project. Big features are divided into small manageable features that should not take more than 2 weeks to develop.
• Plan based on Feature: After having a complete features' list ready, planning for features, implementation starts. Planning is done for every feature, which involves different activities such as setting their priority, identifying risks, resource allocation, and identifying dependencies if there are any.
• Design by Feature: In this phase, the team starts working on the design of the features assigned to them. Design documents are created for features. Once the design is ready for the features, a property inspection is done to avoid any confusion during the development of these features.
• Build by Feature: Once the design phase is complete, teams start developing code based on the design documents. After this, code is tested for the feature. Once testing is completed, it is verified by the chief architect. After the approval of the chief architect, this feature is added to the mail build.

Following the preceding five simple phases, the Feature Driven Development methodology can be used for rapid product development. Not much time is spent initially discussing requirement details. Instead, the overall model is prepared to understand the high-level objectives of the project. However, this methodology can't be used with a small team as it requires an expert chief architect to lead the team and monitor all development and testing processes.

DevOps

DevOps fills the gap between the development and operation teams. The word DevOps is a combination of the words, development and operations. This helps to automate the process to develop and deploy projects faster and more efficiently. DevOps basically uses Agile to create a value-driven environment for quick deployment of software products and features.

The following diagram provides us with the basic idea regarding the DevOps methodology:

Let's discuss the common phases of DevOps:

• Development: In this phase, software development takes place continuously. The development process is divided into small development cycles.
• Testing: In this phase, automated testing is done for the code developed in an earlier phase. This involves writing an automated testing script. These automated testing scripts are used by automation testing tools for testing functionality developed by the team.
• Integration: In this phase, new functionality is integrated with the existing functionality and integration testing is executed. Continuous development supports continuous integration as well.
• Deployment: In this phase, continuous deployment takes place. Deployment is done in such a way that it should not impact any of the existing functionality.

The main advantage of using DevOps is to make the whole development and release process faster. As a result, a product can be released to a user in a much faster way as all of the tasks are automated and do not require any manual efforts. This is very useful when we need a project release very frequently. The use of automated tools ensures high-quality products with efficiency. Products can, therefore, be released to the market in a much faster way. Release automation also minimizes any risk of deployment failure, which significantly reduces the number of bugs.

Apart from the preceding methodologies, sometimes, companies create their own hybrid project management methodologies, which include template, tools, and processes from various project management methodologies. Now, we have discussed the most popular project management methodologies and learned that every methodology has its own merits and demerits. While planning for project implementation, the first task is to pick a project management approach that is right for your project to make implementation smoother and more efficient. Now, in the next section, we are going to discuss which of the preceding methodologies can be used for implementing Dynamics 365 CE.