This blog post was originally published here.

I recently worked on a project that reminded me of Jim Collins' book Good to Great: Why Some Companies Make the Leap... and Others Don't , particularly the part about getting the the right people "on the bus":

First Who, Then What: Get the right people on the bus, then figure out where to go. Finding the right people and trying them out in different positions.

Mr. Collins is referring to startups, but I think it also applies in the context of the implementation of an Identity Management solution (or really any large scale technical implementation).

Now, this quote doesn't exactly align with a project in the fact that first you find the people, then find their positions. For an implementation I would think you would generally know the role that each of the players will play. It may change a bit as you move forward, so you will need to be flexible. This post is more around the pitfalls of either having the wrong people on the bus to start with, or missing some of the key people that should be on-board.

I've run into this on several projects, typically from the customer side. This usually leads to the following issues:

1. Miscommunication: The customer does not understand what they are being told. This is partially the fault of the vendor performing the implementation for not making sure whether or not the customer fully understands. In the vendors defense, there should be a certain expectation upon the customer for understanding basic technical concepts within the implementation. This becomes particularly dangerous when you then have the customer project team communicating with their internal technical people.
2. Poor decision making: The customer may not understand the full consequences of decisions they are making. This is caused by either not fully understanding their own processes, not understanding their own systems, or both.
3. Extending Timelines: There is now more onus on the vendor to drive the project and direct the customer in their decision making. This takes more time for both project team meetings and for the customer to group together to make their own internal decisions.

Given these issues, how do you persuade the customer to get the right people onto the project, or how do you manage a customer if they can't do it? Here are some of my suggestions:

1. Address the situation with the Customer Project Manager: Simply mention that it would help to have the expertise of certain people on the team on a regular basis. It may not always be possible for the PM to accomplish this, so it leads to the second suggestion...
2. Elevate to the Project Sponsor: If anyone has the ability to free up other peoples' schedules, it is typically the project sponsor. Escalate to your own sponsor and have them have a conversation with their counterpart at the customer.
3. Participate in ALL meetings:  This means (delicately) pushing your way into meetings that would normally be reserved as internal for the customer.  If you can join these calls, then you minimize the risk of something be miscommunicated internally (and maybe you can convince one of the other parties to join the project team!).  This would also require adjusting timelines and/or burn rates, as there will be less time to do work, and more time spent in meetings.
4. Note it as a risk and adjust timelines accordingly: This is clearly not the best solution. It doesn't solve the issue, it simply recognizes that it exists. This can also be very tricky to pull off. You go from saying "I think it would be very helpful if Sue could join the project team, because she has expertise in this area" to "I don't think you have the right people on your team, and therefore we don't think you can do a competent job, so we're going to adjust our project plan." This is quite a dance for a vendor to perform.