Often in the world of project management, even the most experienced project managers occasionally get caught with their “pants down”. How does that happen to even the best leaders? Usually it involves people and their lack of communication within and beyond the team.
So how does a project manager minimize the odds of getting surprised? Well surprises will always occur, but finding about them quickly and addressing their root causes efficiently is the behavior that is needed. The key description heard throughout the industry is “communicate”. We (ScrumMasters / Project Managers) hear it all the time: “Must be an excellent communicator…” “Be an Information Radiator”, “Effective at delivering the right message”. As one study conducted by the South Illinois University Edwardsville states, communication is the top skill to possess: http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1491&context=amcis2013
Well, communication will help manage those quite team members that may be hiding a potential land mine, but how does that communication get delivered to top leaders that don’t speak with the ScrumMaster? My solution involves Leading Indicators.
This is a recommendation to test out the measuring of new metrics to help determine if a project is heading the wrong way before the standard metrics of schedule, budget, scope, value and quality hit into the red status.
Consider the following leading indicators:
- Happiness (team level)
- Code check in Ratings
- Staff changes
- Average overtime worked
- Active Issues
- Active Risks (see my article on Risk Burn Down)
These metrics can really help identify if your project is heading in the wrong direction. My thoughts are that the process of collecting these metrics brings out the true health of the project. Leave “no person unturned” and ensure your entire team has their input or have a delegate obtain that input for larger delivery teams.
From my experience of collecting these metrics, make sure the process is as automated as possible and that it doesn’t burden the delivery teams too much to obtain. I find the cadence of doing once during the middle of a sprint usually works best.
Also, recommend normalizing the results so that impacts are equally noticeable for each metric. For instance, if you are measuring happiness, set to zero if everyone is very happy and scale up if the team is very unhappy. If you are measuring overtime, scale at a similar level to show the impact. This is where the subjectivity comes in and would recommend having agreement by the project sponsor on how the scales should be measured. For instance, should losing a key team member be the same weight as an unhappy team? Should working 10 hours a week have the same impact as an average poor code check-in ratings?
When experimenting with new ways to improve communication as reduce the risk of having an ugly project, leading indicators may yield beneficial results. However, every project is unique and you should determine by experience or by trial whether leading indicators will help improve your delivery quality.