I have been lucky to work in various flavors of project management for 15 years, using methodologies from RUP (if you have to ask, don’t) to the newer fangled techniques of Scrum. I’ve been a boots-on-the-ground project manager and a portfolio manager managing a 100+ million portfolio for a Fortune 1000 company. Throw in some state government program management, and you can say I’ve seen quite a bit.
One of the observations I’ve enjoyed watching in my career is the software development industry’s love/hate relationship with project management.
Before the early-to-mid 2000s, project managers were expected to be the “leaders” of the project, and everything to do with the project went through them — they were the “single throat to choke.” If the project went well, they were highly rewarded — promoting that their projects were always “on-time” and “on-budget” was a huge credibility factor.
They were command-and-control, heavy process and governance (“Need a new form?” “Here’s a form to fill out for one.”) Some project managers loved this, and in some ways this model still works in some industries that need the heavy governance for compliance reasons, or their projects are very cut-and-dry/repetitive with little innovation — ERP implementations, anyone?
About ten years ago, more and more consumer facing application development shops started to realize that speed was important and started to focus on outcomes over “process.” They started to cut waste that impeded delivery (a la Lean Startup). In this new world, small teams started working, kept track of what they were doing together and got stuff out the door to test, learn and iterate. Project management was seen as a huge impediment — “I don’t care about your stinking TPS reports! I need to get work done.”
Small team start-ups, either within an organization or a new fledging company (dare I say .COMs?), started to see success, and off they went. All team members shared tasks/responsibilities usually attributed to project management — “What day is it? What are we doing? Are we done yet? How much have we spent? Oh, we need another developer!?!”
It was during this time that when I told people I worked in project management, I might as well said I was a librarian — someone who’s role had a time and place in an old school mentality, not in this fresh, new world. MS Project Plans might have well been a card catalog — seriously, try to get someone under 30 to spend more than five minutes reading one.
So what is the role of a PMO and/or project manager now in consumer facing product/application development? How has the role evolved? Are project managers all Scrum Masters? If so, do they need to learn rugby? What does project management credibility mean now when there is very little control that a project manager can exert on a team?
What does a PMO Director do to stay relevant and evolve their team to adapt with the changing climate/methodology in their organization? How can we continue to provide value so that we don’t become extinct?
I hope to share my insights and learnings from the last eight years as I’ve lead teams that have transitioned from old school waterfall relicts, to lean, mean, agile fighting machines. In each case, it was a bumpy road, and I had a lot of help along the way.