Top 10 Reasons For Having A Project Kickoff - Part III

  • Written By: Joseph J. Strub
  • Published: January 2 2004

Top 10 Reasons For Having A Project Kickoff - Part III
Featured Author - Joseph J. Strub - January 2, 2004


You are about to embark on an important project. Perhaps the project is implementing an ERP package, getting critical applications ready for the busy season, or setting up a warehouse and inventory for radio frequency operations. Whether the project is software or hardware related, it is a good idea to hold a project kickoff meeting. Don't miss this excellent opportunity to get across important communications and establish the tone for the project. In Part I and Part II of this article, we discussed the first six reasons.

In Part III, we will complete the discussion of the remaining four reasons, which can be even more critical to beginning a project on a positive note and reaching a successful completion. Starting with installing confidence in the project, this article will help you orchestrate and direct a successful and productive kickoff meeting.

In Parts I and II of our discussion of the first six reasons, we circled the project; now we are about to get to the heart of the matter. The last four reasons will require all of your skills of persuasion to convince the project team and users of the significance of the work to be undertaken. It is assumed that, as the project manager, you have already been convinced. If you are not, stop the show and do what you need to do to become a true believer. You will not be able to communicate the intended messages with smoke and mirrors. Your resolve needs to come out clearly and plausibly, even more so, in these last four reasons.

4. Define Level Of Commitment

In this section of the kickoff meeting, you let the team and users know what is expected from them in terms of their time and commitment to the project. You have already skirted around this issue when discussing training and deliverables. However, now you ensure everyone knows what is in store for them.

The Involvement Quadrant will help you collect your estimates and ideas. You expect the project manager (PM) and the business process owners (BPO) to be heavily involved in the project. Subject experts and the steering committee (S/C) are "on call", depending on the needs of the project. Be assured that the team leaders are critical to the project but will most likely be putting in less time, on an aggregate basis, than the BPO's.

The replaceable technology quadrant is intended to depict a technologist, like a database administrator (DBA), who can be substituted by another DBA. For example, if the DBA is responsible for structuring and writing reports, another DBA, familiar with the database structure, can perform this task without having an in-depth knowledge of the business. Accordingly, personnel in the replaceable technology quadrant may be good candidates for outsourcing if resources become scarce.

The interchangeable quadrant includes resources that, in total, require a heavy involvement but the workload can be spread out over a wider number of people. For example, a number of users can help perform the required testing and piloting. These time-consuming tasks do not have to be loaded on the shoulders of a few. So long as they have gained the product knowledge through peer-to-peer training, the business knowledge is already present. The same can be said for the vendor's functional consultant and it is fairly typical to have different consultants on a project as schedules and priorities get changed.

After you have determined the involvement levels of the resources, this information needs to be presented to the team and users. You must walk a fine line when delivering this message for fear of the how-am-I-going-to-do-my-normal-work backlash. The presentation format below can be an effective medium for a software implementation project.

Click Here to View Larger Image

Spreading the commitment across multiple phases and expressing it in terms of a percentage can help to mitigate the aforementioned backlash. By including the vendor's resources, the feeling of being overwhelmed by work can be replaced or, at least, dissipated by the "There's safety in numbers" theory. Bear in mind that the intent is not to fool the audience but rather to assure them the level of commitment is doable and has been done before.

3. Demonstrate Executive Sponsorship

In this session of the kickoff meeting, your true directorial skills can be put to a test. Typically, the executive sponsor will not have the time to prepare for the kickoff session. The executive's presence, though, is a positive sign of support and should not be wasted. Consequently, it will be your responsibility to script what you want the sponsor to cover. In preparing this slide for this session of the kickoff, the table below contains some suggested topics for the sponsor.

And Now Few Words From Our Sponsor .
  • Impact of the product on the business
    • Cost savings
    • Cost Avoidance
    • Efficiencies to be gained
    • Competitive advantage

  • Description of the selection process
    • Who was on the selection committee
    • All department were represented
    • Vendors considered
    • Preparation of the RFP
    • Site visitations and demo's

  • Description of the decision process
    • Key factors considered
    • Order of finish
    • Confidence in the selected vendor
    • Contract signing (i.e. this is real project)

  • Long-term impact of a successful project

Not properly planning or knowing what the executive will say can have disastrous effects.

For example: As a surprise and during the project kickoff, the executive sponsor promised to treat the team members and their spouses to a weekend in the Caribbean if the project were completed in four months. First, the project had already been delayed from starting by three months. Even with an extremely aggressive schedule, the project would take eight months and this was stated in the same kickoff meeting and before the magnanimous offer. Needless to say, the team did not even come close to meeting the deadline and getting the paid vacation. Furthermore, after seeing what had to be accomplished, the team was disillusioned and project ended up taking 12 months.

The moral is that there should be close coordination in terms of what the executive is going say and the other sessions of the kickoff meeting. In other words, no surprises!

2. Review Timeline

Throughout the kickoff meeting the audience is wondering how long it will take to install the new software or hardware product. Typically, this message will be delivered earlier on in the meeting in terms of months. However, here you want to provide more details for each phase, indicating the general start and finish ranges. The intent here is not to be too specific but to provide, at a glance, the overall timeframe of the project.

Below is an appropriate level of detail for a kickoff meeting when accompanied by an in-depth discussion of the phases. But don't worry; you will be given another opportunity in the next and last reason for a kickoff meeting.

Click Here to View Larger Image

It may be helpful to apply some metrics to the overall timeline to provide plausibility and reasonableness. Below are some metrics that may be useful in making your case and were taken from an actual project:

  • More than 5% of the project's duration is spent on training.

  • 5 business conditions per team member per day have to be tested during the pilot.

  • 2 weeks have been set aside to train users before going live.

  • 1.2 consultant days are scheduled for each week of the project.

1. Review Plan

And the number one reason for having a project kickoff meeting is, of course, to review the plan of implementation. It is the plan that will bring everything together, showing phases, resources, both external and internal, start and finish dates, dependencies, duration in days, and the timescale for the project. If you agree with the need for these project attributes, you will find that MS Project is likely the best tool for depicting them as columnar heading of your plan. But there are others.

Going through the detail of the plan would put your audience to sleep. However, it is necessary that the team and users know that such a plan exists and due diligence was exercised in creating it. A compromise approach should be considered. Accordingly, it would appropriate to display the project plan at a summary level or, better yet, have it as a handout. The compromise would be to review the first phase of the plan in detail at the task level with a discussion of each task.

An example may help you to visualize the approach suggested above. Assume that the project is to implement a software product. Typically the first phase, in which a deliverable is due from the project team, would be the As Is Definition. Accordingly, the entire plan would be displayed at a summarized level. This provides broad parameters of the plan in terms of the phases, planned start and stop dates, and a calendar timeline. A nice feature of Microsoft's Project is that you can easily collapse the detail tasks into a summary view, enabling your audience to view the entire scope and duration of the project on one visual.

Then, to answer questions as to what the project team will be doing first and to minimize the fear and floundering effect, the As Is phase is discussed and shown in considerable more detail with specific tasks and days allotted to each task. Again, it would provide comfort and instill confidence in the team to indicate the specific assistance and days spent on-site by the vendor's consultants.

To recap, where the summary view would have one-liner devoted to the As Is Definition phase showing the allotted days and start/stop dates, the detailed view should include the following tasks together with duration, start/stop dates, and inter-dependencies:

  • Review existing documentation
    • Conduct user interviews
    • Review existing workflows
    • Conduct observations
    • Vendor Consultant on-site visit

  • Document current procedures
    • Conduct white board sessions
    • Validate procedures
    • Update procedures as needed

  • Present to project team
    • Vendor Consultant on-site visit

  • Update documentation as needed


Having reviewed of the 10 reasons for having a project kickoff, you need to develop an agenda and budget time for the meeting. Below is a suggested agenda, indicating which of the Top 10 Reasons an agenda topic should cover and whose primary responsibility it would be to present.

Kickoff Meeting Agenda

Agenda Topic
Top 10 Reason
Introductory Remarks from Sponsor Demonstrate Executive Sponsorship
Instill Confidence
Define Level of Commitment
Executive Sponsor
Introduction of Project Team Introduce Project Team
Define Roles & Responsibilities
Define Level of Commitment
Project Manager
Business Process Owners
Product Overview Demonstrate Product Vendor Consultant
Review Project Plan
- Timeline
- Commitment
- Deliverables
- Workplan
Review Timeline
Define Level of Commitment
Specify Deliverables by Phase
Review Workplan
Project Manager
Vendor Consultant
Next Step
- Finalize Workplan
- Confirm Training Attendance & Dates
- Install Product
- Issue Marching Orders
Describe Planned Training
Instill Confidence
Project Manager
Closing Remarks Instill Confidence
Demonstrate Executive Sponsorship
Executive Sponsor
Questions & Answer All Reasons All as Necessary

Typically, the kickoff meeting can take a half to a full day depending on the complexity of the project and product being implemented. A product with a scope of ERP software will usually command the entire day.

Regardless of the amount of time needed, budget sufficient time for breaks since the topic will not keep the audience breathless in anticipation. Another technique is to provide rewards (i.e. McDonald's $5 coupon books) for correct answers to your questions and intersperse the questions throughout the meeting to maintain interest. Understand that it is not the size of the reward but the competitiveness in all of us that keeps our interest. Remember, that while your primary job is to dispense information, if you are not entertaining, this information could very well fall on deaf ears.

I would enjoy hearing about any additions you have to the top 10 reasons and any changes you would make in their priority. And, if you would like copies of the templates used in this article together with a detailed project workplan, please e-mail me.

About the Author

Joseph J. Strub has extensive experience as a manager and senior consultant in planning and executing ERP projects for manufacturing and distribution systems for large to medium-size companies in the food & beverage, chemical, and CPG process industries. Additionally, Mr. Strub was a consultant and Information Systems Auditor with PricewaterhouseCoopers and an applications development and support manager for a Fortune 100 company.

He can be reached at

comments powered by Disqus