As you climb the IT Project Management career ladder you may find that your experience and seniority brings you benefits that you didn’t enjoy back at the start … Rank has its privileges after all. However, could it also have its problems?
In my experience, there are numerous instances where a senior manager’s greater experience has got in the way of them actually listening to their team’s instincts or concerns and as a result, sometimes, problems can arise. When teams feel inhibited about challenging senior managers these problems can quickly multiply and can cost organisations in terms of project outcomes.
It can be a hard thing for many to come to terms with.
When Forbes and Payscale.com compiled the 10 highest paying flexible jobs, senior IT Project Managers came top of the list. With the big bucks comes the huge responsibility and high expectation, but that doesn’t mean you should be expected to or even expect yourself to shoulder all of the burden.
Refreshingly, I was working with a Project team recently where a potential project ‘disaster’ was spotted and averted by the alertness of a relatively junior member of the team.
What actually happened in this specific case is really just a subplot to what happens day in, day out within this organisation and its culture. It’s that culture that this post is about!
At this firm – when it comes to hitting the button to flag up potential failure – superiority, rank, years of experience and certificates on the wall all go out of the window. You could be the tea boy – if you think that you have spotted a glitch or a problem you have as much right as the most Senior Project Leader to shout.
As a result, fewer deadlines are missed, fewer budgets are blown, fewer potential problems become real ones AND they are convinced it’s down to their culture of openness and in the case of an emergency a lack of deference to seniority.
When pushed to explain from where the inspiration for such a culture comes the team is infinitely divided – hardly two team members say the same thing and this is really interesting too.
When new members join the Project team they are tasked with proving the hypothesis behind the culture. They are invited to go away and find examples of where a culture like this works.
“When we, as individuals, irrespective of position, have the courage to say when something isn’t right and the humility to receive such comments in the spirit of our constant drive for better. When we have the awareness to not walk on by a problem and assume someone else will pick it up. That’s when we win as a team. There’s no “i” in “team” but there is a U in “sUccess”.”
By digesting the culture and then having to understand it sufficiently to find a match for it elsewhere the project team have found that everyone hits the ground on day one totally bought into it. If they spot something wrong on that first day they have no hesitation in raising their head above the parapet!
Subsequently, the team have come back with many examples of other organisations living and breathing this kind of culture.
From the Toyota Production System where any employee who spots an error or is experiencing a problem pulls on a cord that stops production – and senior managers come to assess the problem and help.
To NASA’s PACE (Probe, Alert, Challenge, Emergency action) protocols that have taken rank out of problem reporting so that less senior crew members have no qualms challenging established mission commanders.
Two very different organisations – one making cars the other sending rockets into space – with common cultures of openness.
Another team member cited United Airlines Flight 173.
The lessons of Flight 173 changed global communication and lines of reporting not just within aviation but across many industries and as they are as pertinent to IT Project Management, it is worth remembering the story.
It was just after Christmas, 1978, a DC-8 with almost 200 people on board crashed in Oregon.
Reading the transcripts of communications between the crew in the minutes before the disaster is chilling and the investigation into United Airlines Flight 173 revealed that showing too much deference to the captain and his or her decisions in an emergency situation actually made a bad situation much worse.
Flight 173 had been coming into land when issues with the landing gear were detected, it hadn’t sounded right – more of a thud than a click – and the light that tells the pilot that the wheels are down and locked hadn’t lit up. The pilot informed the tower, requested additional time and was diverted into a holding pattern.
It was around 5.10pm. Over 30 minutes later the plane was still circling and the engineer alerted the captain to a new more urgent problem. Fuel. It was running low. The captain, however, seemed fixated on the original problem of the wheels.
Although the engineer made more ‘polite’ attempts to alert his captain to the dwindling reserves, just over an hour after the initial communication about the wheels, Flight 173 issued a ‘May Day’. The plane had run out of fuel, too far from any land strip to make a safe landing and as the engines flamed out the DC-8 crashed into suburban Portland.
The landing gear, incidentally, was down and ready for a safe landing.
In the report into the crash, amongst other things, assertiveness training for cabin crew and training for pilots on “the merits of parcipitative management” were recommended.
It’s a dramatic and tragic example but it serves as a reminder that, in the heat of the moment, ownership of an issue should be a shared responsibility – seniority does not give you exclusivity on solutions.
Furthermore, it demonstrates the importance of speaking up, whatever your position, if you sense something is wrong.
As that mission statement declares, “When we, as individuals, irrespective of position, have the courage to say when something isn’t right and the humility to receive such comments in the spirit of our constant drive for better. When we have the awareness to not walk on by a problem and assume someone else will pick it up. That’s when we win as a team.”
Contact us to learn more about how Stoneseed’s Project Management as a Service can give you access to project management staff, resources and tools at a flexible and predictable cost via a fully structured managed service.
Find out more about Project Management as a Service from Stoneseed
