Project Kick-Off and Realignment

Struggling to get a project off the ground? Maybe it needs a kick. Are you getting what you need from your kick-off and realignment meetings?

What For?

The kick-off sets the (initial) tone of the entire project to come. It’s sort of like choosing a destination and purpose before you begin a journey: Do it well, and you’re off to a good start. Do otherwise, and wander aimlessly for 40 years.

I’ve read that the purpose of all meetings is to get someone to do something they might not otherwise do. (They might not read or understand your e-mail, but that’s another topic.) In general, people aren’t especially prone to spontaneously organize and coordinate towards a common goal without clarity and motivation. The kick-off provides both.

Whether you hold a fancy offsite with catered lunch or gather in a dusty grey conference room with notepads and coffee, a proper project kick-off accomplishes (at least) several sub-goals:

• Clients, Project Sponsors, and Lead Staff are all aligned on mission and vision.
• The lead staff is revved up to perform, with a basic idea about what’s required.
• Project philosophy and major policies are established and agreed, such as who has the authority to order and/or agree to a change in scope.
• Each party (particularly including the Client) has overtly agreed and bought into the scope of its responsibilites and the boundaries of its authority.
• Meaningful work can ramp up in earnest.
• There’s a clear and prominent record of:
  • The original goal, at least in overview.
  • The original concept of how to get there.
  • Big risks and major milestones.
  • Top-level outline of scope, schedule, and budget.
  • Responsibilities, Authorities, and modes of Accountability – which absolutely must be aligned for project success.

Localized, team-by-team kick-off activities bring similar benefits:

• The team’s specific contribution to mission and vision are clear.
• Pathways for internal communication are established.
• Roles, responsibilites, norms, and values come into focus.
• Meaningful work can begin.

Finally, periodic realignment meetings help keep the project on-track. The realignment allows for the direction of the momentum to be adjusted where necessary and given a renewed boost. They may be required with a frequency depending on magnitude and complexity of the task; ongoing assessment of how well the project is adhering to the initial goals, schedule, budget, etc.; and how much interpersonal interface the project requires. Gently massaged, the form and substance of the kick-off meeting can be a great way to draw attention to, and begin to resolve, project imbalances.

Indeed, even if you’ve inherited a disaster, cutting your losses and getting out of Dodge is a project in itself. It merits something akin to a kick-off, at least among your inner cabal.

How To?

First, all the usual rules of meetings apply:

• Block out an appropriate amount of time.
• Invite the right people, and make sure they can pay attention.
• Specifically exclude the wrong people. (Their identities are left as an exercise for the reader. Use your imagination.)
• Set the right agenda. (A sample is below, but you’ll want to customize it.)
• Have someone designated to take the minutes/notes. (This, and the lead/facilitator, are the only person allowed to open their laptops/phones/tablets/etc.)
• Document the meeting’s agreements, commitments, decisions, and action items.
• Consider getting the key authorities to sign off on the meeting notes, as this firms up the commitments.
• Publish the results of the meeting in a proper place promptly.

The initial kick-off is much more in-depth. A realignment meeting can usually share the same basic structure and agenda, but quickly gloss over areas deemed to be working just fine.

Because the kick-off is designed to impart the initial aligned momentum to a team, you need immediate follow-up, loudly and with much fanfare, to make sure everyone knows where to find the resulting artifacts and understands the key points therein. And I do mean everyone, all the way from the executive sponsor to the summer intern.

Because of what kinds of things are established in a kick-off, it’s important that your entire task force understand the key points, whether they attended the meeting or not. This includes new members as they come onto the team – modified by anything that comes from realignment meetings of course. This does more than help people get oriented. It also diminshes the chance of disaster, as this quote illustrates:

… bidding on work in the Amazon river basin and people were made aware of the reason that there was to be NO contact with any of the indigenous tribes who were still more or less isolated from the modern world – kind of an ethical question, but really more of a safety and legal consideration as it was against the law in the affected countries (the east of Peru or west of Brazil if I recall correctly).

And again, you’ll need another larger cycle of follow-up to make sure the effects stick across time and space. When new people join, give them a copy or link to read the kick-off artifacts. See that your lieutenants are getting their subordinates aligned on mission accordingly. Check back periodically, both vertically and horizontally, to see what needs to change.

When appropriate changes are agreed:

• Modify the kick-off artifacts accordingly.
• Highlight the actual changes.
• Distribute them loudly and with much fanfare.

You may choose to separate kick-off into two phases: one where you get your own team working well together or discuss sensitive internal issues, and another involving the Client. This is particularly valuable when composing teams from people who have not worked together before, or who hail from different cultures.

Finally, if you’re relatively new at this, or if the organization doesn’t do this all the time, then have a look at the section on related cultural issues and see what you might need to nail down.

Sample Agenda:

What do we know about the Business Requirement?

• Definition of Success
  • By the way, now’s the time to think about design life.
• Identity of Stakeholders:
  • Not just owners, but also
  • day-to-day operators
  • maintainers
  • construct/deploy/IT infrastructure people
  • developers/engineers/designers
  • incident-response team, for supportability
  • (maybe more?)
• Known and Unknown Constraints:
  • Regulatory
  • Ethical
  • Technical
  • Budget
  • Scope
  • Schedule
  • Logistical
  • (maybe more?)

What definition and analysis has already been done?

• External System Boundary
• Transactions necessary to implement core functionality
• Operabilty, reliability, and monitoring concerns
• Size:
  • Data, Compute, Storage, Communications
  • Feed-stock Charateristics, Process-plant, Import/Export terminals
  • Your industry here
• General layout / breakdown / roadmap:
  • features and sub-features
  • systems and sub-systems
• Partners, colleagues, and vendors:
  • Points of contact
  • Service level agreements and responsiveness expectations
  • Multi-way interface agreements (I need Alice and Bob to cooperate…)
  • Specifications on deliverable artifacts and services
  • Scope of support after the fact
  • Any costs involved, or money changing hands
  • Logistical concerns

Broadly speaking, how shall we proceed?

• Roles and Responsibilities (in the abstract)
• Key Persons list (concretely, who embodies those roles)
• Action items: short, medium, and long-term
• Time line for follow up on each scale

Some related cultural issues

How do we keep this large project on track?

• A growing team requires an evolving management style.
• Bigger projects require more careful planning and technical documentation.
• What’s the GICOT (good-idea cut-off time) for different kinds of changes?
• The forecast: It needs to
  • exist, and everyone should see it.
  • change, and for the right reasons.
  • achieve more detail, as activities approach or complete.
• What fraction of efforts, on a continuous or periodic basis, will you devote to:
  • Refinining and scheduling the near-term forecast?
  • The same, but for intermediate term, and longer-term?
• How shall we measure and manage the schedule?
  • Take small bites.
  • Plan the work and work the plan.
  • Don’t get too far ahead of yourself.
  • Lather, rinse, and repeat on a defined cadence.

How shall we refine the scope successively until the bites are chewable?

• This smacks of top-down design. That’s fine; I believe in it.
• It also sounds like big-design-up-front. It’s not; you can leave sections to be refined later.
• Agile tempts people to procrastinate on refinement, especially for high-risk features with external dependencies, because there’s generally something more immediately acheivable.
• Beyond some threshold size, nobody volunteers for a task. To mitigate this, make tickets for investigation and design. Decide ahead of time the format of these artifacts. Use the results to create smaller, more detailed tickets.
• Project teams can get defensive around dependencies – especially the high-risk ones – because nobody wants to work an unachievable goal. It’s tempting to just declare an API, but don’t get too far ahead: the risk YAGNI (You Ain’t Gonna Need It) becoming thrown-away sunk-cost deletium increases exponentially.
• If you’ve done all you can and a goal is genuinely wedged, make a loud clamor to the sponsor or whoever else has influence.

How shall we communicate the forecast, schedule, and progress?

• The medium, and the nature of the message?
• Amongst ourselves or with external stakeholders?

What information composes the forecast?

• Hint: it’s not just time-to-completion. That would be the schedule.
• The project’s entire demands.
• Quantities and specifications of every component in the final deliverable.
• If you’re in the software biz, remember: We do not sell lines of code!

What information composes the schedule and progress?

• On what scales shall we define blocks of work?
• At each scale:
  • Which blocks are in what status?
  • broadly speaking how fast are we moving?
  • Who all is working on which blocks right now?
  • What blocks are stuck or at schedule risk, and why?
  • What blocks require what other blocks complete before meaningful progress can begin?