Six Tips for a Successful Project Launch
If you are like me, you greet the new year with a combination of excitement and trepidation. You come back from the holiday season with your fill of food, family, and -- in the US at least -- (college) football. You're anxious to make some positive changes in your life, both professional and personal. So you make these ambitious, grandiose, well-intentioned New Year's resolutions.
And then proceed to not follow them come February or March.
Project launches have a tendency to resemble New Year's resolutions, but they don't have to. Project launches seem like they go very well, but that success does not carry over to the project as a whole.
Here are six things you can do during and after the project launch to improve the chances of project success. After all, project success is the only real indication of a successful project launch.
Identify Your Assumptions and Validate Them
In every project launch, no matter how much you think you know you make a lot of assumptions. You probably know that you need to record those assumptions, but what do you do with that list once you've created it?
Identifying your assumptions is a good start. Put that start to good use by validating those assumptions as soon as you can, especially those assumptions that could torpedo your project if you find out they aren't true.
A helpful technique I've found for this is Assumptions Mapping as described by David Bland. Even if your project is not creating a new product, you can use the idea of collaboratively mapping your assumptions based on whether they are Unimportant or Important and Unknown or Known. Then you can run experiments on those assumptions that are Important and Unknown.
Assumptions that would torpedo your project will most likely fall in that quadrant.
Identify Your Risks and Address Them
At the beginning of a project, you don't know much and you have a great deal of uncertainty, which means you have a lot of risks. It's standard practice for teams to identify those risks when they start out, but not as common to do anything about them. Part of the reason may be that the teams are doing a check-the-box activity. ("Well, we're supposed to identify risks, so let's talk about them. Check.") But in other cases teams don't do anything about the risks because there are just so many of them.
A good way to structure a conversation about risks and come out with a subset of the risks that you need to address right away is the Risk Management Game that I learned about from Ken Clyne and Julie Chickering. You can use this technique to collaboratively identify the risks you face and find the ones that are high impact and high probability. Then dive into more discussions on how to move the risks that show up in the upper right-hand part of your chart (High Impact, High Probability) down and to the left, or off the board altogether.
Identify Your Decisions and Who Will Make Them
Many people in the agile community talk about self-organizing teams, but in a way that sounds more like anarchy than good practice. That's a flaw in communication rather than a flaw in the idea. The important aspect of self-organizing teams is providing the team satisfying a need with a destination (what outcome you seek) and the guardrails (you could say constraints) they need to stay in to get there. What happens as long as they deliver the outcome and stay within their boundaries is up to them.
A big part of that is distributed decision making. The most effective decisions are those that are made by the people who have the most current, correct, relevant information. So the leader of a team is still likely to have the most current, correct, and relevant information needed to determine the ultimate outcome and whether it's worth delivering. Members of the team have the most current, correct, and relevant information about the small course corrections to get there. Decision making is also more effective when one person makes a decision.
So to avoid wasted time and gnashing of teeth, determine who is going to make what decisions before they show up. That way there's no surprise when those decisions come up. I've found a good way to guide that discussion is to use a RASCI chart with a twist: Use Accountable to represent who decides about a particular topic. It would probably be more useful to denote that with a D, but it's harder to say RDSCI.
Identify Your Metrics and Measure Them
In order for the team satisfying a need to know when they've accomplished that mission, they need some way to measure progress and success. The most common measures are often output-based and measure activity rather than accomplishment. Teams generally take that approach because it is easier to measure output than outcome.
The interesting thing is, when they launch a project most teams still discuss what objectives they are trying to hit. Those discussions are not very useful because, as with risk lists (and assumptions), the discussions resemble check-the-box activities. We're doing it because that's what the methodology says we're supposed to do. As a result, the objectives that come out of those discussions aren't very useful, primarily because they are not measurable.
I suggest instead you start out by discussing how you will know you have been successful and how you will measure that. Then, if that measurement requires a bit of lag time between implementation of something from your project and feedback on whether it's working, figure out if there are any shorter-term metrics you can use.
Then, actually follow up and use those metrics to help you answer the "continue, change, or kill" question on a regular basis on your project.
Identify Your Working Agreements and Follow Them
Project launches are the honeymoon of the project life cycle.
Team members are excited to get started.
The majority of the team is optimistic and has all these grandiose ideas about how well the team will work together. (Note I'm assuming here that the project team was pulled together specifically for this project, instead of an approach that more and more people advocate which is to have long-standing teams that go from one project to another)
Then reality strikes and team members start to find out about those annoying habits, like the teammate who clips their fingernails at their desk, or the one that wears headphones while working and sings along with the song they are listening to, or…
Whether your team is distributed or not, and whether you have worked together before or not, it's always a good idea to discuss how you'd like to work together. That discussion should clarify everyone's expectations, and it should happen before you get to the point where people's unstated expectations are not met.
Have this conversation when it is least uncomfortable so future irritations (they will arise regardless of whether you have working agreements or not) can be handled quickly and in a way that won't rip the team apart. And as with all the other suggestions, actually follow what you discuss and agree to.
Identify Your Plans and Adjust Them
Most people expect project launches to result in plans. Depending on your methodology you could have a lot of plans covering every aspect of the project.
If the act of putting those plans together helps you figure out how you're going to approach the project, or at least how you'll get started, that's great. Just remember: the day after you put those plans together and start implementing them, they will be wrong, no matter how rigorously you follow them. Stuff happens and you'll need to revise your plans.
You should certainly make plans. You should certainly do that in as collaborative a manner as possible. You should also revisit those plans on a regular basis throughout the project, both at regular intervals and when new information presents itself.
Your plans aren't the only things you should revisit and revise. Reflect on each of the actions above and determine if they are working for you or if you need to change them up.
You'll want to revisit the assumptions you hold on a regular basis. Which ones have you validated? Which ones are false, meaning that you now need to change your approach?
Have you addressed the major risks? Have new risks shown up?
How is the decision making going? Do you have new types of decisions that you didn't anticipate?
How are you doing reaching your outcome? Are you making the progress you wanted to, or do you need to change or kill the project?
Are your working agreements standing the test of time? Do you need to add some or take some away?
Did you notice a trend?
A successful project launch is all about doing the things you know you should do during a project launch, and then following up on those activities to make use of the things you did during the launch.
I've suggested a few things that I have found helpful. What things do you do during and after a project launch to increase the chances of your projects success and ensure that it doesn't join all of your New Year's resolutions in the dust bin of "things I didn't do"?
Share those techniques in the comments.