Project Management

Project Management Central

Please login or join to subscribe to this thread
Sharing Technical Project Status to non-techie stakeholders - examples
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?
Sort By:
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.
Lawrence -

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.

Kiron
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.

RK
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.
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!
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.
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.

Please login or join to reply

Content ID:
ADVERTISEMENTS

Information is not knowledge,
Knowledge is not wisdom,
Wisdom is not truth,
Truth is not beauty,
Beauty is not love,
Love is not music
and Music is THE BEST

- Frank Zappa

ADVERTISEMENT

Sponsors