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:

1. Business: The project is taking too long
2. PM: How about cutting some of the features to pull the release date in?
3. Business: No, those are essential
4. 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?
5. 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

If you were at the Summit, what were your highlights?

Related stories:
6 Lessons on Being a Project Manager
3 Strategies for Dropping Dead Rats: How to Take Away Product Features
Unreasonable Estimates and Improbably Goals