Eight Critical Meetings for Large Projects

25.06.2011 0


I don’t think anyone likes too many meetings.  There’s lots of information out there on how to run them more effectively, some satire, and I’ve often thought meetings just make people look busier.  What are we going to accomplish by having a meeting where we just update around the table?  I try to avoid these like the plague.

However, there are huge benefits from having meetings and I do think that there are a minimum of eight significant meetings that have to happen when you’re running complex projects with external deliverables.  Face time is very important at critical points in the project life cycle.


Contract Meeting:

Dotting the i’s and crossing the t’s.  Whether this is a meeting with the customer or with the vendor that is supplying some of the goods or services to finish the project, this meeting ensures that milestones, quantities, responsibilities and the scope of the project are clearly defined and agreed to by all parties.

Project Kick Off Meeting:

I like to do these every time a new phase for the project is initiated. This sets the tone for the work to come and allows the team an opportunity to ask the questions they need before considering, performing or planning work.


Requirements Review Meeting:

This can set up the Statement of Work and is done early in the project.  Capturing requirements using formal interviews with all stake holders, focus groups, workshops etc. just gets you to the raw elements of what must be delivered.  But in the end, a formal meeting where the collected requirements are reviewed with the sponsor, customer, and team leads and then agreed to and signed off is a great way to ensure you’ll build what is needed.

Critical Design Review:

Now we’re committed! The design of what will be built to meet the accepted criteria is reviewed and agreed to by the end customer.  By having this meeting, managing expectation becomes so much easier and allows the team to commit to work packages, risk is reduced, and controlling scope is a matter of reviewing changes against the accepted design and the supporting requirements.

Design or Code Freeze:

Agreement at this meeting freezes design or coding and allows you to either go to manufacturing or finish software compiling, testing and release.
No further design changes on the last product iteration will be considered without altering scope or schedule.

Transition Readiness Review: This meeting occurs before implementation and evaluates the success of transitioning to a new product system or service. The major stakeholders that will be involved in managing changes, or performing implementation work must sign-off on planning, risk management tasks, and the resources needed for the transition.

Budget Review Meeting:

On large projects, periodic budget review meetings with the steering committee are always necessary. I think these should always be done at the end and start of a new phase of the project.  At a minimum these should be performed every quarter as part of the exercises needed to maintain project control.

Post Project Review:

So how did the project go and what important lessons can the organization learn from?  Lessons captured at this meeting along with other documentation can improve the performance for other projects.  Results of the meeting can form the templates for future risk analysis, estimating, methods, and procedures.

I deliberately haven’t written about progress/status, or risk review meetings.  These occur as part of doing the work and are necessary to move the project forward. They are import for communicating and learning about project performance but they do not have such singular impacts to the success of the project as the meetings above.