Kickoff time is extremely critical on every project. It may involve a casual phone call, emails between two individuals on small projects, or it may include 10-20 individuals on bigger, high-dollar projects. But, it needs to happen to get questions answered and to correctly set expectations from the outset. That said, let’s consider some key things to remember and cover when kicking off new projects.
Do I have the right skilled team members at the right time in the project timeline?
Be sure you are ready for each task and challenge along the way. Do you have team members available at the right time and with the proper skill sets. If you keep unnecessary resources on projects too long, the project budget can be blown out of the water fast.
Are we prepared for the risks?
Have we performed the necessary risk identification and analysis? Do we know what we are going to do and how to react to some of the risks we expect might be realized?
Does the client fully understand how change management will work on the project?
We have to manage the scope of the project in order to stay on budget, and the customer needs to know how we are going to do that. What change process will we use? What will change orders look like, and when will we need to create change orders? How will they be prepared, signed off, and invoiced?
Is the client fully engaged?
Is the client on board and available when their input is needed on the project? The client may be focusing on other tasks, but the project team will need the client available for weekly meetings, ongoing communications, decision making, change orders, etc. That necessary level of involvement needs to be made clear at the beginning of the project. A project that can not properly communicate with key customers is bound to fail.
Have all training needs been met or planned for?
Sometimes the customer needs trained on a new system or even trained at the beginning of the project to help with defining the requirements. I have had customers that didn’t properly understand our delivery solution, and that caused progress to stagnate during requirement definition sessions. We have even had to halt projects and arrange a week of training for them before moving forward. Once they were trained to fully understand our configurable solution, they could participate in requirements, and we could safely move forward.
When, where, and how will meetings and communications happen?
From the beginning of the project, so at kickoff time, it is very important to establish how communication will happen on the project. I like to actually produce a formal or informal communication plan that lists key project stakeholders, their contact info, defines when regular meetings will happen, and how they will be structured. I’ve produced dozens of these throughout my PM career – on government projects when they were a paid deliverable at kickoff time and on private sector projects when they usually aren’t paid but just a nice organizational add-on. It helps answer questions upfront and instills customer confidence in the delivery team’s ability to communicate and deliver on the project.
Do we have detailed requirements in place?
From the beginning, it’s important to know where the requirements holes or big gaps are. Many project customers come to the table thinking they have all the project requirements laid out. That is almost never the case. In fact, sometimes, they don’t even understand the real need or project scope. They may only be coming to the table with a symptom of the real project, problem, or need. It’s up to the project delivery team to dig deeper and make sure that you will be delivering what they and their end-users really want and need.
Is our senior management up to speed and prepared to assist if needed?
It’s important to have some higher-ups in your organization on board with the project and ready to assist with funding, needed resources, knocking down roadblocks, making key decisions, etc. If senior management isn’t standing behind your project, then it could be headed toward failure before it even starts.
Is the budget on both sides fully in place?
Is the money there to get started? The delivery side of the project likely needs some funding, and the customer side definitely needs funding for the project to pay off. They may be an external customer or even an internal customer if your individual units within the organization are set up as profit centers. I worked as the Project Lead for all web projects of a large Fortune 500 engineering and aviation firm, and we charged out, at the time, to our internal business unit customers at $75 per hour. All our projects were internal, but those internal clients had to have funding in place before the project began.
What will the handoff process look like?
When the project rolls out, what will that handoff look like? Will there be more end-user training? A lessons learned session? Some period of ongoing delivery team support for the new solution, and if so, then for how long? A week, a month, a year? And how will that be paid for?
Are lessons learned planned for?
Lessons learned sessions are important but rarely happen. Why? Often it’s because once the project work is done and the rollout happens, most resources are moving on to other projects, so it’s hard to get back together as a group due to new commitments. I find it’s best to schedule lessons learned sessions throughout the project when key deliverables are scheduled; that way, we can learn and improve on the current project, not just the next one.
How will status meetings be facilitated, and how often?
Project status meetings should happen weekly and involve all key stakeholders, a few members of the customer side of the project, and the entire project delivery team. Who will run the meetings? From my experience, that has always been the project manager running the project. It could be the customer leading the discussion, but while their involvement is critical, actual leadership of the project status meetings should be the delivery project manager. Decide that at project kickoff time.
What will the status reports look like?
What does the customer want to see on the weekly status report? What do you want to show them? I usually like to suggest including upcoming tasks, tasks in progress, and tasks just finished as well as some issues, discussion points, budget health, and resource forecast. What do you or your customer want to see? Kickoff is the time to discuss that.
What will testing look like?
The customer needs to perform their own user acceptance testing (UAT). The delivery team also needs to test but cannot perform the actual UAT for the customer – that would be a big conflict of interest. The delivery team can help with testing scenarios and use cases but not do the work for the project client. This expectation should be discussed at project kickoff time.
What about cybersecurity?
It is my belief that we are at a point where every project needs at least some cybersecurity presence. That may only be during risk identification, but for big projects involving sensitive data, then you need heavy cybersecurity involvement throughout the engagement.
Summary/call for input
Yes, it takes a lot to properly kick off a project and get everything off on the right foot with all participants on the same page. So a well-planned project kickoff is not nice to have – it is a must. What are your thoughts? What would you add to this list?
About OnePlan
OnePlan Solutions is a trusted global provider of digital transformation services and solutions, with expertise in portfolios of products, services, and projects. OnePlan is your “one-stop-shop” for business agility transformation in portfolio management with implementation services, education and training, customer support and advisory services. We strive to maximize your business outcomes and to create the shortest path to value.In 2019 and 2020,
OnePlan was awarded the Global Microsoft Project and Portfolio Management Partner of the Year award and finalist demonstrating breakthrough customer impact and solution innovation.
Try OnePlan Today
About the Author
Brad Egeland is a Business Solution Designer and IT/PM consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Creative Design, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He was named the “#1 Provider of Project Management Content in the World” and his blog has been recognized as the “#1 Project Management Blog to Follow.” Brad is married, a father of 11, and living in sunny Las Vegas, NV. Visit Brad’s site at https://www.bradegeland.com/.