I've already written about project portfolio management (PPM) twice this week, so I was hugely interested to see a thoughtful post touching on this topic by the always-smart Peter Kretzman on his CTO/CIO Perspectives blog.
At first, it sounds like Kretzman is advocating for PPM. He discusses the difficulty of juggling goals and coping with diverse timelines and delays for multiple projects, the bane of almost any CIO's professional life. He writes:
... The most common and glaring problem I see in companies with IT in crisis relates to an unfortunate tendency to estimate and commence projects one by one, with little thought to resource contention issues. That approach almost always leads to chronic overcommitment and late delivery.
But hold on. Kretzman goes on to say that PPM might not be the right answer for every organization. Companies considering PPM must first evaluate their their budgets, their organizational politics, and the maturity of their overall software development lifecycle process. Not to mention, writes Kretzman, "the level of your desire/appetite for attaching a degree of rigor to what is by nature an ever-swirling hodgepodge of resources, tasks, projects, deadlines, dependencies, delays, resets."
Check. Adopting PPM without first carefully assessing how it will change existing business processes is one of three PPM mistakes I wrote about earlier today.
Kretzman lists five possible project management solutions, helpfully pointing out pros and cons for each. The first "solution," which he calls seat of the pants and defines as assigning work when people seem to have some available cycles, isn't really a solution at all. As he writes, it doesn't scale across multiple projects and is unreliable. (Props to Kretzman for using "unreliable" rather than "stupid" to describe this approach.)
Large packages like CA's Clarity, the fifth solution on Kretzman's list, offer the highest level of functionality and most complete integration capabilities. But they also demand lots of dollar, time and other resources, up-front and on an ongoing basis. So companies may want to consider the three solutions in between those two approaches: "approximating" spreadsheets, installed software packages like Microsoft Project and Web-based products like Zoho Projects. In fact, companies will likely find themselves using different approaches as their budgets, resources and process capabilities change. As Kretzman says, there's no one right approach.
Kretzman provides a sample of an approximating spreadsheet, a solution that has served him well in small IT organizations (which he defines as fewer than 100 people). He writes:
Once you wrap your brain around it being just an approximation tool, it gets you 80-90 percent of the way there without having to devote a large portion of your staff's time to the constant and intense administrivia often necessitated by one of the bigger project management packages.
OK, I love the word "administrivia" and intend to start using it frequently. And I think Kretzman's bigger point makes a whole lot of sense. Project management tools won't improve project management practices -- and may actually make them worse -- if staff must spend the bulk of their time ministering to software.
Simpler is often better. For further proof, see my post from 2007 in which I share a quick and easy approach to ERP advocated by EvolvingExcellence blogger Keith Meyer. Like Kretzman's approximating spreadsheet, it won't work for every organization. But it will work for some. And it's far less complex and costly (hundreds of thousands of dollars less) than traditional ERP systems. A comment on Meyer's post, from someone who'd tried his system, summed it up: "Life really can be that simple."