IT projects do not have a great success rate.  However, a project kickoff that includes some simple steps can significantly improve its odds.  These are not technical steps so anyone can do them.  If your next project skips these steps, then it is more likely to become another unpleasant statistic.

The Big Why

The first step in a project kickoff is: clearly define your why.  We have looked at this in past posts, and it is critical on your journey.  The “why” of your project helps you define where you are going and parameters for the trip.  Do not stop with just defining it either.  The team should have the “why” communicated to them, and that should provide a focus for them during design, implementation, and beyond.  The better the “why” is defined and understood by the team, the less likely there will be functional or other drift.

What Are We Solving?

This step is similar to the “why.”  Accordingly, it is the next logical step.  First, we define our project at a high level.  Next, we list the problem or problems we are solving.  The problem solved is the answer to an important question, “Why should anyone care?”  We do not take on projects just to spin our wheels.  There is always a problem that is being solved, and that is what gives the project value.

What Are Our Assumptions?

This question is a tough one.  Unfortunately, this is where a lot of the pitfalls also live.  When a project is envisioned, there are often pieces that we take for granted.  For example, let’s consider building an application that makes it easy to move money among banks accounts.  We are likely assuming that there is a login, user authentication, bank account linking features, error messages, fraud restrictions, and much more.  All of these functions are critical to the success of the project, but easily overlooked when we ask a team to implement it.

What Can Go Wrong?

This is a step where two things are assessed and listed.  There are the risks to the project success.  The risks include lack of resources, lack of funding, competition beating us to market, etc.  Then there are the exceptions to the solution.  These include handling bad data, loss of needed connectivity, and even things like a forgotten password.  At this point, none of these items need to be addressed at a detailed level; they just need to be considered.  The goal of this step is to ensure we are aware of potential risks and pitfalls and the plan take them into account.  We also might find priorities that come from this action.  For example, the market window for a product may be known to close in a known time frame.  The product has to be completed in that period to have any chance of success.

Beyond the Project Kickoff

It is important to note that this is just the project kickoff.  However, defining answers to these questions at the start of a project will give them the needed weight during design and implementation.  When you look at reasons for IT project failure, responding to these questions and communicating them to the project team is an excellent way to improve the chance of a successful project.