Project Management and Resource Planning: Prioritizing of the list of demands pt.2 – Categories and Methods

There are many methods and frameworks out there to use for prioritzation or ranking of projects.  The important part is not which one(s) that you use, but that the definitions, guidelines, and the “why” for using each is established and communicated with the group of people who will be applying them to the list of projects.  In the end, this group needs to be able to articulate the process that they went through to prioritize or rank the projects on the list.  This is important because there will usually be a large number of projects that do not get the green light and the requesters need to be communicated with so they understand why.

I prefer to use a blend of the following methods in the overall prioritization exercise so that the process accounts for the nuance between the various projects.  It is very tough to have a ‘one size fits all’ methodology or framework.  Even organizations that apply a scoring criteria to projects which allows them to prioritize based on scores, uses a blend of criteria to come up with the final score (these usually have a fair amount of subjectivity to  them).

Here you go:

• Binary ranking of “Required” vs “non-required” works well to get a first cut of a large project list, but the definitions must be communicated and accepted by the group of decision makers at the beginning.  These are the projects that have a large risk for the organization if they are not done.  Examples might be replacing failing or end of life equipment, or projects that fulfill a regulatory, contractual, or other legal obligation for the organization.  The ‘have to do’ projects are “Required”.  Be very judicious in adding projects to the “Required” list or it will get too large and lose its impact.
• Subjective “#1 Request” categorization of projects is as it states, a subjective ranking where the decision makers (usually senior leadership) get the opportunity to apply a “this is my #1 thing that I want done” to only one project for their area of responsibility.  This is good for those projects that have been submitted year after year and are not “Required” and never get force ranked high enough to make the cut.  It allows these leaders to use their one wild card to get something done that has importance to them.  It could be a cool new innovation project, or a ‘quality of life’ project for their teams.  It doesn’t matter what it is, they get to have it bumped up to the second from the top of the category list (under “required”)
• Identifying the “non-required” and those projects that are not in the “Subjective #1 Request” lists by whether they are “Critical” or “Important”.  This is similar to the “Required” prioritization in that it is binary.  Again, definitions must be established for “Critical” and “Important” and they must be adhered to.
• Force-rank prioritization, only works for a list of less than 15-20 projects.  After 20 in a list the rankings lose meaning and become arbitrary.  Project #78 is really no different than project #103 in a list of 120 projects.  Use this to sub-rank projects once you have them prioritized into groups by “Required”, “Subjective #1 Request”, or “Critical” vs “Important”.

In the end you will have your large list of projects prioritized in order by the following categories:

1. Required Projects
2. Subjective #1 Projects
3. Critical Projects
4. Important Projects

If anyone out there has come up with or come across any interesting prioritization methods, please share in the comment section below.

Project Management and Resource Planning: Prioritizing of the list of demands pt.1: Overview

You have the “list of demands” or project requests from the organization for the coming year, but there is way more demand for projects and resources than the organization can supply.  This is where the hard work comes in.  This will can be a process full of emotions, politics and frustration.  But it doesn’t have to be all conflict and ‘horse trading’ to get things done.  There are many benefits that the organization and its leaders involved in the project prioritization process can gain.

Inclusiveness:  It is likely and preferred that the group of leaders who will be prioritizing projects will come from and represent various departments and divisions within the organization.  The perspective, exposure, and focus of each will be different.  This brings potiental for conflict but it also brings everyone together to flush things out in a way that is inclusive.  Nobody should walk out of the room at the end feeling like they were part of the process.

Shared Ownership:  The group needs to have the same understanding of the process.  When it is done and there is a final list of projects that the organization has committed to giving the green light to, everyone involved owns the results.

Top to Bottom Support and Cohesiveness:  If done well, this process can create a better alignment of the middle, and senior leadership with the executive team.  Each plays an important part in this.  The executive establish direction and strategy.  The middle and senior leaders provide the ‘how’ we get there, aka projects and initiative to achieve the larger strategic goals.

Relationships:  Anyone who has gone through a dangerous, strenuous, or challenging experience with someone knows that there are bonds formed in those times of stress that are long lasting and impactful.  I am not going to say that going through project prioritization with someone is the same as surviving a hurricane with them, but at times it feels like it.  Either way, this group will come out on the other side with at least a better understanding of where the others are coming from and hopefully build stronger relationships with them that will help their work in the future.

The best news here is that each year the organization goes through this process, it gets better and it gets easier…as long as the process is improved in an iterative manner each year.

I would love to hear from you.  Tweet me @ScottTWaters or leave me a comment below.

Project Management and Resource Planning: Supply and demand

Supply and demand applied to resource management is a simple concept that is tough to measure effectively, even tougher to communicate effectively and almost impossible to get everyone to acknowledge, accept and support.

The most simple way to explain how supply and demand work for project management and resource planning at an enterprise level is use the Time, Cost, Quality Triangle.

The concept is that you can only have two of the three elements with any project, but you can’t have all three. The business decision is to decide which two elements to focus on and which one you won’t achieve and to stick with that approach.

Let me explain further.  You can have a project (or projects) that is done quickly (Time) and inexpensively (Money), but the Quality is likely to suffer.  There are certain circumstances where “done is better than perfect” and this would be an acceptable approach.  An example of this is when you have a project that is an unplanned emergency or an opportunity that you have to act quickly to take advantage of, but don’t have the budget to do it to the highest quality.  You can have a project that is done quickly (Time) and has to be of the highest Quality, but it is going to cost you (Money).  You can also have a project that is done inexpensively (Money) with high Quality, but it will take you longer to complete (Time).

Conceptually, this usually makes sense to people, but it is important to communicate it to all of the stakeholders and leaders involved. A candid discussion about how to use your limited resources needs to occur.  How will the organization approach the situation where the demand exceeds the supply of Money and Time if you want to deliver a Quality project.

Everyone’s project is their highest priority but if looked at objectively along side the other requested projects, their project may not even land on the top ten list of high priority projects for the enterprise.  So, how do you get buy in from all of the requestors, stakeholders, and resourcing departments?  My best advice is to start by taking the list of projects that you have applied the scoping and resource need quantification exercise to(which if went over in my previous post), and make a visual display showing the capacity for each resourcing/service department along with the demand.  A stacked bar chart works well for this.  This visual needs to be the focus for a resourcing meeting with all of the key decision makers so that everyone is seeing the same picture at the same time.  The goal of this meeting is not to make any decisions, but to have everyone leave the meeting understanding that there is a gap between the projects requested and the projects that can be approved to be resourced.  

Next we post we will do a deep dive into some methods for prioritizing projects.  The type of prioritization applied matters and I will explain why.

I would love to hear your thoughts on how you have been able to effectively communicate and get buy in (or not) with your organization related to using limited resources.  Please comment below or reach out and follow me on Twitter to continue the dialogue.

 

 

Project Management and Resource Planning: Scoping and resources… “who’s coming with me?”

So, you want to do a project.  You know it’s an important project and one that the organization will benefit from.  Furthermore, it aligns perfectly with the strategic direction set forth by Executive Leadership.  Now what?

The first thing that is needed is for you to develop a scope for your project.  Ever heard the term “You can’t boil the ocean”?  This is directly applicable to scoping a project.  Don’t try to do everything that ‘could’ be done.  It is important to build some guard rails and parameters around the project to ensure that the goals are effectively articulated, documented and achieved.  The scoping exercise tasks related to project management are some of the most critical tasks that can be done in the project life cycle.

The Project Management Institute defines Scope Management as:

“Project scope is the work required to output a project’s deliverable. Change happens, and project scope management includes the process to manage scope changes and make sure the project will still come in on time and within budget. Scope is often defined by a work breakdown structure, and changes should take place only through formal change control procedures.”

In normal language, this means, document what you want to achieve with your project, by when, and spending how much.  This is your “scope” for the project.  Any changes to the established scope of the project must be carefully considered because they will most likely impact the cost or timeline of the project.

The biggest aspect of scope that can make or break your project is getting all of the human resources (people) you need to get it done set up and allocated to your project when you need them in the timeline.  This in and of itself is not that difficult, but again, remember that in most organizations (especially those who share certain service departments to achieve economy of scale efficiencies such as HR, IT, Finance, etc) the people or departments that are needed to resource projects are often being pulled in multiple directions.  How do you ensure that you have the HR or IT resources you need at the time you need them to get your project done?  This is where you need to put some resource planning framework in place, even if it is at a basic level.

Resource planning can be done at a division, department, role, or individual employee level depending on how much work the organization is willing to put into the resource planning.  My advice is to make this an iterative process that adds more detail year over year.  This will account for the change management adjustment folks need when learning to do something new.

A great place to start is the department level.  When approaching resourcing from the department level you can use a basic methodology to land on a general department capacity, which is usually hours, available to do projects.  It is important to be realistic when looking at a department’s capacity, in hours, to do projects.  Most support departments do a mix of Administrative work, Break/Fix or Routine Operational Tasks (keeping the lights on), Vacation Time, and Project work.  Keeping this in mind, one can use some basic math to arrive upon a total number of hours the department has available for new projects.  Most departments can allocate no more than 25% of their total capacity for new projects.

A hypothetical  department’s project capacity (in hours) plan would look like this:

• 20 Total FTE/Staff in department × 2080hrs per year per FTE × .25 = 10,400hrs

As part of the scoping efforts for a project, it is important to determine how much time/how many hours you are asking a department to resource your project.  When there are multiple projects vying for the limited resources of specific departments, the capacity runs out very fast.  This creates a need for prioritization of project requests.  Prioritization is a challenging endeavor which I will cover in more detail in a later post.  What is important at this step is to signal the departments that you are asking to help you out or ask ‘Who’s coming with me?’.  We know that Jerry Maguire had himself and the fish, but who else does he need to start his new project?  Those departments should know that they are needed, when and how much.  That is the magic of project scoping and resource ‘tagging’.  You are letting others know you need their help.  Whether or not the help can/will be provided is what will be flushed out later.

Do you know of other ways to calculate capacity for resourcing?  Please share them with me in the comment section below and give me a follow on Twitter so we can continue the conversation.

Next up, I will be diving deep into the supply and demand constraints of resourcing multiple projects.

 

Project Management and Resource Planning: Can we see what’s out there?

Do you remember the last scene in Raiders of the Lost Ark, where the Ark of the Covenant is put in a crate and stored in that huge warehouse with thousands of other crates and boxes?  I remember even as a kid, thinking ‘they went to all of that trouble to get the Ark, and then they are just going to box it up and let it get lost in the warehouse?’  We all know that the whole idea was to ensure that the Ark never saw the light of day again, but it still seemed crazy.

What does this have to do with resource planning or project management?  Well, unfortunately many organizations are so silo’d that none of the divisions or departments know what the others are doing or planning to do.  So, from an enterprise visibility perspective we have the warehouse from Raiders of the Lost Ark full of crates and boxes that contain projects that nobody knows are out there.  How does senior leadership know that the strategic intent of the organization is being accomplished if they can’t see what is being done, from a high-level, across the various operations?  This also creates an inefficient use of organizational resources (money and people) and makes everything take longer than it needs to which leads to project execution failure.

These issues are compounded in organizations where the operations divisions share and rely on the resources in support divisions such as HR, Marketing, Finance, IT, and Strategy to execute their projects.  For the support departments it is important to know who needs them, to do what, and when, so they can plan accordingly.

The first step is to create an inventory of all the projects out there in progress and in the pipeline to be done across the organization.  But be careful here.  You can’t boil the ocean on the first attempt to get this inventory or it will be too big to provide insight.  My advice is to set some parameters for the work efforts/projects you want to track at an enterprise level.  Give the leaders some clear definitions of the types of projects, size, etc that you want to inventory.

Some basic guidelines for defining what items get included in the ‘enterprise’ project inventory:

• Projects must have a clear beginning and end
  • Not day to day operations items
  • When a project moves into production it is no longer a project, it is part of daily operations and work flow
• For the enterprise level visibility, only include projects that need multiple department resources to accomplish
• Enterprise projects to be included should be larger than 80 hours or take longer than 10 business days to complete (again, we don’t want to boil the ocean, so we can’t capture everything that everyone is doing)
• The funding source for the project is not relevant
  • Projects can be OpX, CapX, or not require any funding to accomplish (an example might be a process improvement project that doesn’t need budget, but will take a lot of time for those involved)
  • Don’t let the funding source be a distraction to getting the inventory done…cast a large net in this respect
• A project should be easily tied back to an organizational strategic goal
  • If it isn’t supporting the strategic direction of the organization, ask your self ‘why are we doing it?’

Provide the leaders the guidelines above and then create a tool for them to input their projects.  Make this part as simple as possible.  You don’t want them to run away before you can show them the value.  You only need a few data points initially:  project name, short description, when they want to do it, who they need to help them do it(i.e. HR, IT,..), etc.

There are many tools available that can help with the intake and management of the inventory, but don’t get too hung up on the tools.  I will provide a review of a few of the PM tools out there in a later post.  The important point here is the process and keeping it easy for the leaders.  Even Excel will work just fine initially.

There is a lot of value in just getting to the point where your organizational leaders have a list of projects (inventory) to start each fiscal year showing who is doing what and when.  This creates a sight line across the organization that is invaluable to those who are setting strategy and those who need to operationalize the strategy.  But we are not going to stop the journey here.

I will be covering project scope documentation and resource planning in my next post.  In the meantime, I would love to hear some of your experiences (struggles and successes) with trying to break down the silos in your organizations related to projects.  Provide your comments in the comment section below and let’s learn together.

 

 

Project Management and Resource Planning: What is this stuff and why is it important?

I don’t know about you, but any time someone comes forward with an idea my first questions are ‘why would we do this?’ and ‘what problem are we trying to solve?’.  It is very important for me to understand the underlying problem and proposed solution before I just buy into a new process.  This is especially true if the change looks like it will add a lot of work to my plate.

Too often in business and in life, people are attracted to the new shiny thing(process, approach, product, etc) and want to do it without fully defining the problem.  I will be diving into problem definition in a later blog series, so stay tuned for that.

Project management is hard and people need to really understand why they should tackle such a difficult thing. It needs buy in. It is hard to manage just a single project effectively.  There are so many details to vet, plan, track, and close.  There are challenging personalities to work with within project teams and stakeholders.  There is a lot of change management that needs to take place with most projects.  But before you get to the point where you are kicking off a project, and jumping into the fray to do battle, the project has to bubble to the top of a crowded list of wants and needs within every organization regardless of its size.

When there are multiple projects that are requested in an organization in a given period of time, you are dealing with a project portfolio and that is when things get complicated really quick.

Everyone is fighting for the same limited resources.  There is a finite supply of time available.  Most companies don’t have a never ending supply of money to fund every project that is requested.  And probably the most overlooked resource (which is always in short supply) is the human resource needed to actually do the work to get the project done.

So, simple supply and demand rules should apply, but in my experience are not always applied in a standard and repeatable way.  Usually the squeaky wheels get the grease and those projects with the loudest sponsors get done.  This approach doesn’t serve to further the strategy of the organization.

When its done well, resource planning along with project portfolio management will help to align the efforts across multiple departments and divisions to the achievement of the strategy for the organization.

Effective planning has other benefits that help to enhance the culture and overall execution effectiveness of an organization as well.  Below is a short list of the benefits:

• Creates visibility for all of the leaders and breaks down silos
• Improves teamwork
• Maximizes resource use
• Improves quality
• Aids in change management
• Reduces and controls cost
• Develops an organizational roadmap

These are only a few of the many benefits.  I would love to hear more reasons from you as to why resource planning is important.  Please provide your feedback in the comments section below so we can learn together.

In my next blog I will begin to build the framework for building an effective resource planning culture and process for your organization.  Starting with a process to inventory the demand.

Does enterprise project and resource management have to be this hard?

This picture may look a mess, but believe it or not, it represents a huge milestone on my long journey towards setting up an enterprise project management and resource planning framework.  The journey was one that taught me lot about why project management at an enterprise level is so difficult to do (let alone do it well).

Think about trying to manage a single project, with dozens of dependencies all over the place. Project tasks and resources collide with each other left and right,  constantly needing to be addressed.  Layer on an aggressive timeline and budgetary pressures, and it is easy to see why being good at managing a project can be hard.  To be a good PM you have to have many skills. One of the most important ones is the ability to keep all of the plates spinning throughout the project, so the risks and issues are kept at a minimum, ensuring you are able to deliver the project on time and under budget.  There are competing priorities that pull your resources away constantly, so you are always herding the cats (your resources or people) back to the project, and the tasks at hand.  You need to be able to prioritize the tasks using a number of different criteria and methods, and then communicate those priorities to the project team and stakeholders.  This is tough work that can be extremely complex.

Now, take that complex ball of craziness that is scoping, planning, and managing one project, and multiply it by 250!  Welcome to the wonderful world of standing up an enterprise project management office.  Ever tried to untangle a ball of Christmas lights that have been stuffed in a box in your garage for a year?  Well, getting a project and resource planning process stood up from scratch, at an enterprise level, can make you feel like Clark Griswold trying to untangle that ball of Christmas lights…only there generally is not a “Rusty” to hand it off to.

This blog will be a place where I tackle topics like enterprise project management, IT operations, Cyber Security, and general leadership, in an effort to simplify them. My first series will focus on project management and resource planning.  I hope you will join me for the ride.