What's your pain level? What can you not get a handle on that makes you think you need PPM? If you have no issues with competing needs and scant resources, stop here. You don't need a PPM tool. And me and about 150,000 other IT managers want your job, so watch your back, buddy.

If you do have problems, it's important to name your pain. Typical issues include problems with scheduling (overburdening teams with multiple competing projects); having no visibility into what projects are being worked on (are we working on the right projects?); a need to reduce project expenditures without a rational methodology to do so; and a desire to increase quality of outcomes (and avoid outright failures) by correctly sizing work capacity to project queue.

By identifying the top 3 to 5 objectives or pain points, you'll be well positioned for a reasonably sized and focused implementation. That is to say, one that has an actual chance of success.

Can existing systems accomplish the mission? Ok, so you need PPM. You still might not need a dedicated tool. Ask yourself whether existing systems could be tweaked or used differently. For example, could a work order system be re-configured to accomplish the objective? Frankly, in simple scenarios, I've seen Excel used pretty effectively; if you've got more complex systems, think about maximizing them.

Even if you take the plunge and invest in new tools, be aware of ways you can avoid duplication of work. Integration with other systems, while not a deal-breaker for a pilot program, will be necessary for a sustained effort.

What capacity for change does your organization have? Do you have the bandwidth and patience for a pilot?

PPM is a lot like ERP - it's going to have a lot of tentacles in a lot of places at your organization. Yes, PPM can certainly start in IT, but ultimately, it's going to have to have acceptance by line departments and divisions if you're going to get the bang for your buck.

If you accept the notion that there are no IT projects, just business projects with technology components (pretty much a good IT governance maxim), then you also accept the notion that all IT projects typically require resources from line-of-business. Therefore, in addition to IT, you need to assess your line of businesses for their capacity for change.

One practice that fits this notion: PPM vendors generally won't give you a test drive - they claim that folks who just dabble with their tools are ultimately unsuccessful, and that only folks who invest their time in an assessment with their sales consultants will end up adopting.

I'm not sure that I totally buy that. I agree that organizations need significant self-knowledge to be successful in the process & tools that constitute a PPM initiative. To expand the ERP analogy, it would be insane to simply implement complex software without a somewhat informed approach. I just think that you don't necessarily need an external vendor involved to approach the level of PPM maturity that you need for a successful tool implementation. I do, however, agree with the notion that you need commitment for change before you implement a PPM tool.