When working on complex school projects as a child, my mother once told me, ‘Your success hinges on the early beginnings.’
Mom said it was essential to have a solid plan and to get off on the right foot. I always had Mom’s words in the back of my mind as I worked on everything from science fair projects to term papers.
I see similarities to building successful software products.
When our Client Experience team kicks off a new software delivery engagement, I can hear Mom’s words. In this piece, I’ll detail our experience in how software delivery projects can drive success from their early beginnings.
The start before the start
If your software delivery project kicks off on July 1, some members of the team need to pre-plan on June 1. We’ve seen that the most effective project kick-offs depend on 2–4 weeks of productive planning beforehand. In a typical client engagement, our team of engineers work with VPs of Engineering (and their teams) on the client side. We sit down with the VPs of Engineering before the official kick-off, listing the things that need to get done, along with assigned owners for each item.
There are logistical details to sort out, such as hardware and software set-up, the creation of internal system accounts, approval processes, and more. We define clear roles on each side and designate ‘dance partners’.
For example, the Engineering Manager on our team has a similar contact on the client-side team. The lists of names, roles, responsibilities, and dance partners are documented on slides within the master project deck.
Understanding the overall business context
When a software project fails to deliver, it’s very seldom due to a simple or tangible thing (e.g., buggy code, delays in shipping code, misunderstanding of the project requirements, etc.). Instead, failure is often due to the project team not seeing the bigger picture.
The team dug right in and told themselves, ‘We’re shipping X on date Y,’ but they never stopped to ask, ‘Why are we shipping X?’ Or, ‘How will shipping X help the business achieve its goals for this year?’
In other words, they failed to see the ‘why’ of what they were building.
When starting a software delivery project, you want to know how the product you’re building fits into the strategic initiatives of the business. Focus on having business-level conversations before considering product requirements, scrum meetings, and daily standups. These could be an initial set of meetings labeled as:
- Review of business objectives
- Identification of key business stakeholders
- Product overview/demo
- Roadmap overview
- Architecture overview
- Development process overview
Level-setting at the two-week mark
The two-week mark is a good time to level-set on the effectiveness of the kick-off activities and whether the project is in a good position to meet its deliverables and timeline. Try scheduling a formal meeting that the entire software delivery team attends.
Kick-off activities center around a set of checklists. During this meeting, review each checklist and confirm that all items have been completed. Here is a sample checklist:
- Everyone’s role is clear: dedicated points of contact and ‘dance partners’ have been identified
- Initial knowledge-sharing done (product, architecture, roadmap, process)
- No major delivery bottlenecks identified (e.g., access, code reviews, requirements)
- Goals and success criteria are defined and agreed upon for the foreseeable future
- The backlog is in place for at least one iteration and is clear to the team
- The team can perform a full code delivery cycle within the agreed-upon processes
- Regular meetings are scheduled for all activities
Continuously evaluate and improve your software delivery kick-off processes. During the pandemic, we had to adjust a process or two. I’m sure each of you has your own approach and style.
I’m interested in hearing from you: which of these approaches does your team use and what new tactics should we consider using?
