« June 2011 | Main | August 2011 »

6 posts from July 2011


A Solution to the Resource Management Problem

IStock_000012107875_web Resource management is often characterized as the number one problem facing project-centric organizations (see here for an example).  There are so many "sub-problems" associated with the term "resource management", but I am primarily talking about the issue of resources not being allocated efficiently.  For example, they are not available because they have been over allocated, resulting in the delay of key projects.

There are also many good suggestions and ideas to deal with this problem such as:

  • Using central resource pools
  • Develop a good process of making resource assignment decisions
  • Setting project priorities
  • Using a tool to help see resource utilization issues

However, here is a tool that can help resolve many situations and does not require a huge organizational strategy, top management buy-in, or rigid procedures.

What is this tool?...simply for project managers to talk with each other.  When we are reasonable with each other and communicate well, projects managers can take a big step towards solving this problem.  After all, isn't that why we are there?  What do I mean?  If you have a group of project managers running different projects, it makes no sense to pilfer each others resources haphazardly.  It may benefit you immediately, but it will cause you much more harm and pain long-term.  No one wants that.  By the way, by "project managers", I mean anyone who has the responsibility of managing a project.  You don't have to have the title or a fancy certification to do this.

So take the initiative, sit down with other PMs, and talk about it.  Meet together and review each others resource needs.  Where are the resource bottlenecks?  Find a way to solve them.  If there are unresolvable conflicts because of competing high priority projects (make sure this is really true - everyone's project is "high priority"), then you can escalate and communicate to more senior management for a decision.  But I think that many conflicts could be resolved by simply having a reasonable attitude, and working together.

I recognize that there may very well be more complexities than this.  You may need to go to a functional manager to request a resource, for example.  But least you can do it in a coordinated way, instead of 3 project managers going to the same functional manager for the same resources.

Of course, that means that everyone needs to be willing to work together.  I understand that is not always the case.   But in many experiences, I have found that if you treat people well, they are more than willing to work together.  It is certainly worth a try.



4 Questions to Answer Before Presenting Project Management Software

IStock_000000077653_L2_smal We have covered a lot of ground in this blog about how to implement software, best practices, even how to select it.  One thing that we have not covered much is how to get buy-in from other people to implement project management software tools.  This can be hard to do for several reasons:

  1. People do not like to change.
  2. No one wants to take on another effort.
  3. People are too busy fighting fires, much less trying to address the root causes of the fires.
  4. People think what they are doing is just fine.

Just this morning I read a blog post by Ted Hardy at the Better Projects blog.  In his post, Ted walked through how he brought an idea to his team and achieved their quick buy-in.  I want to expand on Ted's post and give you four questions that you need to answer before presenting project management software to your organization.

What's the problem?

If you are going to implement project management software because it sounds like a good idea, don't bother.  It has to be tied to a problem.  What problem will it solve?  How will it provide value?  Ted's value proposition was that his idea would provide data that they didn't have today in order to solve quality problems. The problem should be your focus and will drive how you present it as well as how it is implemented.  Perhaps you have projects that are continuously late and no one knows why.  Perhaps you are making promises to your customers that cannot be kept, because no one has the data to say when something will actually get done.  Perhaps you know you have resource bottlenecks but have no data to prove it or to show where, how, and why the bottle-necks are occurring.  Perhaps you have documents or other information strung all over the place in spreadsheets, whiteboards, files, and post-it notes so no one can find key information when they need it most.  These would be examples of real, definable problems on which you can focus your "pitch".  If you have a solution that can solve a real problem, that is a real value-add.  And that is much easier to present than a vague benefit.

What's the process?

Do not focus on the project management software tool itself and its "cool features".  Focus on your process.  The software is simply a tool to implement, run, analyze, and improve your process.  When you present this, you don't even need to focus on "implementing a project management software tool".  You can focus on implementing a process (and using a tool to help you do that).  The software can and should take a backstage approach.  If there is too much focus on the software tool itself, than there is not enough focus on the process and the underlying problem.  So what is the process that can be implemented (or changed) to fix problem x (defined above)?

What's in it for them?

Why should people do this?  What will they personally get out of it?  Perhaps it is some key reporting to save them from doing hours of manual data manipulation.  Perhaps it is to remove a headache that plagues them day in and day out.  Put yourself in their shoes and be sure you understand and can articulate how they will specifically benefit.  You could mock up some sample reports to show people (be sure they will realistically be available), and even quietly get feedback on them before even expressing your idea ("do you think it would be helpful if you could get information like this?").  Go to lunch with people and explore what problems they have and what would be a real benefit to them.

How will you implement?

Do you know what steps you will take?  Will you phase it in or try and do everything at once (phasing it in is highly recommended)?  Will you have a pilot group?  Who will be in that group?  What processes will you implement at first?  What will they look like?  What problem will they solve immediately?  What will people be able to get out of the tool right away that will help them?  How long will it take?  How much time will it take from people's day?  These are all questions that you need to answer before making your presentation.

The bottom line?  Be prepared.  In Ted's post, he had an idea for something that would really help the team and the organization.  He did his homework and explored the idea and what it would take.  But even then he didn't present it.  He let it ruminate for a while which gave him time to think it through and thoroughly understand his approach before presenting it to the team.  It worked and unless you are dealing with a dire situation that requires an immediate solution, it's a good approach.




Characteristics of a Highly Configurable Project Management Software System

IStock_000006331752_web I read with interest last month an article on what makes software configurable.  Interestingly, the article was focused on insurance software applications.  You can read the article here (you need to get into page 2 and 3 before getting into the meat of what configurable means).  Certainly parts of this article would not apply to many of us.  For example, we do not need an engine to define rules for insurance products.  However, there were several good insights here that I have taken and expanded to come up with my own list for what makes a project management software product configurable.

1.  Web Client

As stated in the article, a configurable solution should have a web client (even if it is not exclusively a web client).  This makes it easy to deploy and access.

2.  Rules and Processing Options

My own experience has shown that organizations are very different in how they do things and how they have defined their own processes.  This holds true even for organizations that are in the same industry or market.  Configurable software will allow for this by providing flexibility in how things are done.  For example, it may provide an option in the scheduling of projects to allow for the automated update of schedules vs. the manual update of schedules.  Or it may employ a notification scheme that provides flexibility in how reminders and notifications of events are sent to project personnel.

3.  Ability to Extend What You See

One of the big areas of differences in organizations is the amount and types of pure data that they track.  Let's take a simple project.  One organization may simply want to track the Project Manager, start date, due date, percent complete, and some notes.  Another organization may have a list of 30-40 information fields specific to their process that they need to collect, track, and report on.  These may be things like who the customer is, the contract specifics, billing scenarios, project type or classification, current project status, etc.  A configurable project management software tool will make it easy to extend what you see to accommodate this.  This means that screens, reports, fields, and similar vehicles can be changed without programming actual code.

4.  Integration

Project management software no longer sits by itself.  It needs to integrate with the systems around it in the organization.  This means that the software needs to have a mechanism to integrate with other systems technically.  It also means that it needs to be flexible to mold that integration in different ways.  For example, an organization may want to integrate it with a separate time keeping system, or another organization may want to integrate it with an accounting system.

5.  Reporting

Reporting is a huge part of being configurable.  Static reports are no longer enough.  A configurable system will enable the creation of ad-hoc reports.  You would be amazed at all of the different reporting desires I have heard over the years.  Just when I think I have seen it all, someone will throw out another reporting need.  If your project management software system does not have the ability to create reports with different filters, groupings, criteria, sorting, etc., it is not configurable.

I am sure that we could go on with a long list.  What other characteristics do you believe should be in a configurable system?


Key Steps to Achieve Accurate Resource Utilization Reporting in Your Project Management Software Tool: Part 6/6

IStock_000004563504X_web This is the last post in a discussion on how to achieve accurate resource utilization reporting, and thus good resource management, in your project management software tool.

In part 1, we discussed the key of capturing all of the work to be performed by your resources (people for the purposes of this series).

In part 2, we discussed the key of accurately capturing when the work will be performed.

In part 3, we discussed the key of capturing the effort as opposed to strictly the duration of the work.

In part 4, we discussed the key of capturing the true capacity of your people.

In part 5, we discussed the importance of process, discipline, and the right tools.

Now let's pull it all together and wrap up this discussion.  There are some random but key, underlying points to keep in mind as you work towards building good resource utilization statistics.  Here they are.

Maintaining Resource Utilization Statistics Is Not Easy

Do not go into this blindly.  This is not an easy, little additional task to do.  It requires a fair amount of work and it requires really everyone to do their part.  It can be well worth it in the end, but go into it with your eyes wide open.

You Must Know What You Want

What are your objectives?  What do you need to see when all is said and done?  If it is to feel good that you know what everyone is doing, don't bother.  If it is a specific goal, such as to increase the utilization of your key resources, then go for it.  Similarly, this will help you determine the level of detail you need (and thus the level of maintenance effort required).  If you need to make day in and day out decisions on resource assignments, then you need to be very detailed and go all out.  If you simply need to make monthly presentations to management, then you can probably relax on some of the detail and strike a good balance between getting enough detail and getting more than it's worth.

Work Backwards

I would map out what you want to see in a report when all is said and done, and then work backwards to collect the data that will enable that report.  In other words, start with the end result.  Once you have that, go backwards.  If your end result is to see a % figure of utilization for each week for each resource, then you can start to map out a process to collect utilization figures each week.

Implement in Phases

You do not have to bite off everything at once.  Start small and work from there.  Create a long-term plan for getting to your ultimate objective.  You may simply start by creating better work breakdown structures (then you could even do something like assign a generic / default percent of effort for a rough estimation of everyone's utilization).  Then after everyone is comfortable with that, you may start adding effort estimation to your work breakdown.  This tends to work better than to do everything all at once.  If you have to do everyone all at once, then be sure and run a pilot.  Choose a few projects and a few people and work through the process.  You will find that you will change and tweak it to work out the kinks - and better to do that with a few people than with everyone.

Resource utilization can be a powerful tool, even a differentiating tool because it is not easy for organizations to do it well.  Write me at blog@teaminteractions.com with your own stories and insights as you implement this in your own organizations.




Key Steps to Achieve Accurate Resource Utilization Reporting in Your Project Management Software Tool: Part 5/6

IStock_000004563504X_web This is the 5th and second to last post in a discussion on how to achieve accurate resource utilization reporting, and thus good resource management, in your project management software tool.

In part 1, we discussed the key of capturing all of the work to be performed by your resources (people for the purposes of this series).

In part 2, we discussed the key of accurately capturing when the work will be performed.

In part 3, we discussed the key of capturing the effort as opposed to strictly the duration of the work.

In part 4, we discussed the key of capturing the true capacity of your people.

In this post, we need to talk about process, discipline, and tools.  Capturing resource utilization once, such as to present the results at an important meeting, is not easy.  There are no magic shortcuts.  Capturing resource utilization continually over time is even harder.  That takes a few extra ingredients.

First, you must have a documented process on which everyone is trained to continually capture accurate resource utilization.  It needs to include the elements that we have discussed in these posts.  For example, how will your organization capture the work to be performed?  How will it estimate when it will be performed and the amount of effort?  Who will maintain the true capacities of people in your organization?  How will this information be reviewed for accuracy.  This will not just happen.  Your team needs to know the expectations.

That requires discipline: a steadfastness to continue doing this because the benefits are huge.  Many organizations try, but not that many truly have the grit to manage their resources in this way.

And it also requires the right tool.  You will essentially be tracking a lot of data.  You need someplace to store that data.  You need a tool that can calculate the utilization numbers.  This can be a project management software tool such as ours (EnterPlicity) or it can be an Excel spreadsheet, but you need to have a well organized tool that is properly maintained with all of this data.

Process, discipline, and tools.  Make sure you don't forget about these.


Key Steps to Achieve Accurate Resource Utilization Reporting in Your Project Management Software Tool: Part 4

IStock_000006399293X_web This is another post in a discussion on how to achieve accurate resource utilization reporting, and thus good resource management, in your project management software tool.

In part 1, we discussed the key of capturing all of the work to be performed by your resources (people for the purposes of this series).

In part 2, we discussed the key of accurately capturing when the work will be performed.

In part 3, we discussed the key of capturing the effort as opposed to strictly the duration of the work.

Now let's talk about capacity.  Capacity is a key measurement because it directly affects your resource utilization statistics.  Capacity is the amount of time that a person has (in reality) to do the work.  For example, they may work 8 -10 hours a day, but in reality they wear other hats and may only have 4 hours a day to do project work.  That is their capacity.

Why is this important?  Because you cannot accurately decipher and make decisions from your resource statistics without it.  You can see how much work has been allocated to them.  You can see when that work has been allocated.  But you do not know if that is too much work, not enough work, or the right amount of work.  For that insight, you have to know the resource's capacity.

Once you know the resource's capacity, then it is simple math to figure out key metrics such as their allocated utilization (the work that has been allocated divided by their capacity) or their availability (their capacity minus the work that has been allocated).

In order to accurately figure out a person's capacity, you need to include the following factors:

  • Non-project activities: how much time does the person need each day to work on non-project activities, such as meetings, administrative activities, and while we don't like to admit it social conversations and breaks.
  • Vacation: a person's capacity is 0 if they are not there.  Forgetting to factor in vacation can ruin your resource picture at a critical point in the project.
  • Training: are there training requirements that the person must fulfill which affects their overall capacity?
  • Holidays: don't forget about company holidays.
  • Full time vs. part time: is the person working full-time or are they working part time?  Part time does not necessarily mean they are a part-time employee, but they may have multiple responsibilities with project work being only one of their responsibilities.

There are different strategies for capturing this.  You may factor all of these together for the entire year and create an average capacity per day.  Or you may create calendars that keep track of their specific capacity over specific time periods.

This may seem like a lot so let me make the point again about accuracy.  You do not necessarily have to track all of this to the nth degree.  It depends on how accurate you want the statistics to be when you do your reporting.  Which means that you need to decide what statistics and the level of accuracy you need in order for you to make decisions.  If you need accurate, detailed resource statistics, then there is no magic waving of the wand - you have to go through the effort of accurately collecting the base data.  And capacity is one of those pieces that you need to capture.




The EnterPlicity Project Tools blog covers all areas of effectively tracking, managing, and using your enterprise project data.


Subscribe by email:


What is EnterPlicity?

EnterPlicity is project management software that enables your organization to extend project management software tools to everyone, share any project information, automate key processes, and analyze project data in a single, easy to implement system.