Kickoff with the client
Happiness is reality exceeding expectations. We’ve been setting high expectations up until this point—that’s why the client hired us! The transition between sales and delivery can be very disruptive if not handled with care. Our industry is known to bring the smartest and most experienced professionals into sales meetings only to later staff products with offshore teams that couldn’t tell the difference between a user story and a toenail. This unfortunate reality has made buyers defensive and cautious, often resulting in counterproductive contracting processes (such as fixed bid, fixed scope). We’re a different breed, however.
To counter these negatives stereotypes we overcompensate and overcommunicate, especially in early, immature stages of the relationship:
- Build trust. Enable key senior contributors from the team (design, PM, engineering) to have a vocal presence during the kickoff process and continue reassuring the client of our professional and technical maturity. Clients should know how smart and equipped you all are.
- Reset expectations. Now that product specifics are defined, the final team assembled, it is very important to set expectations for the client about how we work and what outcomes can be expected in the coming weeks. You’ll note there are several slides in the template deck that inform the client of the flurry of activity that will follow.
- Educate. The kickoff is as much about getting started as it is about education of the client. Even if they say they’re Agile, they really aren’t. Fewer than 10 percent of companies we work with have the organizational structure, funding mechanisms, and leadership support to implement a true Agile mind-set. We’re here to help and nudge them in the right direction.
- Knock down walls. Or at least identify the first set of walls we’ll be going after. These are typically topics such as security, system access, and SME availability. Set an expectation that when we say “Go!” we really mean it—we’ll be at the client’s door the next morning, asking for access, environment provisioning, etc.
- Focus on outcomes. Align the team around specific planned outcomes for the current release. Explain the backlog, the priorities, the stories that are going to be worked on in Sprint 0 and Sprint 1—this is a sensitive period as Sprint 0 often has few demonstrable artifacts.
That should do the trick, you’re about ready to start making products. But as you and I both know, this flight will most certainly experience turbulence. As long as you know it is part of the job, you will be better prepared to manage passengers that are freaking the hell out (sometimes we freak out too!).
Establishing escalation conditions
A great team identifies and escalates risks before they materialize. In fact, one way to prevent certain risks is simply to identify them before the start of the project. During the client kickoff, the team reviews the risks and determines the best course of action for mitigating them. Some common risks are identified in the table below:
| Risk | Risk factors | Discussion points |
|---|---|---|
| Environment availability | Identify dependencies for environments | Going over the downtime of dependencies adds to the delivery timeline (e.g., nonfunctional UAT for two days extends the project by two days). |
| Partner availability and response times | Establish expected turnaround time as well as availability for third-party integration partners. Email response within 24 hours, including resolution criteria. | Review the schedule, turnaround time, communication cadence, and note impact of client review delays on timing. Adjust as needed. |
| Stakeholder participation in demos | Note the expected participation from stakeholders in demos as well as in sprint planning/refinement sessions. If acceptance is not provided within five days after the demo, the project incurs an extension of an additional sprint, captured through a chance request (CR). | |
| Feedback turnaround time | Decide team preferences for the expected communication frequency, turnaround time for questions, etc. | Present and reach agreement with the client on what the DoR (and DoD) looks like. Not meeting the DoR for high-priority stories planned for the following sprint causes an extension of the project schedule and an additional sprint. |
| Agreement on the definitions of ready and done | Determine what DoR and DoD are. | |
| Process violations | Craft a list of process violations relevant to the project and general DB process. | Go over the list and explain the Devbridge process to stakeholders and our guarantee of results if the process is not changed. (For example, forcing stories into an active sprint should be considered a violation and discussed during a retrospective.) |
Documenting meeting minutes and next steps
Record any new assumptions, changes, or deviations after the kickoff is over. Add notes to the Confluence space, send an email to the client with the summary of the meeting and the next steps in the project. Distribute the kickoff deck to all members of the client’s working team as well as to the sponsor after the meeting for reference.
Assign specific to-do items with specific completion dates to individuals from the session. Several technical dependencies likely exist—environment access, onboarding with the client, and the like.
Invoicing for expenses
The client should reimburse Devbridge for all travel expenses incurred by team members (including team or squad leads). Log traveling time per the standard procedure and bill to the customer at the half-hour rate (eight hours per day max).
If the client pushes back on paying for travel, it may be appropriate to waive the reimbursement of these costs. However, the team or squad lead should never forgo travel based on this decision. In the event a team member needs to stay for additional time beyond the kickoff meeting, expenses incurred for these days should not be reimbursed by the client. Any discrepancies on eligible expenses should be cleared with the managing director.
