Last week, I attended the annual Gartner PPM & IT Governance Summit. The event brought program and portfolio management executives to participate in lectures and catch up on the latest trends in PPM software and soft skills. The special guest keynote speaker this year was Madeleine Albright, who was delightful. But the real meat-and-potatoes of program management thought leadership came from Gartner associates themselves—who brought great content coupled with dynamic speaking skills. Here are my favorite takeaways from the lecture series.
Phase 2 is a lie Andy Kyte, VP & Gartner Fellow was an amazing orator with a charming accent, but the content of his lecture, “Stop Aiming for Successful Projects — Start Aiming for Successful Applications” was the star of the show. He stood up in front of an audience full of project managers and called them out on the “Phase 2″ phenomenon.
As any PM knows, a project’s scope, schedule, and budget make up the Iron Triangle /Triple Constraints. An adjustment to one aspect affects the others—for better or worse. For example: Sales wants the product out faster? Cut features or throw more money at it. Marketing wants more competitive features? Be prepared to extend the deadline and/or hire more people. And so on. Andy correctly identified Scope as the softest piece because of a little trick called Phase 2, which goes like this:
- Business: The project is taking too long
- PM: How about cutting some of the features to pull the release date in?
- Business: No, those are essential
- PM: How about instead of cutting them, we break the release into more than one release? Phase 1 will definitely release on time. The lower-priority, unsexy essential features will come out in a follow-up release, Phase 2. It’s like, totally Agile ‘n stuff. You want to be Agile, right?
- Business: Um, yeah . . . of course we are. And phase 1 will release on time? Good. Make it happen.
Consequently, the Business feels great about their decision and the fact that the project is now “on time” again. Phase 2, however, is likely to get deprioritized because it’s not nearly as sexy as all the other new features that the Business wants by the time Phase 1 comes out. What’s worse, many of the unsexy features pushed to Phase 2 were for maintaining the application and flexibility for future upgrades. The result is that the Business and/or Customer is stuck with a suboptimal application, and Ops is stuck with undue maintenance overhead. That’s all people care about—the crappy application you guys built. But hey, it launched on time, right?
Account for ghost stakeholders
Another insight from Andy Kyte was that the end of any project is really only the end of the beginning of a support cycle for the application you just built. Good PMs gather stakeholder’s requirements and use them to build solid software applications. However, not all your stakeholders even exist yet. The person responsible for maintaining the application in a year? How about the PM responsible for upgrading the product 3 years later? Are these stakeholders’ requirements represented in the plan? Andy went as far as saying to bring empty chairs into every project planning meeting and label them “future maintenance manager”, “upgrade project PM” and so on. This is brilliant and really inspires people to take these non-functional requirements into account to build a solid application.
Sand doesn’t exist
We’ve all heard the prioritization analogy of filling a jar first with big rocks, then pebbles, then sand. So, how should we “fill up” a software or IT engineer’s time? Donna Fitzgerald, Research VP at Gartner,gave her answer to the question. She described the big rocks as projects, and sand as the tiny things that need to be done—small bug fixes, little feature enhancements, overhead tasks, and so on. Some project managers will schedule the big rock projects and expect the sand to get done if the engineer has a few spare moments. However, this almost never happens—nor should it. If a developer gets a small reprieve in the schedule, that “spare time” is much better spent taking a breath and thinking about the big rock project. Refactoring opportunities, missed requirements and code reviews are essential to successful projects. Compare this to the randomization effect of thinking about unrelated pieces of a different puzzle.
Being scary doesn’t mean you’re the bad guy
Tina Nunno, VP & Gartner Fellow, gave a speech about using extreme tactics to get things done in your organization, based on her book, The Wolf in CIO’s Clothing, which I highly recommend. The crux of the speech was that without strong leadership, an organization descends into chaos. It’s the duty of a good leader to use strategies and tactics to not let that happen—be it power, manipulation or warfare. There are “light side” tactics and “dark side” tactics for all of these, which should be used as the situation calls for them. Her example of the best type of leader is the wolf. A wolf is a social animal that is most effective when collaborating with a strong team—and can even be friendly. But, a wolf can bite people’s faces if necessary—unlike a sheep that always runs, or a shark that always kills. Knowing how and when to use the various extreme tactics is the mark of a strong wolf leader.
If you were at the Summit, what were your highlights?