An important part of being a leader is getting projects done. Projects should have a business impact, complete on time, meet customer needs, and align with an organization’s goals. As a leader, we can track the progress of projects throughout our organization. Some ways to do this are: measure at various levels of your organization, allow for peer review of the work, hold teams accountable, and be open to bad news.
Without measuring at all levels of the organization, you don’t get the whole story. Everyone has a unique perspective. Relying on data just from direct reports will provide just their perspective. However, it won’t provide the perspective of the other people in the organization that are working on the project. We need ways to gather the perspective of as many people working on the project as we can.
So how do we get the perspectives of more people involved in a project? Things that most teams already do include project planning. This means you have defined the set of deliverables required for the project with committed dates for when they will be delivered. Track these in regular checkpoints, monthly or quarterly. I like detailed plans that include who will be doing the work, the area/feature breakdown, person-days per feature, and the manager responsible for each area or feature. For key areas or features, do a formal review of them. Invite the leaders of the teams that are depending on the work to participate in these reviews as they will have valuable input.
Meet with the key individual contributors for each area/feature. These can be one on one meetings or a meeting with all individuals working. Ask open-ended questions. My favorites are: “What should we continue doing on the project?” “What should we start doing on the project?” “What should we stop doing on the project?”. It’s important to be open to all feedback — both positive and negative.
Determine which specific metrics to track. Each area or feature will need some specific measurements. Walkthrough what these should be. How will you measure them? How will you verify these measurements? Make sure it’s written down and agreed to by everyone involved. Don’t rely on one metric to determine success.
To illustrate one organization, I assumed management of, used code coverage as the only metric used. I noticed one team was consistently at 100% code coverage. I thought this is great; I wanted to figure out how they do it and spread it to the whole team. When I did a deep dive, it turned out none of their tests validated results, they just made calls to the product, reached 100% code coverage and they were done. They didn’t see how this wasn’t helping to create a high-quality product. They saw the metric as the end goal. This is an example why just looking at metrics isn’t enough.
Peer review across an organization helps measure success, by sharing knowledge across the organization, connecting people across the organization, driving common practices, and measuring how the overall project is doing. It does the later by allowing the teams that are working together to review each other’s work. This helps to ensure what the teams are doing are what the teams that are depending on it need. It also provides a more objective view of the work being done by people who aren’t directly involved.
One way to instill the peer review philosophy is to require sign-offs from teams. If a team is depending on work from another team have them sign-off on the project plan, y of validation tests that should be passing before the feature can be marked as complete. This will drive cooperation between teams. They must work together to get the feature ready for sign-off.
When services (or products) are created without a clear understanding of what is needed, it creates unnecessary extra work. Recently in one organization, I was a part of this peer review, and sign-off wasn’t done. Services would be created without a clear understanding of what the client teams needed. This caused the team to have to create a second service to cache data from the first service so it would meet the client team’s performance requirements. It was a lot of extra work because the teams didn’t review the work early in the planning cycle.
Holding teams accountable throughout the project is vital. Too often, teams miss their first milestone without being held accountable. They continue to miss milestone after milestone with the team and the organization’s leadership, believing they will eventually get the project on track. It is rare that teams that start by missing dates will correct it unless the leadership holds them accountable and helps them manage the project better.
Organizations that don’t deliver won’t last long. I was in one organization where they said in review meetings, “It’s OK to miss dates.”. That team missed date after date. Eventually, the entire organization got broken up and folded into other organizations that did meet deadlines.
For areas and projects that miss milestones dates, communicate directly that this not acceptable. Help them determine why they missed dates, and what changes they can make to hit the next milestone’s date. More frequent follow-ups with the teams that have missed project dates and goals are essential to keep the project on track. There is also an aspect for self-reflection here. As the leader, ask — what did I miss during the previous reviews that I didn’t see that this area wasn’t meeting its goals? What can I do to help? How as the leader will I improve to make sure I’m more in tune with this team’s status?
Make sure people at all levels in the organization feel comfortable coming to you when an area of the project isn’t doing well. It’s important to hold people accountable. However, it’s also important that they feel comfortable with bringing up issues. This is the balance we need to strike as leaders. Make it clear what the expectations of teams and their leaders are. Provide them the support they need and help them meet these expectations. Be the helpful leader that insists on results and will coach people and teams achieve those results.
コメント