"Sorry, there's no room on our roadmap to help with that this year." I remember hearing those words from the IT team with a sinking feeling. We had nearly finished the algorithmic work for our latest data science project, and now we needed IT's help to get it into production. Clearly we hadn't communicated about that very well with them.
If you're in this situation, looking for a quick fix ... I didn't discover one. The project launched much later than we'd planned, and my abortive attempts to pressure them didn't help the relationship.
During our debrief at the end of the project, we wanted to make sure this never happened again. We realised that we needed to involve them (and other stakeholders) in the project from the very beginning to get their buy-in. And so the Project Kickoff meeting was born.
A good Kickoff meeting gathers the key people for the project together: from your team; from other teams whose help you need; and business stakeholders.
It's a chance to clarify what you're trying to achieve - what's the motivation? what would a good outcome look like? and how are you going to get there?
It highlights the risks, so you can address them.
And it clarifies the role of everyone involved.
If there are blockers, it's always better to discover them early. And you'll probably find that people are more willing to find solutions when they feel included from the beginning.
It's probably best to have the Kickoff as a meeting, with some kind of presentation or document to structure the conversation - this is the template I use.
For shorter, simpler or less critical projects, you can race through it in under an hour, especially if you're well-prepared.
For a more complex project, you might find that even a 90-minute Kickoff Meeting doesn't resolve all the questions that get raised - that's fine, as long as you commit to following up on them afterwards. And if it's a really complex project that requires a lot of buy-in, you might even need pre-Kickoff 1:1s with critical people, because it's often easier to talk through obstacles and win people over individually than in a group.
Once you realise what a difference the Kickoff makes, you'll probably choose to schedule a Review Meeting every few months with the same group, to: check progress against your timeline; discuss unanticipated problems; and remind people of their commitments!
From that point on, we started all of our data science projects with a Kickoff, and the IT team were first on the invitation list. And we never had a communication breakdown like that again.
Postscript: I'm writing this now because of a Postmortem last week in a new company. An important partner had noticed a gaffe in one of our demos, and it had shaken their confidence in us. How did we ever allow that to happen?
- We realised that we had been treating the work as a low-priority internal project, because we hadn't considered how damaging a bug could be to our reputation and sales. (A Risk Assessment would have avoided this!)
- The project had been managed by someone new to the role, without enough consultation from senior management. (Defining roles and accountability up front would have helped here!)
A proper Project Kickoff would have made all the difference - so I dusted off my Project Kickoff template, and here we are.
Good luck with kicking off your next project the right way.