Aligning business goals and prioritizing projects based on corporate strategy seems a natural progression, but is far from a practical reality in most matrix organization. Statically just about a tenth of project organizations have managed to put in place a half decent, transparent Project Prioritization policy. Worryingly, almost two thirds have no formal prioritization process and are ‘blissfully’ unaware of the consequential impact.

Today’s dynamic business environment and organizational readiness warrant a consistent Project Management and prioritization policy to encourage refining of operational efficiencies which in turn could translate into strategic business initiatives and generate intrinsic value neurons. A well oiled system would effectively prioritize between a mandatory, strategic, tactical and compliance projects, and still be on the right side of Kirchhoff’s Law. In other words, personal interest, coercion, hunches, knowledge levels or influences would no more define project consistency and priority, but the business goals.

Then why doesn’t everyone do it?? An obvious question I suppose!! Answer lies somewhere in the responses which might just sound a bit too familiar….“We all know which projects are the most important ones” … “All of our projects are important” ….”Our business is changing on a daily basis”….”We do not need an extra layer of bureaucracy, which limits our flexibility”…

These reasons would continue to be true unless the top management is prepared to be the power sponsor for the cause. Spinning a new wheel might be a concern, but improving operational efficiency of existing systems, may attract a few buyers. Since this process can be readily integrated with nominal effort into existing request mechanism processes like desktop forms or high end dPMM or automated enterprise applications, development cost can be ignored as a barrier. Benefits and value of deploying this process are not ephemeral and a slight increase in annual operational efficiency can contribute to a big chunk in savings though some organizations choose to value the project based on Financial parameters like ROI, payback period etc. Apparently, penning down the risks associated with the project along with CTQs and CSFs will give an edge to the whole plan.

Next step is to define the scope, outlining and emphasizing on In-scope and Out-scope activities. While designing the process, questions like “whether the process/application be implemented only for projects or also for high volume low effort activities? How would informal tasks or undocumented activities of a few hours be accounted for? How the criteria could be different with routine or emergency issues?” are vital to be discussed and brainstormed. Failing to define clear scope may make this process a burden, as resources will keep on multitasking and will be in a state of confusion if any out of scope request comes to them. Getting data from current project inventory will be valuable.

Once we have a well defined scope, based on experience, mutual discussions with leaders and available project data, we will have to establish quantifiable criteria to score the projects. Some of the common criteria are alignment with Organizations goals, type of Project (Compliance, Strategic, Tactical, Quick-Win, and Support, depending on request mechanism system), Cost/Benefit Analysis and Constrained date.

Finally, the easy bit, most organizations use scoring rules to prioritize projects as they systematize and automate prioritization of projects. Below are a few examples of prevalent Scoring Models:

One dimensional Scoring Grid
Different evaluation criteria are given as scoring option and if a project gets negative in any of such criteria, it will on the lowest priority. For eg:

Criteria: Alignment with Organization Goals

* Project aligns to 3 or more Goals (+ve)
* Project aligns to one or more Goals (neutral)
*

You do not have flash or javascript support.

Average (2 votes)

Reply