Written By: Parimelazhagar Selvaraju

A day in the life of a Project Manager (PM) is hectic.  Tasks, Risks, Action Items, and Reporting – Oh My!  Not to mention, the classic competing constraints of “scope, budget, and time” and pulling them in a thousand directions.  Consider all of the strategic and important things a PM has responsibility and accountability for:

• The PM meets with executives to initiate a project, then meets with business stakeholders to help define scope.
• The PM plans the project with Work Breakdown Structure (WBS) with the best information available at the beginning of the project.
• The PM creates detailed tasks, milestones, and status report templates.
• The PM gets project team and stakeholder buy-in.
• The PM distributes relevant work to the team and stakeholders, giving them directions on tasks to perform.
• The team begins the project enthusiastically. All goes well—for a few days.
• The PM is then pulled into different directions with “urgent” tasks from the team, stakeholders, vendors, and anyone else who is connected to the project in some way, ultimately needing to direct all to a successful project completion.

How do they do it?  Prioritization.

A PM must be a superior prioritization guru.  Let’s take a look at an IT modernization project day for instance: The PM gets in and grabs a coffee and reads their e-mail. There they find five e-mails from five different important project team members:

1. A customer stakeholder thinks adding a feature is important to performing his/her job.
2. An engineer brings a work component concern to the table, claiming the work he/she is suggesting will greatly improve the usability of certain functions in the project.
3. A quality analyst reports a defect in the system.
4. The engineering team disagrees in a subsequent e-mail that this is a defect.
5. An account manager thinks adding features from conversations with his/her interactions with the customer will be a great value add to the project.

How can the PM judge each “need” from team members to find if it, in fact, is connected to the project and is worth doing? Can the PM cross-reference the meticulously planned detailed tasks in the Project Plan to find if they are already on the list and accounted for? The PM faces these challenges daily, wishing there was an answer somewhere. Fortunately, there is one. It is the project business case.

The Business Case as the Guiding light: Image credit: Creative Commons License

“The business case lists the objectives and reasons for project initiation. It helps measure the project’s success at the end of the project against the project objectives. The business case is a project business document that is used throughout the project life cycle.”

PMBOK® Guide – Sixth Edition

The PM must be acutely aware of the business case of the project. The business case is the guiding principle that will help determine the real needs of the everyday tasks he/she receives from anyone in the project team. If the task does not align with the business case, the PM can safely discard the task and communicate it to the requestor. If the task, after evaluation, aligns with the business case, the PM can add it to the prioritization matrix.

Let’s revisit the example requests from project team members in the previous section.

1. A customer stakeholder thinks adding a feature is vital to the project.

When the PM analyzes the importance of the feature, it is the stakeholder’s preferred way to complete work in the legacy solution and does not necessarily translate as critical in the to-be solution.

2. An engineer brings an idea claiming the work he/she is suggesting will greatly improve the usability of certain functions in the project.

While this could be true after evaluation, the intent behind the suggestion turns out to be that the engineer wants to use his/her favorite toolset and this might not be the best approach for the solution.

3. A quality analyst reports a defect in the system. The engineering team disagrees this is a defect.

There is always a disagreement between engineering and QA teams in a project. The QA team’s “defect” is contested as a “feature request” by the engineering team.  In this case, it is likely necessary to review the initial requirement with the business stakeholders to truly understand the importance of the request.

4. An account manager thinks adding features from conversations with his/her interactions with the customer will be a great value add to the project.

The account manager’s input is valuable, but it may or may not align with the needs of the current project.  Further review is needed to determine if these features should be included.

As you can see, using the business case allows the PM to make a quick first pass at items that should be considered for prioritization.  From there, they can work with their project team and other PM tools and project artifacts to deliver an on-time, in-scope, and within-budget project.

References:

1. Project Management Institute (PMI) – www.pmi.org
2. Agile Manifesto – https://agilemanifesto.org/
3. 7 Habits of Highly Effective People – https://www.franklincovey.com/the-7-habits.html