Please login or join to subscribe to this thread
The key thing is do not use technical language. You have to do it with focus on benefits instead or explaining in technical language what you are doing. For example, think about the benefits to use a movil phone instead of explaining technical what it is or how it works.
I'd suggest meeting with a small group of these non-technical stakeholders to learn what they feel is important to be kept apprised of and their desired format. Then, produce a simple prototype dashboard for them and iterate on it based on their feedback.
If they don't understand why a particular piece of information you would like to share is important, then make sure you provide the context and impact of it as part of the shared information.
One thing I noticed that works well in your situation is an on-boarding meeting or session to explain to them the details of the report and receive feedback which will help you tweak your report to suit their needs and understanding.
In terms of technical projects, desired outcomes of a project are generally less technical and more value focused than project deliverables. One of the challenges, however, is if you're not releasing deliverables and producing value before the project ends, it is difficult to speak to performance with regards to achieving outcomes and realizing value. Regardless, outcomes and value are an important part of the story.
When it comes to telling the project story, your non-technical stakeholders will benefit from understanding the problem(s) you are trying to solve, who will benefit from the solution(s), any challenges you've faced and how you've overcome them, successes, estimated launch date, when the delivered product or service will begin to deliver value...
To Kiron's point, your stakeholders won't all want the same information presented the same way. My last COO was interested in dates, dollars, and data to support the story. The previous COO was more interested in seeing progress. Understanding your audience (think stakeholder analysis) can make things a lot less painful, or at least prepare you to know where to expect the pain to come from.
You could consider something like a simplified digital twin.
If your product is a car for example, selecting a graphic of the car will bring you to a vehicle level status of the performance, technical challenges etc. You can then select major systems in the car from the graphic such as powerplant, suspension, interior, etc. and get by-system views of the work in progress.
This is actually the direction that some modern CAD systems have taken. Rather than a traditional 2D drawing of the product with notes dimensions, and other supporting information, all that is accessed through the solid model itself.
What kind of information is embedded depends on what the customer needs. In a CAD model, that would be information necessary to manufacture the part. To tell the story of the development, it could be the team, the evolution of the technology, etc. In this interactive way, you can organize and package the information in a way where it is aligned with the product architecture, and it is more digestible for the user who needs a high level view.
Please do your best to use their language and terminology. Focus on those tangible deliverables they are looking for and explain the effect of the technical issue on them.
Please login or join to reply