I am currently preparing to take the Microsoft Dynamics 365 + Power Platform Solution Architect certification. Or “MB 600” for short! As I prepare I plan to write revision notes in this post I will cover topics connected with the concept of a project life cycle.

I don’t think the skills measured statement for the MB 600 explicitly mentions the concept of a project life cycle. But it does reference parts of the cycle! Such as go-live and initial requirements gathering. The MB 600 exam does not focus on a particular project methodology but all approaches to managing a project will have some commonalities. I therefore feel it is import to understand these.

Project Life Cycle

We may need to appreciate the project life cycle and how the Solution Architects role fits into that.

There are obviously many project management methodologies. Agile and Waterfall being just two examples. Each organization can (and will) follow slightly different project management processes. But all methodologies typically include a common project cycle, that being Initiate & design, Implement (aka build), prepare and operate. This cycle maybe applied as a one off process, as we’d expect in Waterfall project. But it can also be applied to the iterative sprints we’d find with Agile.

I found this link to a Wikipedia article that discusses various software development methodologies, including Waterfall and Agile along with other concepts such as rapid application development and extreme programming. If you aren’t familiar with these the Wikipedia article may make interesting reading. As you review it maybe consider how each might influence the project life cycle and the associated role of our Power Platform Solution Architect.

But it is important to understand that when we reference the project life cycle no particular methodology is being implied. The cycle (in this context) is used to highlight the role of the Solution Architect at each stage in the cycle. The exact timing and sequencing on these stages could vary based on the selected project methodology.

The project typically formally starts at the initiate stage. But we shouldn’t forget that a stage prior to this may exist in which the Architect will also participate. Assuming a customer / supplier arrangement to delivery then this stage will be pre-sales. When the potential project is discussed.

Initiate – create an understanding of project scope and accountabilities. Covers the start of the project or iteration. Will often happen after signing an agreement following pre-sales but can also happen at the start of an iteration if following a more agile approach. At this stage, the Solution Architect’s focus is on helping the project manager staff the project team and find the right mix of resources to complete the work. The Solution Architect may also be responsible for putting in place the development methodology, applications life-cycle management (ALM) approach, and other key project items.

Analysis / Design – Define overall project context and solution. The Solution Architect will lead the design process although they might not be responsible for capturing every requirements. The Architect will therefore take an active part in customer workshops, requirement validation. High-level architecture definition, detailed solution design, technical design reviews and change management.

Implement – Sometimes called the build phase! During which the Solution Architect must provide guidance on all technical and functional aspects of the solution. Often in this phase the Solution Architect will play the role of a problem solver.

Prepare / Delivery – Create and implement a “go-live” plan. The solution architect is involved in helping the team build the deployment team and validate the plan. The Solution Architect might also participate in advising the business on a go/no-go decision. They will therefore also be responsible for assessing any risks associated with the deployment.

Operate – ensure smooth running of the solution after deploy. Sometimes a warranty period will exist to provide additional support during the early usage of the solution.

Note: I will dig deeper into these concepts during my posts that cover requirements gathering, designing the solution and go-live planning etc.

Project Methodology

The MB 600 exam should be considered agnostic of any particular project methodology. There is no such thing as the “best” methodology! All have strengths and weakness and some may work better in some circumstances than others. All methodologies should help define certain key project attributes, including project scope, accountability, QA plans and much more. An important takeaway (regardless of the methodology) is that the Solution Architect should support the Project Manager.

When thinking about project governance some potential pitfalls to avoid could include;

• Not documenting assumptions – all decisions and assumptions should be clearly documented. This helps ensure we understand not just what has been agreed but why.
• Not doing “real” risk management – having a risk log does not mean you are doing risk management! The Solution Architect and Project Manager should ensure risks are reviewed, their impacts understood and any mitigating actions progressed.
• Over promising – all of the proposed solution components / requirements must be feasible. (Within the customer’s stated budget, time scales and quality expectations.)
• Designing with incorrect requirements or assumptions – a design based on poor requirements will result in a poor solution!
• Not having buy in – it is essential that the senior management are on the same page as the project team! The Solution Architect needs their support to champion the changes, manage risks and generally promote the system within the organisation.

Some recipes for success regardless of the project methodology could include;

• Regular project check points – regular checkpoints to ensure progress is being made as expected are essential. I would expect the Project Manager to be responsible for organising these but the Solution Architect would be involved.
• Change control – if you don’t have a clear process to identify and agree changes then create one. A change board may be needed to review and approve all changes. The Solution Architect should be playing a key role in change management to help estimate the impact and priority of changes.
• Lessons learned / retrospectives – timely reviews of work completed and implementation of lessons learnt should be a given. These must be no fault open discussions that should result in agreed future improvements. Don’t wait until the end of the project, learn and improve as the project progresses! In an Agile project you may complete a retrospective for each sprint.
• Be more agile (lower case a!) – I am not trying to suggest this implies the Agile methodology. But having an iterative approach which embraces change can be a useful mindset within any methodology.
• What does complete look like – understanding what success should look like is important. In fact sometimes just knowing that a task is “done” can take thought. From a developers point of view a task might be done when the code is written. But from a customer’s point of view done implies the code is written, tested, accepted and deployed. Having a common understanding of “done” can therefore be important.
• Seek feedback – actively seek feedback from the customer, the project team and the wider organisation on how things are progressing.

All project methodologies should support the project team and customer in understanding the progress on the project. How are we doing? It should be mandatory to measure progress during the project. There are many ways of doing this but a simple Red, Amber, Green (RAG) status against key milestones or deliverables is one common easy to understand approach. Another alternative is to show progress on a burn down chart, you can read about those on Wikipedia here. Or in Waterfall projects we might measure progress against tasks on a Gantt chart.

Pre-Sales

Before a project begins Solution Architects working for suppliers maybe involved in pre-sales activities. Their main responsibility in a pre-sales role is in supporting the sales team and ultimately helping win the deal to begin the project. Tasks connected with pre-sales might include;

• RFP Responses – A Request For Proposal (RFP) may include many technical questions that the sales team cannot complete on their own. The Architect may be expected to comment on feasibility and also levels of effort.
• Statement of Work (SOW) – often an SOW will be created with input from the Solution Architect to define the extent of the changes to be delivered. This may in turn become part of the contract between the supplier and customer.
• Customer Meetings – It maybe common for the sales person to be accompanied by a Solution Architect in meetings with the customer. The Architect’s role in these meetings will be to answer on any questions as they arise. These meetings can also be really useful for the Architect to gain a deep understanding of the customer’s current environment, desired outcomes etc. All of which will become useful if (when) the deal progresses into a project.
• Proof of concepts / demos – The Solution Architect maybe responsible for giving demos of Dynamics 365 and the Power Platform. On occasion these will be demos of out of the box functionality. But it will also be common to demo a proof of concept solution. The Architect might not be responsible for actually creating the POC system but they would have significant input into its design.
• Solution Envisioning – Based on the customer meetings the Architect will be responsible for forming ideas on how to resolve the customer’s problems. During the pre-sales phase this envisioning maybe at a high level but will need to be detailed enough for the customer to appreciate the vision. It maybe that the Architect creates documentation at this stage which later will become the basis for the SDD. (Solution Design Document)
• Education – Often it will fall to a Solution Architect to brief the sales team on the latest capabilities found in the Power Platform and Dynamics 365. In doing this they help equip the sales staff with the knowledge needed to better qualify leads.

I have mentioned soft skills required by Architect’s elsewhere in these revision notes! But it almost goes without saying that the ability to clearly communicate at all levels with the customer will be an essential skill for any Architect involved with pre-sales.

Additionally Solution Architects might be called upon to help estimate the costs of a solution. A key part of this would include any licensing costs / implications. And in some circumstances the Architect may actually need to revise the envisioned solution to take account of any limitations on the available licenses.

The best Solution Architects are also very adept at spotting potential opportunities within existing projects or during customer meetings. It may therefore be common that they suggest potential leads to the sales team.

Pre-sales (and later) demos can take different forms;

• Out of the box – this type of demo shows off the apps without customizations. Sometimes giving an out of the box demo is an effective way to explain core features to customers, The negative side of this type of demo is that they are not in the context of the customer’s final solution and may not fully help them envision the final solution.
• Prebuilt demo – many Microsoft Partners focus on particular industries, they may create “stock” demos which show typical business processes that would exist in those industries.
• Prototype –an out of the box solution is subjected to minimal customizations. Then a tailored demo can be given in context of the customer’s needs.
• Proof of concept – Proofs of concept should be built to prove that a concept works and typically involves a specific component or activity in the proposed solution. Frequently, this method is done during the design phase but can also be used during presales when the customer needs to see a key concept working in the context of their proposed solution.