Mon, Jan 20, 2020
Read in 5 minutes
This post will give insights on requirements documentation and scope, which are specific to PowerApps Portals. Use this compilation of best practices in your requirements gathering process before the project starts and during project delivery.
So let’s look at some best practices on how to identify requirements and also some considerations on how to document them.
Portals Standard vs. Requirements
You’re up to a good start if you know the Portal functionality very well. And this is template specific, if a template is used. If you leverage the customer self-service template, deep-dive into the template specific Web templates of the solution. If you know all the templates and their unique features, it will be a lot easier to not only choose the right template for your customer needs, but also shape your solution architecturally with out-of-the-box features. Consider to categorize the gathered requirements into at least three categories:
This can make life easier when it comes to comprehend estimated efforts and also maintains a first class documentation of your solution. Put yourself in the shoes of the support staff after the project phase. Wouldn’t it be nice to know straight away that a buggy feature is relying on standard functionality? That will make troubleshooting so much easier as reproduction in other (vanilla) environments can be carried out right away.
Proof of Concepts / Prototyping
Looking at my past engagements, I tend to do at least little PoCs for all the requirements that fall into the category ‘Custom Functionality’ and often also ‘Standard functionality with customization’ if they are critical to the success of the solution. Those PoCs often help to drive an efficient presales phase for high level requirements. If you can generally show the technical feasibility of the solution, your customer is more likely to choose you as the trusted adviser. The Portals frameworks suggests ease of configuration for lots of kinds of requirements. And don’t get me wrong: these possibilities DO enable exactly this and outcomes will be able to be realized the majority of cases with quick time to market. Once you leave the boundaries of the framework, the project can be become quite complex easily. I came to the conclusion, that business requirements often share similarities among different engagements. Hence, you can recycle your PoC knowledge here to enable even quicker turnaround times -may it be in other PoCs or simply in answering questions to shape an effective solution for your customer.
All of the PoCs can eventually conclude to a (working) prototype. Sometimes it is useful to aim for a prototype to be the first deliverable in the first phase of a project. Once this phase is successfully achieved, the key pillars of the prototype can be refined in iterations consecutively, which will ultimately conclude in the final solution. Furthermore, your learnings out of this prototype phase may resolve in the discovery of requirements being infeasible or impractical – partially or in general. Again, a great mechanism to do the so important estimation of efforts/time for later project phases.
In your fit-gap analysis, pay close attention to required automation functionalities, which typically will be realized via Power Automate (Flow) or custom plugins. Take some time to understand the desired degree of process automation and challenge this well. Form my personal experience, customers tend to automate as much as possible once they come to realize the powerful capabilities of the platform. It shall not be about quantity, but about quality. Sometimes a good user training can be much more effective yet cost-reducing in comparison to an automated solution, which needs to be developed/tested/supported. Hence, keep a close eye on the ROI the requested automation artifact.
Found this post useful or have comments?
Reach out to me anytime.
Let’s have a closer look at best practices for gathering requirements of localization specifics in the next blog post - stay tuned.