Leading with a Beginner’s Mind

Last blog, I talked a bit about the importance of having the ability to clearly identify a problem, before jumping straight to solving it.  Slowing down, and trying to find the root cause is critical.  We don’t want to waste time and effort working on a solution that may be a great solution…to the wrong problem.

One quality of almost everyone I have worked with who possess excellent problem solving skills is the ability to look at an issue with a “fresh set of eyes” or hear it with “fresh ears”.  Some of this skill has to do with the process of problem definition, root cause analysis, and lessons learned.  But that is a framework.  What I want to discuss in this post is more of a philosophy and it is tough to do for many leaders.  I am talking about using a beginner’s mindset.

As leaders, we are used to being , well, leaders!  Many of us have risen through the ranks in our respective careers by solving problems, inspiring others, and hopefully being of service to the teams we have the honor to lead.  It can be very challenging to let go of what we have spent so much time accumulating – mainly expertise and experience.  But that is precisely what we need to do to ensure we are not sitting idle resting, while the world keeps moving on.

There are several books on the subject of Beginner’s Mindset, but I like how Chip and Dan Heath put it in their book, Made to Stick:

“Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has ‘cursed’ us. And it becomes difficult for us to share our knowledge with others, because we can’t readily re-create our listeners’ state of mind.”

It is true that with all of our hard work to become good at what we do, we bring along with it the “curse of knowledge”.  We often miss details that a “beginner” would notice.  In our efforts to multi-task (let’s all just agree that doesn’t work), and be super-efficient, we often blow past important details.  In our “experience” they don’t matter, or based on our “expertise” they couldn’t add value or contribute to the root cause of an issue.

This kind of approach can cause a litany of issues for basic problem solving and troubleshooting, but when we come into our engagements with our teams as “experts” instead of “leaders”, we often fail to listen to what they are saying.  And it matters.

There are a few basic things we can do to keep our mindset pliable enough to look at things like beginners do:

• Practice Mindfulness/Be Present – Don’t pull your past experience into things initially, be present in the moment, with fresh eyes.
• Don’t be the Expert – Even it it isn’t your first goat-rodeo, act like it is.
• Ask Questions without Trying to Find Answers – It is too easy to lead towards a conclusion you have already established in your mind.  Ask open questions as if you didn’t know all the answers (because you don’t).
• Try Something New – Take a new route on your commute home, take up dance lessons, do whatever, but make it new so you remember what it is like to actually be a beginner.  Stepping out of your comfort zone is a great growth opportunity.
• Silence Your Internal Critic – Don’t critique yourself, others, or situations.  Be open and accepting of people and things.  Assume good intentions, and try to apply empathy.  This will help you accept a new approach, or catch somthing you might have missed before.  There is a general approach to troubleshooting that works which is to work from the most simple solution/issue to the most complicated.  Do this, always.
• Look at Both Sides of the Coin – Don’t fall in love with your own ideas, conclusions, or solutions.  Look at the opposing views to make sure you are considering all options.

I believe applying the beginner’s mindset to leadership will make you a better leader, and probably spill over into other areas of your life and improve them as well.  This doesn’t mean we need to throw away everything we have learned and know, but it does mean that we can add to it.  Lyndon Johnson said it perfectly, “You are not learning if you are not listening”.  As experts we have a tendency to do a lot of the talking and far less listening.

I enjoy hearing your feedback.  Leave me comment or give me a follow on Twitter @ScottTWaters.

Effective Problem Definition

When I think of a single competency that is of the utmost importance in life it is the ability to clearly define a problem before jumping to a solution.  This applies to our personal and business lives equally.  The funny thing is that most of us are either unaware that we have this blind spot or think we have it nailed and do not need to work on it.  The hardest part is that in life, especially in US culture, those who are doers and problem fixers are rewarded.  The rewards come in the form of promotions, friends, and other accolades.  The real issue is that we learn through our increasing success and recognition, that fixing the problem is more important than clearly defining what we are trying to fix.  When you break it down, it seems counterintuitive and not logical to try to fix a problem we haven’t defined.  I mean, how do we measure success?  How do we know if it is fixed if we don’t know what “it” is?

The good news is that there is framework to follow to ensure we are defining the problem first and then going through a simple process to figure out which solution will best address the problem.  This framework is simple and easy to follow which aligns with my approach to most things.

Specifically for those in leadership, sometimes there is a true emergency that needs to be triaged and solved quickly, and other times the  problem is less time sensitive.  Each need a slightly different approach, but regardless of the type of problem you are faced with, you need a basic framework to work from so that you are able to lead your team to the best solution.  As leaders, we are generally not the ones who are actively working through the tasks of addressing a problem. We are not pushing buttons, pulling levers and turning knobs. In most cases we are supposed to lead the efforts and planning to resolve the problem.

So what tools do we have?  

The infographic above shows the basic framework to follow.  We should break each issue down into 3-4 steps.  These steps can be very simple and quick to do, but they need to be done to ensure you are fixing the real problem and finding the root cause before you head into fixing the problem or solution generation and prioritization.

A brief summary of each is below:

Problem (definition):  this is sometimes known as the problem statement.  This is the step where you slow things down, take a step back a truly evaluate the situation. A good problem definition or statement should be a short and simple description of the issue to be fixed or improved upon. It should show the gap between the current state and the preferred end state.  This is where you get the 5 W’s: who, what, where, when, and why.

You have to understand the problem before you can find the root cause, which will then help you determine the best solution(s).

 

Cause (root cause):  The root cause analysis work is a thorough look at what the causes of the problem are/were.  This is the point in the process where you will list all of the potential causes and do a quick vetting of each to determine the likelihood of them being a root cause of the issue.  If you have done a good job of clearly defining the problem, then bouncing each of the causes in your list up against it should be fairly easy to do.  Eliminate those causes that do not seem to be big enough contributors to be at the root of the problem.

Solution:  Now is the time to start working on solutions.  Again, it is always good to list the solutions to the problem by looking at the root cause you established in the previous step.  Keep it simple and focus on the solutions that will give you the biggest impact or benefit with the least amount of energy.  This is the low-hanging fruit approach.  Once you have your list of solutions, prioritize them using the biggest impact/lowest energy to implement as your guide.

Now implement your solutions and don’t forget to circle back around and do a lessons learned exercise to figure out how you can do things even better next time.

As always, I would love to hear from you.  Leave a comment below or look for me on Twitter @ScottTWaters.

Project Management and Resource Planning: Tools of the Trade

This is the part of the journey where I share some of the tools of the trade that I like to use for project management.  Remember, this is not a one size fits all type of thing.  You have to first decide what level of detail you want/need for tracking your projects and project portfolios.  There is a big difference between tracking individual projects with low levels of complexity/minimal team members and trying to keep track of complex projects individually and as part of an enterprise portfolio.  It is important to find the most simple solution that fits your need.  The more complex the solution you choose, the more time you and your teams will spend on project management administrative tasks rather than doing the actual work to get the project done.  The law of diminishing returns applies well here, so choose to track and report on only the tasks and metrics that are truly important and nothing more.

I am by no means going to give a comprehensive list of everything out there in the project management space, but I will give you a peek into the tools I have used and continue to use that make life easier.

Let’s group everything into 3 buckets:  Low-tech, Mid-size, and Enterprise.

Low-Tech:  Spreadsheets and simple task lists

At the most basic level, project management is simply about creating a list of things that need to get done, by when and deciding who is going to do them.  So, with that in mind the most basic form of project planning can take place using some form of a task list and tieing that to a calendar.  In fact, I have seen people be very successful planning and managing projects using Microsoft Outlook built-in functionality such as tasks, reminders, appointments and other calendar functions.  If you want to step it up a bit, Microsoft Excel has plenty of project management templates that can help you create simple to fairly complex Gantt charts.

Mid-Size:  SaaS PM and collaboration solutions

There are many SaaS (software as a service) or cloud-based project management and collaboration solutions out there.  The key to picking the right one for you is to decide what you need to do with the tool.  Do you need a space for documents and other files to be worked on by the team collaboratively?  Do you need to manage one or many projects?  How many team members typically work on your projects?  All of these questions matter because there are literally hundreds of project management solutions out there that offer varying functionality.  The two that I really like are:  Confluence for collaboration and Trello for more formal project management tasks such as issues and task tracking.  When you combine these two tools, you can do a great deal, and the learning curve is still very low.

Enterprise solutions: Complex project and large project portfolio management

When you get to the point where you need to manage large projects or portfolios with numerous projects in them, then a more robust solution is probably necessary.  Still, remember to keep it as simple as you can.  I like to apply the logic that if a project is highly complex, highly visible, or has a large cost or budget then it is worth tracking to a higher level of detail.  This is the space where the project management administrative tasks become much more onerous and time consuming so make sure it is worth it.  You should be asking yourself:  Is the juice worth the squeeze?  We certainly don’t want to do project management for project management sake.

The larger, enterprise tools that I have found to be the most useful are:

BrightWork,  an excellent project and portfolio management tool which allows for simple to very granular project and resource management.  If you have a Microsoft SharePoint infrastructure in place and are familiar with its use, then BrightWork is a great tool with a lot of automation available.  The one area it doesn’t address well is collaboration outside of your organization.  Since BrightWork sits on top of SharePoint, it relies heavily on Active Directory, so it is tougher to open it up to team members who are not full-time employees.

SmartSheet, is a really solid solution across the project management and collaboration spaces.  If offers a lot of flexibility through the use of mobile apps and plugins.  It is also a SaaS solution, so accommodating larger teams that are inside and outside of your organization is fairly simple.

These are just a few of the many tools out there that can help you manage your projects more effectively.

I am always interested in hearing from you.  What tools are you using to manage your projects and project portfolios?  Share them in the comment section below or Tweet them to me @ScottTWaters and I will reTweet and share them.

 

 

Project Management and Resource Planning: The final product…are we there yet?

Now we have an enterprise gantt/schedule to start the year that aligns with the strategic intent of the organization.  All the hard work is done, right?….Nope!  The real work starts now.  

You will need to continue to scratch and climb your way along the the planning path with frequent stops and starts.

Emergencies and opportunity projects happen.  Even the best planned projects go off the rails.  This will test your will, stress you out and challenge your resolve.   The inevitable change in plans will force you to not only manage the portfolio of projects from a status perspective (project status, health, etc) throughout the year/cycle, but to sometimes cancel projects, replace projects or reschedule projects to keep things on track.

The most important thing to consider and pay attention to at this point is to ensure that you don’t let the overall schedule slip without quickly adjusting.  If the initial scoping and planning of each project is done well and the management of each project is executed effectively, there should be ample time factored into the project plans to account for some level of timeline slippage.  If any projects go beyond the planned “wiggle room” that is built into the timelines, then now is the time to jump in quickly and get things on track or take a look at the potential downstream effects that will impact the other projects on the schedule.  Remember, it is not just one project you are dealing with at an enterprise level, and small problems can have significant impacts.  Look back to the inter-project dependency mapping exercise we went through and make sure to account for those as well.

One last note of caution, when the “opportunity” or “emergency” project comes in, outside of the planning schedule, you must go back, reference and use the tools we have discussed during this series, specifically:

• Cost/Quality/Time Triangle – when something new comes in, you have to take something of equal weight (work effort, timeline, cost) off the schedule/gantt if all of the resources and constraints remain the same.  Physics still apply.

My next series will focus on PM tools that can make project management easier and better.

I am very interested in hearing from you.  Leave me a comment below or a follow on Twitter @ScottTWaters.

Project Management and Resource Planning: Prioritizing of the list of demands pt.4 – Inter-project dependencies

One of the last steps in the process of coming up with an enterprise schedule/gantt is to figure out which projects depend on which in order to get done.  This can often be the straw that breaks the camel’s back for a group of people who are trying to get a massive list of requests down to something that is realistic and doable.  This is the case because the process of getting to a “doable” list is an exhausting one if it is done right.  It is all about the long game with this stuff and it takes a significant commitment and endurance to get to the final list.

So, we have a list of requests that have been scoped, prioritized, and filtered down to something that looks like it can be done, at least on paper.  We have considered timelines, budget, resources and we are thinking to ourselves, “we are pretty good at this stuff!”  It is a little too early to celebrate because we now need to look at inter-project dependencies.

There are whole books written on the subject of how to itemize, track and measure inter-project dependencies, so I am not going to try to reinvent the wheel or cover all of them here, but conceptually it is important to look at how the list of projects interact, depend, sequence, or collide with each other.

A visual mapping exercise can be the most effective way to accomplish this.  

My biggest piece of advice is to start simple.  Don’t try to tackle every aspect or dependency on your first go.  The basic items you want to look at are:

• Timing dependencies with other projects
• Resourcing dependencies with other projects
• Operational dependencies like critical infrastructure projects that need to happen before a project can start or complete

Many projects can run in tandem to a point, but the “go live” of each must be staggered because the dependencies say so.

The most widely used approach to inter-project dependency management is to use a DSM (Dependency Structure Matrix) tool or framework.  

There are limitations in this approach if you are trying to account for any more than 2 or 3 dependency items or data points.  The complexity becomes too much to effectively fit into the DSM “box”, but I would advise at least becoming familiar with how to use a DSM because you can use concepts and elements of it to come up with something that works for you and your organization.

Go through the project list and do a dependency mapping exercise to level of detail you can.  This will help you sequence the projects in a way that is practical.  It will also show which projects are going to run into trouble and collide or stall out because they depend on another project or component of another project to successfully be executed.

This stuff is challenging.  Hopefully we are all sharing and learning together taking the nuggets and pieces that work best for us and leaving the rest.

If any of you have come up with a simple but effective inter-project dependency mapping approach, please share by adding a comment below or Tweeting it to me @ScottTWaters and I will be sure to share it.

 

Project Management and Resource Planning: Prioritizing of the list of demands pt.3 – Applying filters

Even when an organization has developed a project and resource prioritization methodology and framework that fits its culture, and it is understood by the stakeholders and decision makers, it can still feel overwhelming to get that list of 100+ project requests down to something doable.  After all of the work has been put in to prioritize the list of demands, what can be done to avoid playing a game of “Wheel of Priority” with the list?  We certainly don’t want all of the planning work to be wasted and to have things fall back into disorganization and chaos before the year/cycle has started.

So how do we reduce the “noise”?  In the end, we need our final list of approved projects to fit the following criteria:

• be aligned with organizational goals
• be supported by the Executive leadership team
• be understood, at a high-level, by the larger leadership group
• fit within the resource constraints of the organization (time, money, people)

A simple way to get to the “final” list is to go through the priorities list from the top (#1’s) to the bottom until all of the resources are exhausted and draw the line there.  Anything under the line just won’t be done this cycle.  Make no mistake, this will have to be done and is a tough pill to swallow for any of the project owners who have projects that do not make the cut.  But we must remember, this should not be taken personally.  The best leaders are passionate about what they do which is part of what makes them great leaders, but it is important to take a step back and look at the greater good of the organization and take our personal feelings out of this process.

There are things we can do to make this work easier and more aligned.  Ideally, strategy (which creates projects) should inform the budget but sometimes we can use the budgetary process to “filter” out projects from our larger list because they are not going to be funded.  So whenever possible, use a cross-walk between the budget (both CapX and OpX) process and the project/resourcing process so that we can eliminate anything from the project list that will not be funded.  Remember “no money, no mission”?  Well, “no money, no project” applies as well, if the project is not purely a process improvement project that doesn’t need funding.

If you tie the budget and project/resourcing processes together, you will find that they can help each other out by eliminating projects or budget requests that are not going to make the final cut for the upcoming year or cycle.

There are other “filters” that can be applied in addition to the budget or “money” filter.  Physics apply as well.  Time is a constraint that can also help filter out projects that are competing for the same spot on the calendar.  Sometimes, you will find that there is simply not enough time in the year or cycle to do a project or multiple projects no matter how much you increase the funding or lower the quality requirements (remember the Time, Cost, Quality Triangle?).  The time filter can be an important aid to eliminate a number of projects on the list.

Do you have any “filters” that are helpful in whittling down a list of projects that is larger than can be done?  If so, share them by putting them in the comments section below or by Tweeting me @ScottTWaters.  I look forward to hearing from you.

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.