Hi, a group of colleagues and I are in the process of creating a plan of record for next year among a huge amount of competing projects. We want to use the standard 000-999 priority scale but I cannot find any documentation describing what (if any) standards there are around the various thresholds. For example, generically speaking for any business, what constitutes qualification as a 900 or a 999? How about a 700? Saving Changes...
The difference, even between an 800 and a 900 is probably irrelevant, much less between a 567 and a 568.
A silly system.
Before going into any project vs project prioritization exercise, poll the strategic leadership of the organization and have them identify what they see as their top ten. Odds are, if your leadership has anything between its ears, there will be considerable overlap of the lists, making the initial top cut much easier.
Then, identify dependencies between the projects. Obviously, the ones that are needed for others will be needed to be addressed first, giving them priority in time, if not value. You're better off thinking of these as programs rather than as collections of independent projects anyhow. After all, the value comes not from the individual projects but from the collection -- especially of the interdependent ones.
Once these easy rankings are dealt with, you can take your time with the others, ranking them against $ value, linkage to strategic initiatives, tech risk, value risk and other usual characteristics. Once ranked in the form of buckets of projects, you can worry about refining the differences as their launches approach, if necessary. After all, why waste time today trying to differentiate between even an 200 and a 274 when it's likely that the need for one of them will likely disappear by the time you get around to it, or superseded by new needs or opportunities.
The problem with plan of record is that too often they are implemented as planned.
For more on prioritization, check out a short piece here.
Also, let me recommend an excellent book on portfolio management is Advanced Project Portfolio Management and the PMO. It offer good advice about prioritization based on linkage to a sound business strategy that accounts for both demand and supply-side projects.
You do have a sound, clear strategy against which you can base your priorities, don't you?
As Frank states you need to look into implementing a portfolio management system, but first, you need to develop a Strategic IT Plan that supports your business unit, followed by implementing program office and portfolio management.
In other words, a top down review is the only approach that makes sense. Saving Changes...
Anonymous
Hi, I suppose I should have provided more context. We are in the process of a top-down IT Prioritization, and I am representing one of the business segments that is presenting its priorities. The problem we are encountering is that between segments, business sponsors are construing the priority scale differently, so that it becomes, as Frank implies, useless. We are hoping to put some definition to what qualifies as an 800 (borderline between important and critical, we are saying, for example. But we want to put it in generic business terms they will definitely understand how to use, and I was simply looking around to see if there were any ISO standards or PMI standards or whatever, dictating the gradations of business need ranging from 000 to 999. It seems not, so far... seems it's just a scale with more middle numbers, like 1 to 10 but using 2 decimal places.
IMHO, without a strategic IT plan that supports the objectives and strategies of your company, your effort is a complete waste of time, effort, and energy...ALIGNMENT and FOCUS are the keys to success.
You need to go through the strategic planning process first so you can clearly define what your company's priorities are in terms of BUSINESS VALUE (effectiveness, ROI, and competitive advantage). As it stands now, you simply have a lot of folks saying "my project is high priority" and competing for limited resources, whether it makes business sense or not.
Think TOP DOWN! Saving Changes...
Anonymous
Tom, yes, we are doing that. I was only inquiring about standards of expressing criticality among priority ratings, about which there seem to be none. Thanks for your input.
Moose...I kind of liked the the "standards" implied by a comment you made in a previous post...self-descriptive plain English words like
Critical (important and urgent to protect and/or grow organizational throughput, typically focused on current constraints to growth)
Important (for growth of throughput but not necessarily urgent, perhaps related to raising the capabilities of second- or third-tier constraints that would undesirably become constraints to growth once the current constraint is addressed via "critical" projects)
Useful (local/functional work-life improvements and cost reduction efforts)
Nice-To-Have (but not a big issue if we don't get to them), and
Why-Are-We-Doing-This.
Five nice buckets which quickly become four once they are determined.
Within the buckets, if you want/need to further refine criticality to strategic intent, map the projects to the various tactical objectives they support. The more (and more important) tactics that a project or program of interdependent projects supports, the higher ranking it gets. Saving Changes...
Frank, this guy or gal doesn't get it! You gave him or her a great book recommendation and continue to get a pretty clueless response!!! Saving Changes...
Anonymous
Frank, thanks for that, I was beginning to worry I couldn't accurately describe my request, but you got it exactly. Of course a strategic plan and top down prioritization including ROI needs to be applied. But my query specificaly was about whether there are any definitions about the thresholds dividing numbers in a priority scale ... so that business sponsors can identify in number what they feel their relative priorities are (independent of ROI or strategic benefits, they are other crucial data points to use in the strategic prioritization effort), but are informed by some terminology helping them rank appropriately and not to overinflate. So thanks, what your last posting put out was exactly the kind of start I was looking for, and very close to what we have improvised so far also.
I'm sorry to say I have not had time since Wednesday to acquire the book you recommended (much less read it) but I certainly will. I appreciate your good faith in advising here!
Today's other comment did not evince any good faith and doesn't merit a response or a place in this kind of forum. Saving Changes...
Glad to help, Moose. By the way, my weblog touches on these kinds of things all the time. As a matter of fact, I like what I wrote in that last entry of mine so much that a version of it will probably show up in it this week. Thanks for nudging me to a workable start for you. Saving Changes...
Anonymous
Am I currently working on a very similar issue to Moose, I have found this discussion very enlightening, thank you.
I would however like to say that Tom's comments typify project speak arrogance. The project world is full of people who are using jargon that the business cannot process. As soon as anyone queries or does not understand a concept they are looked down on. What just occured in this forum is exactly what happens in the project world. We need more people with your patience and desire for understanding
"Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so."
