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

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 this post, I want to discuss what may seem like a nuance, but is actually very important.  That is the importance of estimating the effort that will be expended on a task / project.  Many organizations simply collect the duration.  The duration is the amount of calendar time that is required to complete a particular task or project.  The effort is the amount of actual, dedicated work that is needed to complete the task or project within the duration period.  For example, "Creating a Design Document" may take 5 days (the duration) to complete, but John has other things he will be doing during those 5 days.  Over the course of those 5 days, John will be working for 12 hours (the effort) on "Creating a Design Document".

Why is this important?  Because when it comes to resource utilization, the effort is all important.  That is a fundamental building block.  How much time will a resource need to expend on the task?  The duration will not cut it.  You have to know the effort.  And there is no magic shortcut.  It is not as simple as saying "ok, let's start tracking effort."  It takes time and discipline to produce good estimates.

For some tips on how produce good effort estimates, let me turn to an old blog post by Tom Mochal in TechRepublic.  Included in his recommended steps are the following:

• Create the initial estimate for each activity (task) in the project (this implies that you need to break down your project into these activities / tasks.
  
• Add specialist hours (hours from experts, specialists, indispensable folks that will inevitably be needed).
• Consider adding rework hours (most likely the task will not be 100% correct the first time).
• Add project management time (time to do the project management).
• Add contingency hours (to factor in the uncertainty of your estimate).

I would also add that you need to start tracking historical records of how long things actually take.  That allows you over time to gradually improve your effort estimates and assumptions.

It may be a big step to perform these steps right away.  In that case, start small and gradually add more maturity to your estimating process as people become more comfortable.

Of course, it can be difficult to follow the steps above all the time.  We are bombarded by imposed deadlines from stakeholders, management, clients, and others.  But as I said, there is no magic shortcut.  If you indeed want accurate resource utilization, you will have to go through the "effort".

 

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

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).  This includes project and non-project work.

The second key step is to predict as accurately as possible when that work will be done.  In other words, you need to schedule it.  How you schedule it is another matter.  It could be a typical Gantt chart schedule (aka waterfall).  It could be an agile iteration or a sprint.  But you cannot get away from the fact that if you want to know how your resources are going to be utilized in a given time period, then in your project management software tool, whatever that is, you have to have accurate predictions of when work will be done.  How else could you look at the month of July and have any idea what and how much your resources will be working on?

Does this mean that you need to schedule down to the nitty-gritty detail level?  Not necessarily.  Again, it depends on the level of utilization reporting you want to get out on the back end.  That is the level of detail that you need to put in on the front end.

In other words, you can draw a fine line so that you do not get too carried away with 100% accurate schedules.  What are the time frames for which you want to look at resource utilization?  By week?  By month?  Let's take by month as an example.  If you are mostly interested in the figures for the month as a whole, then what do you need to make sure of in your schedules?  You need to make absolutely sure that the work that will be done in July is properly scheduled for the month of July.  It does not mean that you need to be as concerned with the day it will be done.

Similarly, if you want to look at things by week, then you need to be sure the work scheduled for each week is accurate.  Again, it may not be necessary to have the exact days 100% accurate.

There is not a magic button or tool.  If you want truly accurate resource reporting you need to continually do the work to capture the necessary up front data.

Key Steps to Achieve Accurate Resource Utilization Reporting: Part 1

Many organizations want to know how their resources are utilized.  In fact, this can be critical to organizations that rely on proper resource utilization, such as a consulting group, a professional services organization, or an IT group overburdened with project requests.  In my experience, accurate resource utilization is hard.  It is not easy, it takes discipline, and it involves more than many organizations realize.

This is the first post in a series to help you achieve accurate resource utilization reporting in your project management software tools to support proper resource management.  In this first post, I will cover the first key step that is necessary.

Let me cover one point before that.  When I am using the term "resources", I am referring to people.  How is the organization using its people?  I understand that "resources" is a broader term and can encompass things like materials, money, or machinery.  We are going to focus on "people resources", as they have the most impact on the most organizations.

With that out of the way, the first key step to achieve accurate resource utilization reporting is to capture all of the work.  In other words, you cannot accurately determine how much work a resource has on their plate at a given point in time if you have not captured all of that work.  In concept it seems easy, but in reality it is not.  There are some considerations that play into this.  This means that you must:

1. Develop a good work breakdown structure (wbs) for every project.  You have to capture all of the work that will truly be needed for every single project out there.  And it needs to be detailed and accurate.  In other words, if your work breakdown structure includes a line item for "Implement Product at Client", that's probably not going to cut it.  You need to have enough detail to accurately know how many hours it is going to take to do this.  Read my previous post for tips on how to do this.
   
2. Capture non-project work.  Most people do not devote 100% of their time to project work.  They have some day-to-day operational or maintenance tasks.  This is part of their workload as well.  They attend meetings.  They go to training.  These have to be captured.  There are generally a couple of ways of handling this type of work.  You could capture all of this work, just as you have done for your project work.  Or you could estimate the % of time each day that people spend on these things.  For example, you could estimate that 40% of a person's day is consumed by non-project work.  This gets into the topic of capacity which I will expand on in a future post.

A quick note.  Do you have to have a good, detailed work breakdown structure with estimates?  No, you don't.  But the accuracy and detail of your reporting will correlate with that.  The less detail and accuracy in the work estimates that you have captured, the less detail and accuracy you will have in your reporting of resource utilization.  You will have to decide the right balance.

 

5 Things You Are Not Doing (But Should Be) With Your Project Management Software Tools

Almost all of us have project management software tools that we use on a consistent basis.  It may be true project tool, a spreadsheet or even email, but it is still a software tool we use to help manage projects.  Here are 5 things that you are probably not doing right now with your project management software tools (but you should be).

1.  You are not looking at trends or historical data.

Most people are consumed with the present and the future.  Which tasks need to be done and which are coming up?  Trends are important.  If you do not look at trends or historical data, you will never get better.  Trends tell you tasks that are typically not completed on time, how much time items really take, who your resource choke points are, and even opportunities for process improvement.

2.  You have not matched technology and process together.

Technology only provides significant value-add when it is married together with a good process.  The technology should support that process.  Many people implement technology without a good process in mind.  In other words, they are focused on the features of the technology (aka "a way to schedule our projects") instead of being focused on implementing their process.  Or they have implemented technology without a documented process in the first place.

3.  You are not taking advantage of automation capability.

Even organizations that have sophisticated project management tools tend to not take advantage of the automation capabilities in the tool itself.  They still spend an enormous amount of time doing things manually that could be done in more of an automated fashion.  For example, you may be tracking your schedules in a tool, but you are also continuing to fill out documents (with duplicate information) and passing them along in your process.

4.  You do not have a meaningful dashboard.

Organizations may have a dashboard, but many organizations do not have a "meaningful" dashboard.  Either no one is looking at it or when they do look at it, it does not tell them what they need to know to make decisions.  This is because no one has spent the time to discover what information is truly meaningful or the data in the tool is not up to date.

5.  You do not have anyone overseeing the tool set.

Tools are like anything else.  If you do not spend any time overseeing the tool, it will not be used effectively.  That means that you need to have someone whose responsibility it is to make sure the tool (and the information in it) is clean and useful.

Are you guilty of any of these?  Most of us are not perfect in the use of our project management software tools.  Pick one and work on it and see what results you get.

 

4 Quick Thoughts on Buy-In for Project Management Software Tools and Processes

Following up on my last post on how much buy-in is necessary for a successful project management software tool roll out, a question remains: how do you achieve buy-in?  This is not an easy question, but here are four quick thoughts on how to go about it:

1.  Accept the buy-in that you can get.

In other words, be content to start small.  You may not get the home run, organization-wide buy-in right away.  Start where you can and prove your ideas.

2.  Plant seeds.

Sometimes an organization is just simply not ready yet.  But you can plant seeds in a professional, courteous, and tactful way.  Forward an article you read as an idea for something in the future.  Let someone see the results you are getting in your own small area.

3.  Bide your time.

Sometimes the timing is just not right.  Perhaps there are too many things going on for the organization to buy-in right now.  Bide your time.  At some point, an event is going to occur which will put the organization in a better position to be open to your ideas.  Perhaps a new, key manager comes in who is more open to the idea, or perhaps a major failure occurs and there is a call to action.  You never know when or how quickly things can turn.

4.  Be prepared.

Know what you want to pitch and how to pitch it.  Show what you are accomplishing in your own area.  Show what other organizations have achieved.  Have a process mapped out for how it could be done.  Be prepared for the right time.

 

How Much Organizational Buy-In Is Needed for Project Management Software Tools to be Successful?

This is a question that I have been contemplating again.  Project management software tools need have buy-in to be successful.  That is especially true of management.  You need to have management buy-in, otherwise no one will use it.  It is not as much true of team members that are further down the "totem pole".  It is certainly great to get their buy-in and we should diligently seek that, but sometimes it does not matter how great a solution is, there will be resistance because it is different.

So do you need organization buy-in throughout an organization in order for a project management software tool to be successful?  Does the CEO need to buy-in to it?  Ideally, the CEO and the entire organization buys into both the software tool and the business processes it supports, and that does happen.  However, often times you might as well play the lottery, especially if it is a large organization.  You will have just as much of a chance of making it happen.  The question is...can you still get value from the tool?

The answer is...it depends.  How big is your organization and what do you want to accomplish with the tool?  Here are some principles for you:

1.  There must be a clear purpose for the project management software tool.  What are you trying to accomplish?  Understanding resource loads?  Providing visibility into project status?  Stopping tasks from falling through the cracks?  Centralizing information?

2.  There must be business processes that the tool supports.  The tool is only as good as the processes it is designed to support and automate.

3.  The purpose and processes must be associated with a team / group / department / organization.  In other words, are you trying to accomplish this purpose for your team?  Your group?  Your department?  Your entire organization?  Who is involved in the process?  Just your team?  Your department?

4.  Buy-in is needed throughout that sphere.  For example, if you are trying to understand resource loads for your team, then you need buy-in from the team, especially the leaders / managers of the team.  If you are trying to provide visibility into project status for the whole organization, then you need buy-in from the top of the entire organization.  If you are trying to use the tool to automate a process, then you need buy-in from those that participate in that process.

Do you agree or disagree?

5 Principles For Project Teams To Work Better

I recently wrote a white paper on 5 Principles For Project Teams To Work Better.  One of the principles deals with automation so it is applicable to this blog on the implementation of project management software tools.  You can download the white paper at the URL below.  I would appreciate any thoughts or comments that you had!  You can comment or email blog@teaminteractions.com.

White Paper: 5 Principles For Project Teams To Work Better

 

More Tips for Great Dashboards in your Project Management Software Tools

As a follow-up to my post from earlier this week on keys to an exceptional dashboard, I came across an article in CIO magazine by Chris Curran on "10 CIO Dashboard Tips."  It is geared towards an IT audience, but has several good tips nonetheless.  Here are a few that I liked:

Make sure you can actually collect the data you want to measure.

It does not good to show an earned value statistic, for example, if you do not have good work breakdown structures.

Begin by summarizing and analyzing data you already collect.

You may find some good analysis for your dashboard right off the bat.

Create a report to perform checks and balances on core dashboard data to increase credibility.

The companion report would provide some detail from which the dashboard data is derived.  This increases everyone's confidence in the dashboard data itself.

Have a printable version of the dashboard.

This way people can easily take the information with them.

 

You can read the full article with all the tips here.  Enjoy!  And have a great weekend!

5 Keys to an Exceptional Dashboard in Your Project Management Software Tool

Dashboards are not created equal, even dashboards that display the same information.  One organization may have a vibrant dashboard that is used by everyone reliably.  Another organization may have a stagnant dashboard used by no one.  What makes the difference?  What are the keys to implementing a good dashboard?

Here are five keys to implementing a fantastic dashboard in your project management software tool:

1.  Keep it Simple

Some dashboards are overly complicated with too much information, or information that is too complex.  Keep your dashboard simple both in terms of the layout and the information presented.  Do not make it too complex.  Someone should be able to glean significant information from the dashboard in a matter of seconds.  If it takes a lot of effort and time for them to glean information, it will not be effective.

2.  Your Dashboard is Only as Good as the Data You Enter

It does not matter how fancy of a tool you have, how nice the reports are, or how fancy the presentation is if the underlying data is not solid.  In other words, all a dashboard does is present data that has been entered by people.  If people are not entering data correctly, or are not regularly keeping the data up to date, then your dashboard will be useless.

3.  Stay High-Level with the Ability to Drill-Down Into More Detail

It is easy to get lost in the minutiae of adding all of the significant detail to a dashboard.  That is not the purpose of a dashboard.  The purpose of a dashboard is to provide a high-level overview so that the viewer knows what action to take.  The viewer may then need the ability to drill-down into more detailed information, but this information should not all be displayed in the dashboard itself.  For example, it may be important to the viewer to know which projects need attention - perhaps a green / yellow / red indicator is attached to each project or portfolio.  However, the individual tasks, milestones, or issues that are causing the indication would not normally be displayed.  Those would be available upon the viewer drilling down further.  The exception to this would be a team member-level dashboard whose specific purpose is not to provide insight but to communicate a lot of detailed information, such as their current tasks.

4.  Only Present Actionable Information

There is a tendency to put information on the dashboard because it is neat and because you can show off the fact that you know the percentage of tasks within a portfolio that begin with the letter "M", started the Monday after a holiday, and the number of letters in the name is divisible by 2.  However, no one is going to use this information so there is no reason to display it and no reason to collect it.  The dashboard should be a tool where information is displayed that viewers will consider relevant, that they will actually look at, and that they can take action on.  Ask yourself whether the information in your dashboard meets this criteria.

5.  Don't Forget Training

 No matter how simple your dashboard may be, do not assume that people understand what they are seeing.  Sometimes there are nuances in language or procedures that are interpreted differently by different departments, people, and organizations.  Provide some training so that people know they are using the information in the dashboards appropriately and effectively.  I am not talking about formal training, but either holding periodic brown bag lunch sessions and / or providing a one-page cheat sheet on the information presented.

What other keys have you seen make a dashboard effective?

Happy Dashboarding!