Project phases

  • 15 minutes

Typically, implementation methodologies separate an overall project into smaller parts, which allows you to track progress more easily. Generically, regardless of the specific methodology, other common names for these smaller parts of the project are sprints or iterations. Regardless of what they’re called, these small parts of a project represent a milestone in the project’s progress when they’ve completed.

The length of time that’s spent on each phase and on each project will vary greatly. Some projects go from the idea phase to the operate phase in only a few months, while others take at least a year of discovery before work can begin.

Project phases ebb and flow as the project progresses. If your project uses an agile methodology, you might repeat phases along the path from presales to operate.

Commonly, a project will follow a path; presales, initiate, implement, deploy, and operate.

Diagram representing different phases of a project that follows a certain path.

Certain team members specialize in each phase; however, many project team members float to wherever they’re needed on a project. It’s common practice for team members to join a project at any point from idea to deployment.

Presales

The primary activity of presales is to support the sales team on landing the project. With presales, the focus is on the minimal effort that’s required to land the project while ensuring that the sales team doesn’t oversell what you can deliver. Activities during this phase of the engagement are primarily categorized as follows:

  • Request for proposal (RFP) responses
  • Introductory customer meetings
  • Proof of concepts/demos
  • Solution envisioning

Initiate

As the project progresses into designing the solution, the solution architect will take the lead. Depending on the methodology that’s used, some of this work might be completed up front, or more commonly, done with each sprint/iteration in more agile projects.

  • Customer workshops - These requirements capture discussions with the business users who are working to drive toward a thorough understanding of their needs.
  • Requirement validation and clarification - Review the detailed requirements that are collected, including those that are specified as user stories. The goal is to ensure that they’re implementable requirements and are clear and concise. This process is where the team should be looking to identify and add non-functional requirements as needed. This task might require additional follow-up with the customer or team to ensure understanding of requirements before construction of a solution.
  • High-level architecture - The solution architect takes the lead on designing the overall solution topology and communicating this information with the broader project team. Included in this assessment would be any Dynamics 365, Microsoft AppSource, or other external services that would be used, including the broad view of interactions with internal and external systems and services.
  • Detail solution architecture – This process is when more details become defined. It would include designing the security and data models and the overall integration strategy for each external system and service. Additionally, this process involves specification of customizations to Dynamics 365 apps and any other existing apps that will be used. The project teams commonly use a fit-gap analysis to identify the gaps between the requirements and the out-of-the-box capabilities.
  • Review technical designs - As the architecture starts to progress into detail designs by the broader project team, the solution architect would assume the role of reviewer to ensure that the designs fit within the desired architecture.
  • Change management - Change management is a key element to ensuring on-time, on-budget solutions that customers enjoy using. The team must avoid scope creeps while simultaneously allowing changes that are essential to meeting the project success criteria. Exceptional change management is necessary from this point forward in the project.

Implement

In the implement phase, the project team is focused on building the solution according to the agreed-on solution design and scope. Implementation reviews are introduced in this phase. Implementation reviews help the team thoroughly address questions that are related to the specific aspects of the solution design (data model, security, integration) and implementation practices (application lifecycle management and testing strategy). During the implementation phase, you can expect questions that are related to the design of specific components, technology choices, upcoming changes, roadmap, deprecations, application lifecycle management (ALM), and build. Make sure that you proactively work with customers to ensure that the developed solution is in accordance with best practices and is strategically aligned to the product roadmap.

Deploy

By the deploy phase, the solution has been built and tested, and the project team is preparing for the final round of user acceptance testing (UAT) and training. Additionally, all necessary customer approvals have been granted, information security reviews are completed, the cutover plan is defined (including go/no-go criteria), mock go-live events are scheduled, the support model is ready, and the deployment runbook is completed with tasks, owners, durations, and defined dependencies.

Operate

You've now planned, developed, and deployed the application, but you're not finished yet. The goal of the operate phase is to validate the success of the deployment, review lessons learned from the project, and plan for the transition to the next phase or provide transitional support to the maintenance team. After the customer is live, the solution architect should perform a post go-live review. Discuss the transition plan and share the same with the maintenance team.