Prioritizing Project Goals to Align with Your Organization’s Strategic Goals

[article]
Summary:

Prioritization is a key ability leaders must have to manage project goals and ensure they are aligned with organizational strategic goals. Priority management is a very complex task, and it should concentrate on these issues by taking care of the business needs, goals to be achieved, budget, and risks. Read on for details.

Prioritization is one of the key abilities leaders must have to carry projects toward success.

In order to know how we can sort all of the activities we need to have done in order to finish a project, it is vital that we have a good understanding of the business we are in—especially knowing what the project drivers are.

There could be a lot of project drivers that encourage project execution and lead an organization to assign the necessary budget. The main thing to keep in mind when prioritizing tasks and goals is to align the project drivers with the strategic drivers underlined by the business. Some of the most common examples could be:

  • Time to market
  • Product quality improvement
  • Post-selling maintenance cost saving
  • Customer satisfaction assurance
  • Increasing market share

A good leader must understand these concepts and be aligned with them in order to address the necessary dynamism when managing a project. It’s essential to continually prioritize and reprioritize tasks and goals looking after new requirements or changes introduced by topical issues related to the sphere of influence.

Here, there arises the need to identify the big difference between a leader who is focused on delivery and a leader I call an enabler. The former will focus on project deliverables dealing with the cost, schedule, and scope variables—known as the “triple constraint”—only to comply with the assigned budget and deadlines. By contrast, the enabler is going to manage these variables to comply with the organizational strategic goals, not only by focusing on deliverables and deadlines, but also by assuring that the planned added value is conducted as expected.

At first glance, the need for any project execution comes from an organizational strategy need. Based on this necessity, the “go/no go” decision has been made by analyzing the business context within a frame of some special characteristics related to the goals the organization is looking to achieve.

This input should act as the kickoff to allow the project leader and his team to verify the original scope, breaking down the work in terms of business value and creating a realistic plan for trustworthy estimation. Through this estimation, the project leader will be able to figure out the percentage of the business value contribution for each task.

Prioritizing Based on Complexity

When facing a big-bang project, we should break down the main solution into measurable and manageable pieces that represent a portion of the business process. This division will allow leaders to identify existing constraints between tasks to be executed and other business entities to be implemented in order to better understand what their individual added value contributions are. For instance, if we are going to implement a selling solution, the billing functionality will be the first feature customers are going to ask for. If the customer is not able to invoice, the business will not work. Therefore, if we set up the billing functionality as the top priority, we must keep in mind to look for possible constraints. For example, we will not be able to invoice if there is no definition for articles on the shelf. The conceptual business flow must be performed as a whole to be able to prioritize firstly based on business needs and organizational goals, then based on constraints and other roadblocks.

It is common to prioritize goals according to several well-known methodologies, such as the prioritization of issues based on the complexity of each item to be implemented. The purpose of this rule is to start working on those items considered the most complex to reduce risks and avoid stumbling upon any unexpected problem when facing the home stretch. If we are able to deal with the more complex problems from the beginning, we are less likely to have to struggle with complex issues at final stages.

This ordinary practice is very useful if we only focus on delivery and deadlines. Having said that, if we also start analyzing priorities in terms of the added value contributed by each planned deliverable, we can prioritize goals trying to give more business value within the shortest possible time, targeting the less valuable goals to be treated by the end of the project.

Prioritization is not an isolated practice, and it must go hand in hand with looking after business needs, budgeted costs, and the expected quality, which could be part of the organizational strategy and in most cases could also be a project driver itself.

The Importance of Communication

To assure that the leader is prioritizing in the most effective way possible, it is important to share the strategic plan. A project leader must be supported and motivated and should be involved in the business decisions being made. If the project leader does not know the organizational strategic arguments, he won’t be able to create a project plan aligned with the goals the organization is striving toward.

In the same way, the project leader must communicate any change applied to the prioritized goals and report to the organization the expected impact and involved risks. The leader does not always have the entire business context to make unilateral decisions, but his point of view based on his part of the project is still useful to the organization when considering the big picture.

The emotional impact this kind of communication could bring must be managed with care because every change may affect staff morale and team performance. Ever-changing prioritizations could be a critical matter. It’s best to be clear about the business context and project drivers from the beginning and try to maintain stable prioritization as much as possible.

Nevertheless, organizations are dynamic. Higher-level decisions may change with more or less frequency according to business context. Prioritization management starts with the organizational project pipeline. At this stage, decisions are made in the pure style of “go/no go”. On the contrary, in the project management context, decisions are more results-oriented, taking care of the project execution and goals. But when organizational goals change, an ongoing project might get a lower priority.

It is crucial to emphasize that prioritization should be maintained at all levels. Many times projects fail or must be canceled during their execution due to poor prioritization and project portfolio administration. It is common to focus on the management of a particular project when these kind of issues arise instead of trying to figure out the real root cause, which could be found in the higher-level plan or in communication of the organizational strategic goals.

Managing Risks

Risks also need to be prioritized. Commonly, risk management activities include cost-impact analysis. Each risk, regardless of its nature, will end up producing an economic loss. Risk management and the strategy to deal with risks must be included in a project’s cost. If we tried to be safe and avoid having any risks in the project, the cost of the risk management would be higher than the cost of the project itself. Consequently, risks should be prioritized, and the budget to manage them must be assigned based on this priority.

A common practice is to quote the risk budget by considering the economic loss of its impact and the percentage of its likelihood of occurrence:

Budget assigned to risk management = [Economic loss produced by the risk impact] * [% Probability of occurrence]

By taking into account the economic loss for each risk multiplied by its probability of occurrence, the outcome will be the necessary budget to control each risk. The sum of the outcome for each risk to be controlled will result in the total quote needed to support all risk management activities.

In this case, the prioritization concept needs to be introduced again. Risks and their budget should be prioritized not only by cost and economic loss, but also by taking care of the negative impact on the project goals and the organizational strategic goals.

Conclusion

Prioritization is a key ability leaders must have to manage project goals and ensure they are aligned with organizational strategic goals. Priority management is a very complex task, and it should concentrate on these issues by taking care of the business needs, goals to be achieved, budget, and risks.

User Comments

6 comments
Kevin Dunne's picture

Christian, 

I think that this article is great!  

In the beginning of the section Prioritizing Based on Complexity, you mention a Big Bang project as an example for the context of your article.

I am wondering how these strategies you have laid out here would apply or would apply differently in an agile environment, or more iterative project for that matter.  Do you think that addressing complexity up front would still be a valuable way of going about things in this context?  

I am thinking that, considering there is an expectation of some code/features being delivered at constant frequent intervals in this scenario, that you would want to bite off some "easier" pieces first up front to get your legs under you, then move on to more complex features in later sprints. 

Kevin

August 20, 2014 - 12:26pm
Christian Fernando Kedidjian's picture

Thanks Kevin! Your question brings up a great contribution.

When you are working on in an agile environment, you are good to apply this kind of prioritizarion. Keeping in mind that most of the Agile methodologies tries to give the more business value in the shortest time possible, logically, first prioritization must be based on business requirements. But you never have to stop looking after the project as a whole. In every agile project you have to plan for each iteration, but you also have to perform and manage a high-level release plan. This plan must take into account the complexity. Additionally, in IT proyects, complexity is not always related to business requirements, it might be more related to the software architecture, test strategy, database engine, and so on. So, you have to analize the complexity to plan the best strategy and be able to avoid any roadblock and risks from the begining to be sure that you are on track to deliver what your customer asked for in terms of business value.

Risks must be managed too. Risk management must force you to re prioritze your product backlog overriding your fist analysis if you don´t have a good risk management plan before facing the first sprint. Anyway, a non-expected risk may appear out of the blue and impact on the project plan forcing the team to re prioritize from the scratch. But again, it has a very low probality if you have a good risk management plan.

On the other hand, in spite of the fact that you were working on in agile environment, you have to manage a product backlog, and in some cases this list of requirements could be more like a big-bang project. The release plan i have mentioned before comes up from this backlog list.

Once the product backlog is prioritized and the release plan has been laid out, you are able to perform a complexity analysis to determine which is the next strategy and re prioritze your backlog to better comply with the business needs avoiding complexity risks.

The hardest task in agile is to manage a stable prioritization, since precisely, the backlog list may change at the begining of each iteration, but the methology has been conceive to support this kind of demand.

from my point of view, there is not only one prioritization strategy that always fits the frame. You can mix them and choose different strategies depending on the business you are in, and also depending on the issues you have to struggle with for each project stage or project management level.

Remember, the main idea is to be sure that you are always aligned with the Organizational strategy goals.

Hope it helps!

August 20, 2014 - 1:47pm
Kevin Dunne's picture

Christian, 

Thanks for the reply - a lot of great information in here I can use.  I totally agree with you, there is not one tried and true process that will work in any environment, but it is great to know some frameworks I can use.

Look forward to reading more of your stuff in the future!

Best, 

Kevin

August 21, 2014 - 11:42am

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.