Colin Powell Lesson 7
The commander in the field is always right and the rear echelon is wrong, unless proved otherwise
A software PMO is like battle command. Communications are always coming in from different units; requirements, test, schedule measurements, developers etc.
These Guys Know What's Up - Listen to THEM
Just like in a war situation, a Program Manager PMO lead can be surrounded by a cadre of people who want to give her the best picture because they are concerned about their relationship to her. They all speak the same PMO vocabulary (“risk”, “float”, “CPI”, “baseline”), they all speak about things the same way (“that issue should be handled as a change request”), and they are all using the same tools (“risk register”, “IMP”, “Change Request Log”).
In their own PMO world, they don’t have to worry about learning new tools or learning new languages or understanding how somebody else works. This is especially true now that many PMs get their start from getting a PMP rather than working their way up the software development chain from say, a BA. In other words, it’s highly possible to get a group of PMO SMEs on a software project who have never worked in software development.
This means that the PMO can start to sit comfortably in its own vision of PM reality, pulling in schedule metrics and status’, not really hearing what various groups are saying and perhaps more egregious, dismissing the other group’s snapshots of reality as not true.
Here’s what happens. Inevitably, the programming lead or the requirements lead will come to the PMO with a problem. But the problem will be stated in their language using their terms. Something like:
Requirements Lead: ‘We’ve discovered that use case analysis is going to need fully elaborated data requirements in order to be complete.’
Programmer: ‘We’re having problems with our PII Stig. C&A is not happy with our use of PII’.
I’ve seen PMs draw blanks with these kinds of statements and move on to the next item in the agenda. Or worse, argue that these issues should not impact the schedule, challenging that programer or requirements lead’s vision of reality. And then, months later when the project is completely red, the PM doesn’t understand why.
As Colin Powell has probably learned the hard way, the guy or gal on the front is always right.
To prevent failure, a PM should do three things in this regard. First, know who’s on the front line of your project. Second, learn to speak their language. And third, and most importantly, hear them and believe them.
Know Who is on the Front Lines On a software project, the front line is not your executive sponsor, it’s the users. Ultimately the users will make or break your project. You aren’t warring with them physically, rather you’re in a battle for their hearts and minds. You want them to love and use your application.
Therefore, the front line is anyone who has the responsibility for the application build in their hands. The PMO is not the front line. The front line is not senior management. The front is, at initiation, the project managers who are working with the users to determine scope. While gathering requirements, the front line is the requirements analysts who are deep diving on what the application should look be. During application build, the front line are developers. And during testing, the front line is test.
Speak Their Language Be able to speak to the front line in their language. Understand their tools and understand what they are telling you when they come to the PMO. The software PM needs to bone up on requirements methodology. Open up the BABOK and try to at least understand requirements frameworks. If you don’t understand the various elements of software architecture, sit down with the developers and let them teach you. And if they say something in a meeting you don’t understand, politely ask them for clarification. Whatever you do, don’t get stuck in the fear of looking stupid, it’s ok if you don’t understand everything, and your willingness to get clear is usually appreciated by those on the front lines.
Believe the Front Lines Don’t disregard the front line because they don’t have the same vision as truth as you and because they don’t agree with you. They’re not going to agree with you because they’re in a different reality. And that’s ok. As a PM, you want to hear an alternate vision of the truth. And you want to be able to accept it even though you may have to synthesize their version with yours to get at some middle way of truth. But whatever you do, don’t dismiss or argue it away because you don’t understand it.
Repeat after me 'EVERYTHING'S GREAT EVERYTHING'S GREAT, YOU ARE GETTING VERY SLEEPY"
This is about winning the war. Don’t listen to that PMO SME at headquarters whose saying ‘yeah, everything’s fine, everything’s fine’, because he doesn’t want to look bad. That person will kill your project. It happens all the time. I’ve personally seen this happen in corporate America when former Fannie Mae CEO Frank Raines’ relied on rosy pictures from his direct reports, while the ship was sinking. And even with the new show undercover boss, it’s become clear that there is a significant disconnect between top and bottom.
Don’t become a PMO silo. Know your front lines, and give the front lines the respect they deserve.
Great post Michiko!!!
It has now inspired me to finally sit down and write my next blog post about an idea that I have been ruminating for a while now. The idea is the importance of being a “Blue Collar PM”.
For a while now, I have been thinking about the distinction between two types of PMs. The first type is those who become project managers after they have toiled for years in the trenches paying their dues by doing BA, testing, development and development work. I call this type the “Blue Collar PM”.
They are hand-on PM (does not mean micromanager), like to get their hands dirty, and don’t mind picking up tasks on the project to help their teams to the finish lines. They are part of the team and they are so involved in the project that they know the real status the project at any given time. They see their job as helping their team to the finish lines.
The second type is the Project Managers that I will call the product of the PMO. They never really had to generate any content or helped produce a product but somehow they landed they first job in a PMO office and they eventually become a PM. This type I call the “White Collar PM”. These are the types that make their project team managers fill out weekly status reports and keep a wall between them and the team. They see their job more as process monitors and journalist chronicling the project events and reporting any infractions.
I have always admired and enjoyed working for Blue Collar PMs. Because they themselves are in the front line, blue collar PMs (1) know who is on the Front Lines, (2) speak Their Language, and (3) Believe in them.
Thank you.
Samad,
Exactly right! This is exactly what I’m referring to. Last year one of the BAs on my team said that he didn’t believe I was a project manager when he first met me. His thought was that because I asked him what he was good at, and because I gave him feedback and direction on his requirements document, that I wasn’t a ‘real’ project manager. I think he was quite used to White Collar PMs and experienced some cognitive dissonance when he met me.
I look forward to your post!
Michiko
[...] you with a thoughtful way to coach yourself – something all leaders ne… 2 Tweets Leadership Series Lesson 7: The Front is Always Right OR Don’t be a PM Silo « Preventin… 2 Tweets Take an Imagination-Driven Approach to Management – Management Tip of the [...]