Discuss stakeholder management responsibilities

Completed

While every project is different, as a functional consultant it is common to interact with stakeholders. This is usually done alongside other team members like project manager and solution architect. This communication with stakeholders will be in meetings, emails, workshops and documentation. Team leadership should let each team member know what types of stakeholder communication is expected for the project role.

Perform workshops

Workshops can start before the actual project work starts. Gathering requirements, confirming requirements, and gathering more requirements can all be done with a client workshop.

Work with the maker team to ensure an understanding of requirements, and execution of the requirements. Identify and gather information from your champions, seek their input on what areas of the system to highlight to end users to gain their enthusiasm. Encourage management to offer users incentives for system adoption, such as a competition, tracked business goals, and so on. Find measurable ways to track user commitment and adoption to both showcase the system, and identify potential areas for improvement in a later phase.

Workshops are also where we prepare our stakeholders to take over the system we’ve built for them. Sometimes this knowledge transfer is from builder to maintainer; or it could be onboarding new users. Not every project will have a dedicated resource for planning these workshops. As the bridge between tech and business, the functional consultant is very well prepared to take on this roll.

The functional consultant will often assist in training delivery to end users. This is again based on their unique position to understand both the technology and the business to help bridge that divide with users.

Create and deliver a solution review

A solution review is a chance to show stakeholders progress toward a goal. Depending on the exact delivery methodology, you will likely have incremental reviews of progress. A solution review could also potentially include showing a proof of concept to the team to gain their input and support.

The solution architect will likely be the one taking the lead on this, but the finer details of a solution review often fall to the functional consultant. When planning a solution review look for ways to not only gain approval, but to seek genuine feedback. This is the time to plan for minor course corrections if a feature didn’t come out as planned, or maybe doesn’t work as smoothly as it did in design. Don’t feel bad when course corrections are identified in this review cycle, it’s why reviews happen. It’s what we do with the feedback that matters most.

Create demos and proofs of concept (POCs)

As you start to envision the solution it might be time to share a good demo to validate requirements with your stakeholders, but also to build confidence in the platform. When a customer is confident in the platform, they are more willing to accept your proposed solutions with enthusiasm. If you are using an iterative approach to the solution, you may find yourself building several small proofs of concepts along the way. Microsoft Power Platform makes building a proof of concept easy.

Demos can take different shapes and forms depending on the solution being proposed. The following are some of the most common approaches:

• Out of the box - An out of the box demo simply shows off one or more of the apps without any customizations. This demo is often performed by pre-sales resources and doesn’t involve the solution architect. This demo is also a good way to get customers up to speed with the core product features. The negative of this approach is it doesn’t help the customer envision their solution on the app. You can mitigate some of the negativity from this approach by including relevant sample data to their business.
• Pre-built demo – Many partners specialize in particular verticals or solution areas and invest in building up pre-built demos containing their own intellectual property that tailors the out of box base solution with their designed value-add. This approach helps the customer see their particular problem area because often it uses the vertical language in the app. Often it also hides things that aren’t appropriate for the solution area that might distract the customer.
• Prototype – This takes the out of the box state and with the customer needs in minds does the minimal tailoring of the app to reflect the customer’s needs. The main benefit of this is to allow telling a story during the demo that the customer can relate to solving their particular objectives.
• Proof of concept – Proofs of concept should be built to prove a concept works and typically involves a very specific component or activity in the proposed solution. Unlike a prototype that usually has a straightforward path to completion, proofs of concept may try multiple approaches to reach the desired goal.

It’s quite common to interchangeably use prototype and proof of concept and from a customer perspective the difference typically doesn’t matter. The goal here should be focused on telling a story and bringing your proposed solution to life, helping the customer see their problem solved by the proposed solution. You should also look to reduce risk by flushing out unknowns.

Keep or throw away

When you build a prototype or proof of concept, you should realize that the quick wins here may not translate to a best practice for production-ready solutions. This doesn’t mean that best practices are hard to follow, but for a quick showcase of an idea, it is likely more than you’d need to build out a quick idea than plan for a larger solution. This should be something decided up front, because if you do want to carry the assets forward you will need to ensure they stand up to your standards and not take short cuts that can’t easily be remedied.

Manage expectations

Due to the fact it is so easy to quickly put together a demo to show off your proposed solution managing expectations is important. It’s not uncommon for a demo to be given and the customer saying great – when can we go live! The best way to manage this is being up front that what you are showing while it might look complete, it doesn’t have all the security, automation and other trimmings necessary for going live. The important point is to have the discussion and not assume the customer will know a demo is just that a demo.