A Lesson Learned
Sometimes you need to fess up to the fact that nothing is perfect… even yourself. We all gain experience through trial and error and sometimes sharing this experience means that you need to document things you learn the hard way. This post is one such instance where I share some lessons learned on transitioning into an existing project team.
We recently joined an existing project team in the commercial development sector with a request from the client to bring some project management principles to the project to ensure it was executed on time and budget. With this mandate in hand, we held a structured kick-off, followed by a period of detailed planning, and we converted the existing weekly meeting to a much more structured routine of tracking progress against the schedule. It was a standard tool set and routine structure that we had applied in the industrial sector, which we were more accustomed to. The result was not what we expected, though in retrospect it shouldn’t have been much of a surprise.
This abrupt change in process was not well received. It created a divisive atmosphere within the team for a period of time that led to some healthy storming. Though this was unpleasant at the time, this conflict was ultimately a good thing since it led to the team gelling into a cohesive unit. Also, the weekly meeting evolved into a collaborative routine that maintained accountability, but was more appropriate for this particular team and the nature of this particular project.
While it may be mildly interesting to hear a story about a team in conflict, it is most important to translate situations like these into some tangible takeaways. It is common for project managers to transition on a project for a variety of reasons and I have outlined below some points of consideration when you are joining a project already under way as a project manager:
Understand the lay of the land. It is important to get a good understanding of the project scope, the complexity of the project, as well as what routines and tools are in place. It is also important to understand the individuals on project team, including their work styles.
If it ain’t broke, don’t fix it. After understanding the mechanics of how the project is operating, as well as the project team members, you must decide if everything should stay as is, or if changes are needed. This is where your own knowledge and experience comes into play, however don’t forget to ask the existing team what they think since this is a very important source of information. If something is working, then resist the urge to change it just to suit the way you are used to seeing it. If you do need to change something, the transition will be much smoother if you get buy-in from the team on the need for the change and asking for their input is a great step toward achieving that buy-in.
Keep it lean. When implementing changes, it may be better to Introduce changes in a stepwise manner rather than all at once, if the project timeline can accommodate this approach. Think of it as a mini lean loop where you try something and monitor its effectiveness and then adapt from there. Measuring this effectiveness can be based on project performance and by simply asking the team what they think of the new process or routine.
Don’t be afraid of conflict. While it is unpleasant, accept the fact that some constructive conflict is a necessary step to achieving the best results. Just make sure the conflict stays professional and not personal.
In summary, as I was reminded the hard way, when joining a project that is already under way it is important as a project manager that you do an adequate assessment of the nature of the project, the team and the culture of the project before implementing too many changes to quickly. Moulding the processes, routines and tools to those that you are used to can give you a sense of comfort, however you need be sure that you aren't trying to fix problems that don’t exist, since this incremental comfort may not be worth the upheaval it causes within the project team.