The question is how you go about it. One answer, and a good one at that, is Scrum.
Scrum isn't project management
In case you've been doing your best to ignore everything related to agile, Scrum appears to be the most widely adopted agile variant -- at the moment. Regardless of whether you've been ignoring it, the most important thing to know is that in spite of what you may have read, Scrum has nothing to do with project management. It isn't a new way to manage projects, an old way to manage projects, a new twist on an old way, or anything like that.
Scrum is a release management methodology. It provides a way to manage the enhancements queue -- no more, no less. It's a good way to manage the enhancements queue, too.
Scrum takes every enhancement request and puts it in a queue, but instead of calling it the enhancements queue, which might confuse those who are easily flummoxed when someone calls something by its long-held, familiar name, it's now known as the "backlog." We should be happy about this, as it's a rare case in which the new name is neither an acronym nor a more polysyllabic, harder-to-pronounce replacement for the old one.
In any event, every proposed change to an application goes into the backlog, listed as a "user story." This is something else to like about Scrum: User stories are the titles of yet-to-be-fleshed-out use cases, and again, the Scrum-vocabulary masters resisted the urge to create an intimidating name for them.
The way Scrum works from here: Someone called the system owner (system "steward" would have been better) decides which user stories are to be worked on in the next "sprint," an unintimidating word once again. A sprint is a short period of time -- usually but not necessarily a month -- that ends with a releasable build. What's especially nice about Scrum is that decisions about what goes into a sprint are actually a collaboration between the system owner and Scrum team -- a collaboration because the system owner defines the priorities, but the team knows how much work it can get done in a month.
No projects, no project portfolio management
Once we've eliminated all IT projects in favor of ongoing release management, there are no projects to evaluate, no master schedule, or any need for project portfolio management.
This doesn't mean the enterprise no longer has priorities, or that it no longer has the means to control how it achieves them. What it means is that instead of implementing priorities through project portfolio management, the organization handles them by deciding how many developers to allocate to each major application in the IT applications portfolio.
Sign up for Computerworld eNewsletters.