You're navigating a Systems Design project. How can you engage stakeholders effectively?

I will connect stakeholders successfully, keeping communication channels open and actively including them in important decision-making processes throughout the project management tool and project timelines. Regular updates and feedback sessions guarantee whether or not their wants and concerns are met.

Keep in mind who your stakeholders are. Speak their language. Remember that many are non-technical, and for them technical details will be incomprehensible. Don't forget to speak to their interests.

1. Identify, check qualifying capability and engage the stakeholders. 2. Open all the communication channels with proper detailing. 3. Run a Requisition phase with stakeholders and get the demand generation. 4. Work over the Solution crafted over the demand generated. 5. Collaborate with stakeholders in various round (if needed) for the changes before the final Submission / PoC within a specific time lime. 6. Successful PoC clear the way to implementation. 7. Exception handling / remediating mis- configurations during the implementation to avoid delay in delivery (within project time line). 8. Start the production (Data/Product) and engage the stakeholders to align help-desk to support during the production phase. And get the report.

From project's business value to budget to time-lines, from security to user-experience, compliance and NFRs to deployment, engage different stakeholders as per their world-view of the project and actively work with them throughout the planning and execution phases

1.Conduct stakeholder interviews, surveys, and workshops to gather and prioritize requirements.Create detailed project charters, requirements, technical specs, user stories, and meeting notes.3. Develop and share a clear roadmap with timelines, phases, milestones, and deliverables using visual aids and regular updates. 4.Develop user-centric designs with prototypes, iterate using Agile methods, and establish feedback loops.5.Schedule regular meetings, provide updates, and use project management tools for transparency.6. Identify risks, set realistic goals, and communicate impacts. 7. Showcase milestones, gather feedback, and implement improvements.8. Conduct retrospectives and document lessons learned.

There are a few points that would have to keep in mind. 1. if the requirement is clear then you will have a clear picture of what stakeholders want 2. Understand what they want, the purpose behind it If you fell that you have enough information then After propose a design in front of them

Having successfully designed 26 products, my experience has been that not many stakeholders can clearly explain what they want. It's better to show them a collection of use cases and take the discussion further from there. I usually focus heavily on product functional and user requirements before designing anything.

Los responsables de proyecto deben analizar a sus partes interesadas y prepararse para manejar las expectativas y la influencia de éstas. Sin una gestión proactiva de las partes interesadas, sus intereses y planes pueden contraponerse con las metas del proyecto. La correcta gestión de las partes interesadas garantiza que todos tengan la comunicación y el apoyo necesario a lo largo del proyecto. Las distintas partes interesadas harán distintas suposiciones sobre el proyecto y tendrán sus propias expectativas. Idealmente, el equipo del proyecto debe revisar y fijar expectativas adecuadas con las partes interesadas al inicio del proyecto para evitar conflictos posteriores.

This is one area I see that is commonly overlooked, or rather ignored in the AV industry. Too often some AV engineers are familiar with their systems and brands and walk into a needs assessment with their minds made up about what the customer needs. They listen out of necessity to “check the box” as part of the design process, but not with the intent to understand. Listening with the intent to understand means you're paying attention not to voice your own thoughts or ideas, but to understand someone else's point of view. Too often this leads to over-engineered solutions that are too complicated for the end users - when what the customer asked for was something much simpler and less sophisticated (also much less expensive.)

Understanding the needs really comes down to understanding the goal in plain language. Too many projects achieve the design brief but don’t meet the needs because they miss the mark on usability.

For me this is the critical part. Having a documentation centralized (Confluence, for example) with all the tech aspects, diagrams, metrics (like an ADR) to be used by the team and stakeholders are much better and important than e-mails or message chats that could not be missed by someone. Also, it is important to have a domain dictonary documentaded explaining the domain language for everybody involved in the project.

Cada parte interesada tiene sus propios intereses y las estrategias de comunicación deben tenerlo en cuenta. Después de analizar a las partes interesadas de tu proyecto y de determinar sus motivaciones y niveles de interés, deberías averiguar más sobre sus preferencias de comunicación, cada vez que te resulte práctico, invita a las partes interesadas para que hagan comentarios, organiza reuniones presenciales o virtuales, comparte gráficos, crear un informe breve o, incluso, solo envía a las partes interesadas un correo electrónico periódicamente.

You can avoid technology jargon that creates confusion while talking, and prefer simple and easy terminology that helps to understand what you are explaining.do healthy debt that helps to create better design

Cultivate an environment of clear and regular communication to keep all stakeholders abreast of the project's progression, hurdles, and triumphs. Regular updates foster trust and ensure unified understanding among all parties involved.

Design a technical design document at the beginning of a project can be useful for engaging stakeholders early. It presents a concise view into the proposed architecture and implementation avenue(s). Stakeholders can ask questions, and the architect can refine the document as the design phase moves forward. Translating the TDD into a wiki, and breaking it down into technical stories for a backlog provides a step-by-step process that stakeholders can understand and appreciate, and which developers can easily follow.

Having identified the full range of stakeholders think about their influence, and the best way to engage Treat their input as incomplete needs. Considate the inputs from the range of stakeholders, address conflicts and fill in gaps Validate your understanding by talking to them Do some preliminary concepts and select the most likely. Revalidate requirements and validate conceit by showing to stakeholder. Does your concept align to their needs? Recognise the tbd and tbc issues - don’t wait to complete but not when you need to know and how you will find out

When engaging in the design phase of a project, it’s imperative to facilitate a back and forth dialogue to refine the offering, but it’s also important to know your boundaries. Scope creep begins early and if not managed, often blows up not only the budget but also the ability of the solution to meet the design intent.

Actively solicit stakeholder participation in the decision-making process. Their diverse insights can contribute valuable perspectives, fostering a sense of project ownership and dedication.

In my experience a system, expecially a big system is the "essence" of being crossfunctional, as it involve many different technologies that must work and perform to let the system works and performs at best. An Airplane a vehicle or a Nuclear Power Station are good examples. This is because collaborative involvement and best communication are the fundation in system design.

Establish robust channels for stakeholders to deliver continuous feedback. This not only nurtures engagement but also enables early detection of potential challenges.

A regular cadence of design, backlog refinement, implementation, and demo can serve as the foundation for strong stakeholder feedback. They should be present for any UI/UX design review and approval. Their input is invaluable during backlog refinement, especially for prioritization. Providing regular demos throughout implementation will show them that the project is on track. Including a knowledgeable, engaged stakeholder during daily stand-ups can benefit the team greatly if the individual can help remove impediments. This can include granting required approvals and permissions for internal resources and third party software, or even approving budget for additional team members if necessary.

Within the context of product development, taking a usability perspective, feedback should flow bidirectionally between developers and other involved stakeholders. Usability related feedback mechanisms are often grouped into “Formative studies” (intended to ensure that the usability attributes associated with evolving design attempts progress towards becoming those that are appropriate) and “Summative studies” (that are performed on the final, developed, product to confirm that its usability attributes are appropriate). I highly recommend obtaining the support of experts who can help you choose an optimal usability ?feedback strategy“. Often only minor subtleties can have a significant influence on outcome quality and the required budget.

Personally, my thoughts on today’s Project Management (PM) are not main-stream at all. It seems to me that PM is being driven by the software industry with dozens of players trying to provide the ‘best’ s/w - the tail wagging the dog. The idea, to me, of a single PM managing down to the task level and interacting directly with ‘team’ members is a distortion that goes against the most fundamental management practices. Likewise, the ‘team’ concept popularized by the US government’s Polaris project/program is misapplied, misunderstood and misused. The overall PM should only manage down to and interact with with a work-package manager, who is responsible with delivering the WP. How, who and such details are up to him or her, just as in OO s/w

Budget and delivery dates are often prime concerns, especially for a consultancy. Explaining how many devs it would take to deliver a design by an agreed-upon given date, and what those devs would cost is key to managing a successful project. Avoid agreeing to a budget or timeline before scope is locked down to avoid burning out a project delivery team with excessive hours, or disappointing a client with incomplete work at the delivery date.

Managing stake holders expectations is very crucial and getting sign off at all stage is important part of the rhythm , especially in a Human Centered design …. And the matter becomes complex and messy when : 1 . Too many stakeholders and too many competing issues 2. Not priority or ranking of stake holders expectation at the design stage 3. Not getting buy-in and sign off when there is iteration in design outcomes

Provide stakeholders prototypes or mockups to give them high level understanding of the system. This would enable us to get the feedback early and implement the same.

Presenting the final user with a “fait accompli”, that never incorporated their operational imperatives, means that the projects will be rejected by the very it was designed to support. That is regardless of whether the project met its “artificially devised contractual milestones”. The user matters! Artificial constructs, . . . not so much.

Also, develop real-time analytics dashboards to share live project metrics and performance data with stakeholders. This transparency can build trust and help stakeholders make informed decisions based on current project status.

Implementa los planes y evalúa el éxito: Al igual que el plan de tu proyecto, deberás evaluar el éxito de tu gestión con las partes interesadas. Las partes interesadas deben estar lo suficientemente comprometidas con el proyecto, recibir comunicaciones y participar si se modifica o actualiza el plan. ??éxito en tu gestión de Partes Interesadas!!