Quelles sont les meilleures pratiques pour mener une réunion de lancement d’une mission de conseil en logiciels ?

Knowing the business of the client, understanding the in and out, back and forth of the business, speaking the business in the dynamic world is what it takes for the success. A kick off meeting is just not about the client or the software that is going to serve the clients requirements, it is all about where the client wants to see their business in the dynamic world and how we can be a part of their continuous journey.

I would recommend using 2 ears and one mouth in that ratio. Listen to the issues and ask great questions to uncover the challenges, the evidence and the business impact. When you have done the above you may be able to recommend a solution.

In my experience, it is key to understand the client's company culture and how they execute projects typically. Once understood, one can align the client's approach with some of the industry best practice approaches. In this way, one builds better rapport at the initial stages of the project.

Ask yourself, what was the *intent* of the customer's initiative and associated scope? Have you researched the nature of the completed sales cycle and received a proper handoff from the business development team prior to this meeting? Is the lead seller attending? (Hint: yes, they should be attending). There are four corners of a contractual scope document but limitless potential to miss associated context not shown on those pages. Internal alignment and seamless transition from sales into delivery is paramount and an absolute necessity to consider before you even write your first bullet point for the agenda.

A kick off is often the first opportunity for the business to ask questions, understand the overall plan, the key roles & responsibilities, communication plan and get a grasp of what's in it for them. Best to leave enough time for some Q&A. People always appreciate to have the opportunity to speak up.

Empathy plays a pivotal role here, - this human ability to understand and share the feelings of others. The point here is to step into an empathic posture to be able to capture the weak signals and build an authentic relationship with the stakeholders. Understanding and stepping into their shoes is valuable to encourage genuine collaboration. It helps to grasp the needs, expectations, and concerns of everyone and gain a deeper insight into each perspective and motivation. This creates a space where each party feels heard, respected, and encouraged to contribute significantly. It can really encourage an environment of trust and cooperation.

In my experience, clients aren't used to the same level of collaboration, workshopping, and thinking out loud as consultants tend to be! I've found it helps to start off with ice breakers even if it seems silly to loosen up the crowd and get everyone comfortable with sharing ideas and opinions without fear of scrutiny.

You need to be a chameleon yourself to do this well in technical engagements where you will initially inevitably get a spectrum ranging from total detractors to overconfidence and overestimation of capabilities. It's only by engaging at the individual level you can gain trust and bring people to that common ground of reality, positivity and alignment. This can take weeks, and may need to be revisited throughout the engagement lifecycle - IMO it is the keystone of success.

The customer stakeholder(s) must have a voice in the kickoff. The success pf the project will require both parties to be committed. From the customer's perspective, having your leaders share their motivation and excitement for the project is usually more impactful than hearing from the vendor. Always make it about we/us.

In my experience both empathy and understanding of the business and the business problems to solve will create a more cooperative environment ensuring success. It is the time where we must show that we truly understand their goals, and show them a roadmap to the solution with their participation and collaboration.

This should go without stating, but ensure you have restated the customers problem statement and ensure you are clear on what aspect(s) of the problem this deliverable is designed to help with. Scope is all about defining and agreeing on deliverables, project/development sizing. Without proper agreement on the problem itself and how this development/ project relieves that problem, the scope is irrelevant.

Nailing down and reinforcing exactly what the project covers is a critical factor. By making the scope crystal clear, everyone is on the same page, thus helping to prevent any confusion later down the line. Then comes the acceptance criteria – hashing out what success really looks like. Getting everyone in the kickoff meeting to agree on these standards helps to ensure that everyone is pulling in the same direction, keeping expectations in check as the project rolls out.

At my company, the first "sprint" is the written Scope and Requirements documentation for the complete project. We start at a high-level conceptually and work ourselves into more and more details as the conversation engages. Once the client/stakeholder is confident that the software company has the correct assumptions and understandings, the Scope and Requirements take on greater meaning. This is when the discussions on risk and risk management can take place as well. The scope becomes the blueprints of the project, and will be referred to in every future meeting and programming event.

Don't wait 45 minutes before asking "So, how does that sound?" Listen for the "Yes buts..." The first ones will be about why the project plan won't work. The later ones will be identifying obstacles to its success. Listen for the difference before you answer.

In my consultations I always start by looking at the realities we are facing and what is expected of the team. Additionally I set about having the various team members take the time to learn the 'Why' and 'How" things are done, to understand the current processes we are here to replace / repair. There are reasons for why people do things and why processes are set up a certain way and unless we understand those elements the project gets bogged down and could likely fail.

In addition to handling delays and deviations, it is also useful to track the impact on the overall timeline. At the end of the project, all members of the team will have an understanding of the occurrences and their specific impact on project completion timing.

I always find it helpful to create a role and responsibility matrix aligned with the timeline. Everyone knows who is working on an aspect of the project and when. This helps highlight planned time off, organizational events and other unavailable days.

Dependencies can vary largely in nature, from other projects, external events to access to client's resources. It's likely that more are discovered as the project progresses.

For agile projects the planning and delivery will be handled differently to this standard project methodology timing and milestones.

Similar to last points, a lot of shoulds and punctuations especially the double “and” after commas. Keep one “and” only the last one. Reduce the size of the sentence if you have many commas. Content is good. Maybe bullets will be more clear in this section because it’s timeline. A sequence will look more clear.

Create and align on a RACI matrix. A RACI matrix, an acronym for Responsible, Accountable, Consulted, and Informed, is a tool used to clearly define roles and responsibilities for tasks or deliverables in a project. By employing a RACI matrix during a software kickoff meeting, teams can ensure clarity in who owns what task, who makes decisions, who needs to be consulted, and who stays informed. This upfront clarity minimizes ambiguities, streamlines communication, and sets the foundation for efficient project execution.

In my book, "Software Development Playbook", I maintain that frequent and constant communication is a key to success throughout the lifecycle of the project. It lowers the fears of the stakeholders, and keeps the programming team on a stricter programming agenda, ensuring a strong finish on or before the delivery date. Letting the users know what to expect, and who is responsible for different aspects of development leads to closer relationships and better communication - which means a smoother working relationship and an expected outcome that is attainable. We never "surprise" our clients, and always speak the truth. No candy-coating for time and effort.

Looks good. Similar to first point, have combination of other modal verbs. Sounds more instructions than engagement article. Instruct the AI to use various verbs and avoid repeated ones.

Da es gerade sehr schwer ist Mitarbeiter zu finden sollte es jedem Unternehmen klar sein das neben Incentive dem Cafeteria Modell das Thema (Work Life Balance) ein übergeordnetes Kriterium für den Bewerber darstellt, und damit allem zum Thema (New Work) sollte bestens durch dacht sein, aber dafür dürfen dann auch Höchstleistungen des Mitarbeiter erwartet werden.

Content is good. Instruct the AI to have powerful conclusion to grasp the attentions when summarizing the topic sentences in introduction rather than also instructing in conclusions. Excellent article for first draft AI. Just better prompts for punctuations and verities verbs transitions. May be also extra layer of a tool after first draft until the AI gets smarter. I’m impressed. Thanks LinkedIn for choosing me.

Everything makes sense, I suggest adding elements of accountability, such as setting up the 5 Ws structure at the end and making stakeholders confirm it.

In my opinion and also experience, defining fixed next date / meetings is key. Of course, depending on the own agenda and staffing power, but usually pushing the client with specific suggestions leads to a quicker follow up. In every case, kick-off´s are kind of "speed dating" for the team and the client. So kick-offs are awesome to get a first atmosphere and culture check. Remember the other part is knowledge and experience, so the teams need to start working quickly afterwards to make the engagement a success.

Anytime next steps are captured be sure to identify these three things: 1. Who will perform the task 2. What is the task / how will we know it's successfully been completed 3. When does it need to be accomplished by Clear is kind in these scenarios.

By way of example, this summary of "next steps" can also introduce the manner in which Project Status / Updates will be delivered. Set this tone professionally and with an appropriate sense of urgency for the audience to take the right actions and in the right time frames.

Building a ONE TEAM culture, all working together towards the same goal! While a consultant's job is to come in and deliver, sharing accountability for a successful outcome between consultants and clients builds a better collaborative environment. When the project team inevitably hits a bump, the narrative shifts from finger-pointing to collaborative problem-solving to get the job done.

In my experience, sometime the client won’t know what they want exactly. They’ll have some idea, which could be inspired from a previous software they used. As a consultant, it’s good to keep it in mind as you work with client to define scope. It’s necessary to push clients to accept latest tech and software through the entire journey of software consulting project.

Choose a team that can relate to the customer, either with domain knowledge or similar experiences, to help build rapport with the customer. Choose the correct team size and composition. Each member of the team should bring something uniquely valuable to the customer. The team needs to work as a cohesive unit. The team should have a healthy debate toward a common goal. Having opposing ideas without clear reasoning will make the customer question the capability of the consulting team.

Present as one team…!! Align on the presentation with core team before the presentation to senior management While presenting give opportunity to different stake holders from both sides to present, this will help in bringing out the idea of one team

It is helpful to include people with disabilities into the process. Maybe your client has a disability, others who are familiar with disabilities can help you navigate that process. People with disabilities help your company think of how you can help accomplish your and your client’s goals. Including people with disabilities will make your program and software more accessible to more people and will help you earn more as an organization. Not just monetarily, but with engagement, new clients, kick off ideas, socially and otherwise.