Technical project management is not just a skill, it's an art.
It is a mix of coordination, communication, strategic and tactical work, experience and a little bit of fortune telling. Additionally, a really good PM knows how to blend various project management methodologies to align to the work.
In the IT world, this ability, to blend methodologies is extremely important — and it’s also rare. Most organizations have shifted to some form or fashion of agile in the IT development project space.
While this approach works well for most developers, it doesn’t necessarily translate well to upper management. Budgets and end dates and scope become difficult to articulate when leaders are used to receiving information in a way that is driven out of the waterfall project management methodology.
There is an inherent conflict created between the development teams and upper management because “they don't get it” (said both sides). Due to this conflict, you'll often see large organizations swing the pendulum back to a waterfall process simply because the reporting meets their needs. Again, more conflict is created in the swing.
So, how do we stop this pendulum swing? One solution: watergile (a term I've been using for the last several years). Simply, watergile allows the PM and the development team to report out against the traditional metrics captured in waterfall (time, cost, profile) but still allows for development to occur in sprints. The trick is that no story points are used. (Sorry, agile purists.) This blended methodology only works if traditional hour estimates are used.
Projects are managed as “fixed budget, variable scope” and metrics, such as budget, schedule and scope, all can be captured and reported against. And, developers still get to operate within the scrum framework, prioritizing work in each sprint.
Watergile takes a skilled PM to get you through the first few projects, but after this methodology is in place and is understood, it's a great blend for both development teams and leadership.