I'm not a success without the people on my team! Flat and simple - if they aren't succeeding, then I'm failing. As a leader inside the organization, it's one of my responsibilities to look out for the needs of my team and find ways to make them successful. I can't guarantee them success every time, but I need to find ways for them to succeed more than they fail and within their failure, I need to recognize that I own some of that failure.
I've seen people that have been great contributors on the team suddenly put themselves in a position where they look like they are going to hit the wall. I've had to step in-front of them and prevent the smash up that is about to occur. Sometimes these discussions can be difficult, because they don't want to admit that they are about to fail. Sometimes there is a look of pure relief on their face when someone steps in and says - hey, I'm here to help.
One of the first projects I worked on after becoming a manager was a fairly mundane project needed within the organization - there were several pieces of the software being developed and one of the pieces was being held up because there was nobody else to work the issue. I made the decision that I would jump in and work the issue myself. At this point, my boss asked me why I was working on the code. I explained to him my logic and he began to ask questions:
- If you're working on the code - who's going to keep track of all the pieces that are moving within this effort and make sure overall we're on target?
- If you're working on the code - who are your engineers going to escalate the issue to when there's a problem and how will you manage those issues?
- If you're working on the code - who's going to keep myself and the rest of that management team aware of the status, issues, risks and plans?
There were several other questions - but you get the general sense of the conversation, I was young and eager and for every question he had, I had an answer, me! My manager made it clear to me that this was not the right answer and that I was going to end up hitting the wall. I assured him, that I would be able to handle all of it and went on my merry way.
Soon, I began to trip up on myself - at first it was missing a status report here and there, not escalating an issue that needed to be escalated. Then the impacts grew - I wasn't paying attention to all of the different moving parts and coordinating the delivery. I hit the wall. My boss looked me in the eye and asked me what I was going to do to clean it up. I had failed! Luckily, he reached out and helped clean up the mess and get the project back on track. But what he taught me happened after all the pieces had been put back together and the project was again running forward. He sat me down, told me that this time he had allowed me to fail and had helped me out so that I could learn what not to do going forward! The next time this happened, if I let it happen, I would need to clean up the mess by myself.
Where to start? First I learned as a manager, it's tough to be the one in the details and still be the one coordinating everything else that needs to be done. Two, I learned that sometimes it's alright to let people fail. Three, I learned that when somebody does fail, you have to be there to pick them up and help them get back on track - give them the ability to learn.
Now in some instances - the failures begin to outweigh the successes and you come to the moment of truth. Is there a way that I can make this person successful, or have they proven that they are incapable of performing within the role that they've been hired for - a difficult decision.
As leaders - either formal supervisors/managers or informal project managers - it's not enough just to do the tactical parts of the job. It's essential that we work work with the people we touch in the organization and help lift them up. Only if we truly give them the tools and skills they need to perform their role and prepare them for more difficult responsibilities in their future, will we reap the rewards and succeed within our own role.
If you'd like more information on my background: LinkedIn Profile
How many of us are running effective project meetings? I know this sounds trivial, but I’m serious. Think about how long your project meetings are and what you’re accomplishing – the decisions you’re making, the issues you’re addressing and the mitigation plans that are being discussed. Does the value of what you’re producing in these meetings exceed the combined hourly rate of the participants in the meeting?
First off – what’s the purpose of your meetings? Are you meeting to regurgitate status information that everyone knows? Are you meeting to capture the details of actual work activity? If so, then you’re meeting for the wrong reasons. In my humble opinion, standard status information should be collected and discussed prior to the meeting – through informal walkabouts, emails, instant messaging and/or phone calls. If you’re using your status meeting to gather this information – you’re boring the participants of the meeting. What you should be focused on are the exceptions:
- What were you planning/hoping to accomplish that you couldn’t accomplish? Why?
- What roadblocks have you encountered? Are there options for a mitigation plan?
- Based on what you know now, are there any new risks that need to be identified?
- Based on what you know now, are there any obstacles to hitting our key milestone dates? If so, are there options that would allow us to still hit the milestone dates?
Hopefully, as the Project Manager, you’ve already identified the above items through your informal meetings. What you really need the Team Meeting for is to ensure that this information is being shared and communicated with the larger team. And, most importantly, the information should be evaluated by the entire team to ensure that the best mitigation plans are formulated and executed.
Nobody wants to sit in a meeting for an hour to go around the room and hear that “everything is fine”. It’s your job as Project Manager to dig into these statements and validate, “Hey, that’s nice to hear that everything is fine and on-track. Are you finding any issues in the implementation that differ with the Project Level Designs or Details Designs? Do we need to clarify any of the information that was passed in to the Development Team on the functionality your developing?” Often, that will open doors for individual project members to highlight issues and provide you with feedback that can be used by the entire team. Most people aren’t comfortable bringing up topics that they feel are negative in a group setting – it’s up to you as Project Manager to dig deeper and pull that information out. Building those relationships in the informal meetings will go a long way towards getting people to open up in the Team Meetings.
I’ve also had several Project Managers tell me that they meet because best practices say that they should meet as a team once a week or bi-weekly. Some Project Managers have told me that meet 2-3 times every week – to stay on top of things. Seriously – a full team meeting 2-3 times a week? That seems like overkill – there may be specific points within a very complex project where that is the case, but, by and large, if you’re needing that meeting frequency on every project you run, something is probably wrong.
I understand daily standups – these are quick 15 minute meetings with teams or sub-teams involved in the project. Most times these are structured around covering subjects that promote team focus – what was accomplished during the previous day, what is planned to be accomplished today and what is causing delays. The team can then collectively address issues that are causing delays. I view these as separate from the full Project Team Meeting. The full Project Team Meeting crosses organizational silos – involving development, infrastructure, quality assurance, architects, finance, marketing, sales, operational teams and others throughout the organization. The daily standup meetings are more team focused – and the information discussed more granular.
Back to the issue at hand – how often you’re holding Project Team Meetings. I actually don’t mind, in fact I encourage, Project Managers to schedule weekly Project Team Meetings. The difference – I also tell them to cancel the meeting if there isn’t enough value that will be derived from holding the meeting.
As the Project Manager, I expect them to know if there are issues through the informal contacts that they have with the project team. If the project is at a state where things are relatively smooth and there are no outstanding issues where mitigation plans need to be developed or where there is not a milestone that is driving communication between teams – then don’t meet! It’s that simple. The Project Manager should be empowered to understand the focus and purpose of the larger Project Team Meeting and make decisions on when it is useful to hold a meeting or through informal communication with the overall team – cancel a meeting.
What’s the purpose of your meetings and are you driving enough value to justify the cost?
Tags: SDLC, Lifecycle, Project Management, Project, Management, Meetings, Status, Team, Development
If you'd like more information on my background: LinkedIn Profile
