77 Comments
When we are assigned a new project there are plenty of things to do, right? First, that frantic wave comes over you as you consider the work that is already on your plate and you think about how you are going to manage to insert this new project assignment into the workload that you are already carrying. Then you start to think about the usual processes you go through to start a project like gathering as much info about the project and customer as you can, how and when you’re going to kick off the project and what your project team will need to look like in terms of skill set and experience.
Yes, we all have our thought processes that we go through and some are our own processes from experience, some are mandated by the policies of the organization we work for, and others are mandated by the projects themselves. What I want to discuss are three things that have come up for me after leading many of these engagements that may be a bit off the beaten path. These are concepts to consider that are a bit outside the norm of what you might usually be planning as you prepare to kickoff a new project with a client.
My three are:
Kick it off at your site. I know it’s popular to kick off a project at the site of the customer. In fact it’s standard. But if you are hosting any part of a technical solution at your location and any sensitive customer data will be residing at your site – on your servers – hosting the formal kickoff at your location will give you a chance to ‘wow’ your customers with a little security dog and pony show. Show them your server room, have your security team discuss security and performance issues with your new project client and answer any questions they may have. It’s a great chance to put their mind at ease very early in the project.
Discuss lessons learned at the beginning…seriously. Usually we do lessons learned at the end – if we do it at all. And I’ve suggested that we should do lessons learned throughout the engagement – after each phase or a major deliverable – so that we can take what we’ve learned and apply to the next phases of the current project, not just the next project. But what about discussing lessons learned from other projects at the outset with the customer – possibly as part of a risk planning session? Or even as part of the formal kickoff or possibly even earlier than that. That will give each side a chance to discuss past issues on other projects with other clients and proactively apply what has been learned to this project during the planning phase.
Give the client some change order stats. You should always discuss your change control process for the project with the customer. Changes to requirements happen and you’re going to be managing scope. But give the client some stats from past projects. If most of the projects you manage have resulted in 4.7 change requests on average that have extended the project timeline by an average of 27 days and increased the project budget on average by $89,500 then share that with the client. It will give them something to go by…something to expect. And at the very least it will put both sides on alert to do a better job truly defining requirements thoroughly and as completely and in as much detail as possible. The cheapest route is always to get it right the first time.