How to start projects right

Digital projects often have a large entourage of cooks. By that I mean multiple stakeholders such as the product development and design team, different client departments, CEOs and others – all of whom want a say in the final delivery (as they should).

But not all stakeholders are acquainted with product development and design thinking processes. Neither are they necessarily aware of what technology enables. Their opinions about digital transformation are also most likely formed by what they have read online, not out of experience.

Because of this, during the first digital project stakeholder meeting, its participants often tend to pull in different directions. At the end of such meetings, it is common to find that no two stakeholders are on the same wavelength about the project’s deliverables.

So the question is: If a disparate set of people across a company’s different departments collaborate on a project that deals with a subject many of them are quite unfamiliar with, what is the best way to begin? How can the company ensure that the project is executed most efficiently, and succeeds?

In my experience as a designer and strategist handling digital innovation in organisations, projects that follow the three-step workflow outlined below are more likely to succeed.

‍

‍

1. Kickoff – Let’s all get on the same page.

2. The Project – We have a lot to deliver, let’s collaborate well.

3. Retrospective – What did we learn from this project?

‍

‍

‍

The beauty of this process is that it can be as granular as you want it to be. You can start with an overview of the whole project, or zoom down to a specific function that you want to work on. Use this process whenever there are multiple stakeholders and expectation management is key.

The Kickoff

Ensure that a “kickoff” is held as soon as a project is initiated. Holding this meeting will allow you to manage expectations and quickly illustrate which direction you will be heading for the duration of the project. This is why the kickoff must include all stakeholders.

A kickoff is essentially a knowledge sharing session. For some, it is a day of Post-Its and Sharpies. For others it is a fun break from work routines. Whatever the motivation, its participants must come prepared and share as much of their knowledge during the session so that the project delivery team runs with that information and can deliver value at the end of the project.

I’m assuming here that the delivery team has already held its own internal meeting and are now well aware of the project goals, stakeholders involved and time-plan to complete the project.

So what goes into the kickoff?

1. Team introductions — It’s difficult to work with someone if you don’t know who they are or what their objectives are. Team introductions help fix this. The introductions can be informal with some banter so that all participants get a sense of the energy in the room.

2. Discuss the initial project offer that led up to this kickoff — What brought you all to the table to start talking about the project? What was promised and what was discussed about the time-plan and the scope? You don’t need a deep dive into this topic, but it’s good for everyone in the room to get a quick understanding about why they are there.

3. Understand the goals of each stakeholder involved — This is an important step. Not everyone at the table has the same goal or vision for the project. Motivations also differ: for some it’s personal KPIs, others have been told to deliver a project by the management, and on occasion the project is initiated because of leftover annual budgets. Whatever the reasons, the project delivery team at the kickoff must ask enough questions to get an understanding of these goals and motivations and identify a way to take into account the stakeholders’ personal goals too by making the upcoming collaboration exciting for everyone.

4. Collaboration methodology — It’s important to identify early on what are the tools each team should use to collaborate so that there is no confusion later. This is a crucial yet often ignored part of expectation management. For example, is everyone expected to use Skype for Business or Google Hangouts, or Slack or Google Documents or Microsoft Sharepoint? Specifying what tools will be used early on ensures efficiency in workflows across teams. Basically, any process that can be streamlined to avoid corporate bureaucracy or confusion must be discussed early in the project.

5. Planning for speed bumps — All projects will have speed bumps. You could choose to be reactive towards them, or you could preempt them and talk openly about the issues you might encounter during the collaboration. It could be something as mundane as access to content, file-sharing access, or something even more critical such as not getting complete stakeholder buy-in in time.

‍

The Project

This broadly refers to the time period during which the project is being executed. Since there are many jobs to be done that are vast and often more complex, a rough project time plan must be set so that a weekly rhythm is set with the project team and stakeholders.

Weekly “sync meetings” with stakeholders as well as “project gates” with the project delivery team must be defined. These gates can be used to ensure that project owners get the necessary buy-in from all stakeholders at the right time. In order to run projects that have a limited time and budget, it is important that these steps are planned into the workflow.

In the case of digital projects, a typical project gate would come after the user experience (UX) and prototype testing phase. This is set so that when the user interface design work is ongoing, no one attempts to dig up the foundation (the previous step) as that will simply be inefficient and frustrating for those running the project.

So what are the actions one can take to ensure a smooth project phase?

1. Weekly syncs and daily stand-ups — Ensure that weekly meetings are conducted with external stakeholders, and daily stand-ups are conducted with the project delivery team. This allows even those who are not participating in the actual design and development of the project to be involved enough to be able to get their points of view, experience and ideas across to the team running with the project.

A note of caution: You must ensure that the weekly stakeholder sync meetings do not turn into a weekly delivery meeting. They must be treated as a collaborative work session where the delivery team is not focussing on building presentations for stakeholders. This must be a status meetings leaning more towards open discussions and collective problem solving.

2. Milestones and checkpoints — An efficient project plan will often have a few milestones set into the future so that the project is continuously moving towards smaller milestones that the team can build on, measure, and learn from.‍

3. Project owners and their responsibilities — A project owner must be an active part of the implementation team and also of planning. This is to ensure that the project owner, who is responsible for the delivery of the project, can empathise with any problems the team runs into and ensure that the broader vision of the project is in sync with the vision of the upper management. Typically those directly involved in the production/development of the project should rise to this role. But be aware that this role is not necessarily project management. The last thing you want is management leading more management leading more management… you get the drift.

4. Waterfalls belong in nature — Ensure that your project team doesn’t work in isolation or in silos. Often, the project delivery team is broken up into smaller teams and assigned a specific task each. When there is a lack of project ownership and understanding of its vision across the delivery team, these smaller teams finish their work without really understanding how their tasks contribute to the success of the entire project. This, naturally, affects the quality of work done. The team that takes over for the next step  struggles to incorporate that work into the project. This is not only a waste of time and a blow to efficiency, such situations are often a big risk to the health and success of the project. This is why any good team must not be scared of asking the question “why?” Everyone should know what the big picture is.

5. Don’t be afraid to pivot — As many wise entrepreneurs have said, failure isn’t necessarily a bad thing as long as you can realise it and take the necessary steps to regroup. Realising something is failing early on is the only way you can take necessary actions to succeed going forward. You can’t fix an oversalted pot of food by adding more salt. Just throw the dish out and start over already.

This brings me to my final step.

Retrospective

Often managers and even team members forget or don’t prioritise this phase of a project. But this is an important step especially when the top management wants a team to take more ownership of their work. Holding a retrospective is also the surest way of knowing if the team worked well together or not. This will help the company in future projects.

But what exactly is a retrospective?

It is the process through which a team can reflect on their successes and failures while working together. It is a forum that gives team members a chance to acknowledge and voice their understanding of how the project unfolded – both the good and the bad. It will allow the team to grow collectively, move on from their mistakes, and hopefully not make them again.

How is it conducted?

There are many techniques available. But if you have followed the process of a project time plan as shown above, draw it out on a whiteboard. Now tackle each phase, asking participants around the room to list what was the “good” and “bad” in each phase. If you don’t want to use the word “bad”, you can use “Areas of improvement” :)

‍

The “good” and “bad” listing in a project isn’t necessarily restricted to just the team’s performance, but also the collaboration with the stakeholders and management. It could be about time-plans, budgeting, scoping, delivery pressure among other things.

Here are four recommendations to get the most value out of a retrospective.

1. The project lead shouldn’t lead the retrospective — Someone other than the project lead must lead this meeting as that allows the discussion to be less of a report card session and more of a team discussion aimed at working better going forward.

2. Ask questions like — What worked well? What was lacking? What did you learn? What do you long for going forward?

3. It’s not personal — Don’t make your comments personal or take any feedback personally. Retrospectives must be a safe space to voice an individual’s concerns or point of view.

4. Action points and clear next steps — Don’t just conduct the retrospective and toss all the notes into the post it pile from hell. It is important to document the discussion points and address them at any subsequent kickoffs to ensure that those mistakes are not repeated in future projects.