Client Project Kickoff Tasks
This week you and your client will be receiving an email from me about setting up your kickoff meeting. The meeting should be scheduled and happen within one to three days.
The kickoff meeting is absolutely critical to the success of the project. Many things have to happen, many unknowns have to be managed, and you only have an hour!
Preparation and focus is the secret. Below are steps that can make kickoff efficient and effective:
- Define your roles
- Create your team slides
- Contact the client to set up the kickoff
- Set up the weekly client meeting schedule
- Kick off the project
- Adapt your infrastructure
A few of these tasks need to be recorded in the appropriate shared Google docuument. See the Canvas assignment for links.
Team roles
You don't want silos of expertise in a team. That leads to low bus factors. But you do want to have roles on a team, to make sure common non-technical tasks don't slip between the cracks. Every team works out what roles they need but a few are common and important when working with clients.
Here are the roles you need to fill before contacting the client.
Email contact point: All emails from the team
to the client should go through one person, so that the client
can easily find all project emails.
- Always CC the entire team and all clients on all emails.
- You do not need to CC me.
- If the client forgets and replies to just the contact point, the contact point should forward the email to everyone -- the team and clients -- so they get the point (nudge, nudge, wink, wink).
- Note taker: Never never meet with a client without
at least one person in charge of taking notes.
Clients notice when no one is writing things down.
- Note takers must focus on writing, not talking.
- The note taker must then circulate the notes with the team shortly after the meeting, for correction.
- The contact point then sends the notes to the client for confirmation.
- Because note taking takes time, and reduces participation in client meetings, I recommend you rotate this job from meeting to meeting.
A formal role in Scrum is product owner. Look up what it is and decide if you need one, or how you could tell if you need one.
Team Slides
Team slides are like a web site for your company. A quick way for the client to see who you are, what you've done, and how to contact you.
Create your team slides in the slide set I created in the shared Google client projects folder. Clients will have full access that folder.
- Edit the pictures and text for team member slide
- Insert right after that slide
- Your current product box slide
- Your 4-panel storyboard
Contact the client
Email the client to
- send them your email contact info
- send links to your team slides, and any other links you think relevant, e.g., a Trello board
- set up the first meeting time
- set up the schedule for the two weekly client meetings for the rest of the project
- ask the client to send you their 4-panel storyboard and other material
Every team member should look over the client project material, write down notes on what you think will need to be built, then compare your notes with the team. Differences suggest important questions to ask the client at the kickoff.
Weekly client meetings
There are two weekly client meetings, very different in type and purpose:
- a 1-hour face to face iteration planning meeting
- a 30-minute midweek checkin -- this is often a conference call
Kickoff meeting
The kickoff meeting is where you get to know the client as a person and what the real goals of the project are. It's where they get to know you as people. It's where first coding tasks have to be defined, in such as way as to maximize value to the client, not the developers.
To define the first iteration deliverable
- Start with the payoff in panel 3 of the 4-panel storyboard
- Slice it to something you are very confident you can build in one or two swarms that can support user testing the payoff proposition
- Collect sketches of the user interface
- Write out a user interface flow
- Define at least one acceptance test example with specific data
- Try to have at least one outline of a user test scenario that the deliverable will support
Project infrastructure
You won't know until you meet the client exactly what technical infrastructure you will need. Some things are that often done differently in the client team project are:
- Mobile web rather than hybrid app: Web is a lot easier, but limited. Many clients want apps, not mobile web, even when mobile web will work. The client decides.
- Two permanent branches: master and development. These should be merged at least once a week, if not more often, but only when the client is ready, i.e., not in the middle of testing. Create feature branches off of development.
- Shared task board, e.g., Trello or waffle.io or others, that clients can access and modify.