In this next post in my series on solution architecture for the Power Platform we’ll look specifically at the next stage following first discovery processes we’ve run through as a solution architect to identify the problem we’re solving for an organisation.
We’ll look at some of the things you might consider including at a high level, and some of the things which may create differences in proposal documents.
Did you collect your data properly?
So people, whilst you may have just done a bunch of discovery, did you actually collect that data properly? Did you make notes in those workshops? Draw all over collaborative workspaces and whiteboards? Where are the answers!
What’s next?
Now is the time to look back at all the material and notes you collected and pull those findings together into an initial high level architecture and design that we can propose to the customer.
Now we don’t have to have a fully architected solution here, but we should have a proposal ready that will be a viable solution for the customer and uses implementation components which won’t present any single points of failure for the solution or it’s availability.
Writing the proposal
Now we can begin to write a proposal or project plan summary where we start to define some of the parts or parameters that the project should hold and things about it, such as…
- Project reasoning (business problems, objectives, reason for solution)
- What is success?
- Scope for the project (what is included and what isn’t)
- Governance plans
- Timelines
- Deliverables
Now it’s important to call out anything that at this stage might be missing to achieve the success point defined, any risks that can be identified and any dependencies which will need to be present during relevant stages of the project.
Feedback and iteration
Now, don’t expect that when you send that proposal with a figure on it that the customer will be happy with it straight away, and rightly they probably shouldn’t be! In the majority of cases a proposal document will require several iterations of changes before each element is properly ironed out with any missing parts filled in between the consultancy / solution architect and the customer. Be prepared for this to happen and make elements of this a collaborative process with your customer friends! 🤝
Acceptance and next stages
Now, if you end up at a point where your customer is happy to proceed with the project implementation and signs off your proposal the next steps are super important!
As soon as possible following this happening, it’s so crucial that you outline the next steps to your customer and communicate upcoming interactions, and engagement activities which they should be prepared for having signed off your proposal.
What’s coming up?
So friends in my next post we’ll look more closely at that last point we made. We’re not at the point of project implementation yet, and there’s still a few more stages to go, so in the next post we’ll look at defining a communication strategy for all stakeholders involved in the implementation from developers through to C level stakeholders in the customer organisation. Stay tuned friends! 💖