Lawrence TaxsonSenior Program Executive| USGVienna, Va, United States
How do you tell your technical project "story" to non technical stakeholders? We are looking to leverage different types of communication methods (website, blogs, newsletters, etc) to inform our stakeholders of weekly / monthly highlights on our technical efforts. I don't want to post a dashboard or Gantt chart, but rather a different information view that is engaging and more modern. Any suggestions or examples you can share? Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
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. Saving Changes...
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.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Lawrence
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. Saving Changes...
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. Saving Changes...
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. Saving Changes...
Use visuals and images, analogies. As technical people we rely a lot on jargons. I think it is a very good communication exercise to try to be away of technical vocabulary and at the same time transmitting the right information. Keep us posted how you were successful! Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
The answer is in your question: tell stories. People related well to stories. Stories should be told in the present tense and have names--real or not--for characters and locations. Saving Changes...
Felicia WarnerPM Specialist| City of ChicagoChicago, Il, United States
Not using technical language and providing the non-technical with the benefit(s) of the project worked for me.
My problem is getting non-technical people to see the value of a PM and that PM work is more than 8 hours especially when you have 10+ projects. Saving Changes...
Community Champion
