IT projects do not have a great success rate. \u00a0However, a project kickoff that includes some simple steps can significantly improve its odds. \u00a0These are not technical steps so anyone can do them. \u00a0If your next project skips these steps, then it is more likely to become another unpleasant\u00a0statistic.<\/p>\n
The first step in a project kickoff is: clearly define your why. \u00a0We have looked at this in past posts, and it is critical on your journey. \u00a0The “why” of your project helps you define where you are going and\u00a0parameters for the trip. \u00a0Do not stop with just defining it either. \u00a0The team should have the “why” communicated to them, and that should provide a focus for them during design, implementation, and beyond. \u00a0The better the “why” is defined and understood by the team, the less likely there will be functional or other drift.<\/p>\n
This step is similar to the “why.” \u00a0Accordingly, it is the next logical step. \u00a0First, we define our project at a high level. \u00a0Next, we list the problem or problems we are solving. \u00a0The problem solved is the answer to an important question, “Why should anyone care?” \u00a0We do not take on projects just to spin our wheels. \u00a0There is always a problem that is being solved, and that is what gives the project value.<\/p>\n
This question is a tough one. \u00a0Unfortunately, this is where a lot of the pitfalls also live. \u00a0When a project is envisioned, there are often pieces that we\u00a0take for granted. \u00a0For example, let’s consider building an application that makes it easy to move money among banks accounts. \u00a0We are likely assuming that there is a login, user authentication, bank account linking features, error messages, fraud restrictions, and much more. \u00a0All of these functions are critical to the success of the project, but easily overlooked when we ask a team to implement it.<\/p>\n
This is a step where two things are assessed and listed. \u00a0There are the risks to the project success. \u00a0The risks include lack of resources, lack of funding, competition beating us to market, etc. \u00a0Then there are the exceptions to the solution. \u00a0These include handling bad data, loss of needed connectivity, and even things like a forgotten password. \u00a0At this point, none of these items need to be addressed at a detailed level; they just need to be considered. \u00a0The goal of this step is to ensure we are aware of potential risks and pitfalls and the plan take them into account. \u00a0We also might find priorities that come\u00a0from this action. \u00a0For example, the market window for a product may be known\u00a0to close in a known time frame. \u00a0The product has to be completed in that period to have any chance of success.<\/p>\n