Category: Articles

Home Articles

My interview with Nathan Latka on Top Entrepreneur is now live!

As promised, my interview on Nathan Latka’s Top Entrepreneur Podcast is now live! Nathan and I discussed my company, HMS Software’s history as a premiere publisher of timesheet software and the rise of TimeControl as one of the most popular timesheet systems. I was delighted to do the show and had a lot of fun with Nathan during the discussion. I encourage you all to grab the free podcast and take a listen.

The Top Entrepreneur podcast can be found on iTunes at: (it’s episode 1209) or from your desktop on Nathan’s site at:

Did you see my interview on the B2BNN?

I had great pleasure of being interviewed a few days ago by Dave Gordon for a piece in the Business to Business News Network. The piece was recently published under the title Inside the Mind of… Chris Vandersluis.  Dave has done a number of interviews like this over the past few months and I was delighted to be included.  The interview is designed to help entrepreneurs know how companies like my own HMS Software have been able to navigate the increasingly challenging business and economic landscape.  Having been in business since 1984, we had a few things to talk about.  I encourage you to give the piece a quick read.  You can find the article at:

Project Automation must enable process, not replace it

If projects were always predicable we wouldn’t need project managers.  We’d just authorize the project based on what estimators had determined and then on the expected finish date, we’d pick up the completed project with the actual costs exactly meeting the projected costs.

Sadly, that’s not the case.

The work of project managers is so important because life is so unpredictable.

In the face of almost everything challenging in our world, we have come to turn to technology to fix our problems.  We expect that just like a calculator was able to give us the answers to complex mathematical problems in instants rather than the much longer time it would take us to do it manually, technology will solve everything for us at the push of a button.

So it’s probably no surprise that we often give so much attention to the automation of project management in the hope that it alone can solve our project problems.  Estimate not correct?  Better estimating software will fix that.  Quality of the project not up to standards?  Better QA Software will fix that.  Project late?  You need better project scheduling software.  It will fix that.  Project overbudget?  Cost Control software will fix that.

If only it were so.

In each wave of new technology we count on it to fix our challenges.  When PCs took over from mini and mainframe computers, early adopters of the new technology released PC-based project management software.   The license costs were 5% of the mini computer equivalents and project management software became available to almost everyone.  That will fix project management problems forever, we said to ourselves.

The Internet let everyone exchange data instantly from almost anywhere in the world.  “Ah, that will do the trick,” we said.  Project Management data could be freely exchanged in an instant.

New technology waves that are more recent include the migration of many software systems from PCs and internal on-premise servers to Internet subscription systems in the “Cloud”.  Now even the installation and maintenance of software won’t hold us up.  We will be able to deploy enterprise project management in minutes instead of weeks as we used to do.

Mobile Smart Phones and Tablets use the vast cell phone network to connect our personnel to our centralized project systems 24 hours a day, 7 days a week.  Now even the commute to work won’t be a barrier to our project management.

But all of these wonders of technology have a massive underlying caveat.

Project Management is a process.

A process.

If we say that technology is the only thing that’s important in our project management environment, then what about training?  In the 1970s, project management systems would have cost hundreds of thousands of dollars and been available only to larger organizations who could justify the purchase.  The training that went into making sure that the technology would produce dividends was extensive.  It was not at all surprising to find people in weeks of training to follow the new project management process and to ensure that the use of the new software supported the process exactly.

With project management technology having been pushed to everyone, many have ignored the critical impact of the underlying process.  I have been asked in the past how long after subscribing to project software for the organization reports from it would be available on mobile devices.  It was a tough question.  Instantly could be the answer.  But that would be unfair.  The question itself has hidden expectations.

“Would you expect the data to be accurate?” I asked.

“Of course!” came the reply.

“Would you expect unapproved data to be visible?” I continued.

“No, I don’t think so,” was the less certain answer.

“Would you expect to see data mixed with every project in the entire organization, even those for individuals?” I asked.

“No, only the projects of interest to me,” came the reply.

“Then it’s going to take some time,” I answered.  “The data you are hoping for in your report will require approval processes, workflow, filtering, definitions of what data to include and how to distinguish it from other data and an agreement and understanding from everyone to work along similar standards.”

This was deeply disappointing to the executive who had already authorized the subscription to a large enterprise project management system.  They also had not allowed any time to create that process, to train their personnel or to maintain the process over time.

It’s a challenging combination.  Not only does a project management process need to be defined, if you are intending to use that process across all projects and all project personnel, then there is collaboration required as well as a monitoring of the process in some manner that will maintain what is important in it.

Some suggest that creating a central PMO (Project Management Office) will fix that issue.  But a PMO can be many things in many places.  Just the creation of a PMO will often reveal that the organization has internal challenges to sharing project authority and that there are many opinions on how to manage projects.  In some organizations, unseen internal incentives to be successful in one’s own project can run counter to cooperating with others so they too are successful.

As someone who works in the project management automation industry, you might think that I would be a forceful voice for automate first and think about how to use the software later but nothing could be further from the truth.  Like many in my industry, we have found that the most successful clients are those who use software like our own to enhance and improve the project management process, not replace it.

The Excel Attraction – what’s a project manager to do?

Several years ago I worked directly the Microsoft Project Team as part of their Enterprise Project Management Partner Advisory Council.  One topic that came up more than once during the 5 years I spent with the group was the impact of Excel on Project Management.  At the time Microsoft estimated that over 30 million copies of Microsoft Project were in use somewhere around the world.  Their own internal estimates were that over double that used Excel for Project Management.

So what’s the attraction of Excel?

As my wife said when I asked her, “You can get stuff done.”  (Ok, she didn’t say it exactly like that but this is a family show!

She’s right though.  Excel has been around for ages and it wasn’t even the first spreadsheet on the market.

In the early 1980s I was introduced to VisiCalc on a CPM PC and was mesmerized.  There was no end to the calculations and formulas I could create.  Yes, it was only text at that time but for those who had ever done bookkeeping in a hard covered wide ledger book filled with green pages lined with green lines, this was a miracle!  Not only did it catch my errors, it recalculated instantly.  Forget a line?  Just insert and there it was and the formula also caught the new update immediately.

VisiCalc gave way to Multiplan for me which Microsoft was selling.  (Yes, they sold a different spreadsheet before Excel!) and then in the late 80s of course, Excel and I’ve never looked back.

For project managers they have available a myriad of options for project management tools that do so much more specific calculations than Excel was ever designed for.  After all, Excel starts off basically with a blank page (unless you’re using templates of course).  So why is it still so popular?

In a short answer, not everyone needs the rigor of project management practices in order to be effective.  For many project management tasks, the exercise of getting all your tasks defined and all your roll-ups organized and all the rates and all the resources and all the cost centers can be an overwhelming bottom-up challenge.

Let’s say you just need to do a high-level budget.  Sure, you can do something in Project, but it can be so much faster in Excel.  And, once you have some numbers, generating charts and graphs is a snap.  The boss will be delighted.

Let’s say you need the same numbers but organized differently.  Well, there’s a Pivot Table if you’re so inclined but you might just copy/paste to a new tab and resort and recalculate.  Hey presto – solution delivered.

But, you say, I have complex multi-currency, multi-category issues.  Excel has shown time and time again that it has an almost infinite flexibility in extending formulae and calculation concepts into different directions.

So why don’t we abandon other project management tools and just use Excel?

The problem with Excel for project managers isn’t that it’s incapable, it’s that it’s such a great personal calculator tool that it doesn’t lend itself well to being a centralized source of auditable data and that’s where the mischief begins.

Some people create tools with Excel that become so popular that they are asked to extend the tool to more division wide or corporate use.

I’ve seen dashboards that start as a simple personal tool and then management asks why we don’t see all the projects in this format rather than just the ones from that individual.  It’s hard to say no when management can see the hard copy results right in front of them.  So the individual’s spreadsheet becomes a multi-page concept or even programmatic in nature.  Soon we’re using Excel’s data connectors to pull data from all kinds of sources.  Does it work?  Sure.  But there’s no audit of where the data is coming from.

So a tool that might have started as a simple display or calculator for one project manager finds itself stretching further and further and further until at last it is being asked to form the basis of a corporate tool.


Let’s take a look at a couple of examples from my own experience.

Excel Timesheets

One client of ours (to be fair, this has been the case for numerous clients of ours) had an Excel timesheet that started as a simple grid for a team of a half-dozen staff.  The creator was a project manager who was just trying to gather more data in the absence of a standardized timesheet.  The grid started as an Excel template (There are several) and the project manager populated this with some drop down choices for tasks and projects.  Each employee filled in a new file each week and emailed it to the project manager who then used a summary spreadsheet to read the results from predictable cells in each file and make a summary.

Worked like a charm!

In fact, it worked a little too well.  “Why can’t we expand this to the department?” our PM was asked.  So they did.  Now, instead of 6 files to collect, there were 60.  The work increased by an order of magnitude.  “Where are the missing files?” became an every week challenge.  When it was just the 6 of them, it was a matter of calling across the cubicle.  Now, people were all over.  Still, our PM prevailed, putting in the time to hunt down files.  With more people involved, some users felt they could be helpful by reformatting files from time to time to make them even more awesome.  That was a problem for our PM as his summary spreadsheet didn’t take into account freelance Excel helpers.  This meant manual manipulation of 5 or 6 files each week to make sure they worked.

Management didn’t see this extra work of course.  They were delighted.  “Let’s do this for all 300 of us,” they suggested.  Well, at this point, each week’s summaries became a logistical nightmare.  Every week there were challenges.  Some files wouldn’t appear.  Some people were sick from time to time or took vacation.  Files were altered and no longer worked with the summary page and had to be manually re-entered.  The amount of work had turned our once-eager project manager into an almost full time timesheet clerk and this left him frustrated.  Moreover, the summaries no longer were as efficient and management complained.

In the end, our PM was able to convince management that the one-time efficient process couldn’t possibly continue and if they considered how much time and effort was going into manually manipulating Excel files every week, it would be much cheaper to get onto a commercial timesheet system.

Migrating to TimeControl, which was how this turned out, was helped by TimeControl’s many links and support of Excel but one challenge of the deployment was the affinity for the existing process with people who had no idea how much manual effort was behind the scenes making it work.

Project Management

It started as a simple Project Update chart created by one Project Manager to see his projects and major milestones in a format that was easy for him to follow.  When we met him for the first time, his one-time Excel file had ballooned from 3 projects to 130 and was out of control.  Using Excel’s network functionality to link many network-saved worksheets into one summary, many project managers were updating files and expecting that that Project Management Office was able to see the current results as well as they could.  That wasn’t the case.

The PM who was in charge of the summary found himself working more for the PMO than as a PM because of the massive display on the centralized worksheet and while that might have been great for his career at one time, now it was doing damage to his reputation.  The centralized spreadsheet was rarely 100% up to date and, even if it had been, it was rarely 100% accurate.  In the end, management finally admitted that what had been a great tool for a tiny group was not well suited to a much larger group.  Interestingly, this same management had a tough time understanding why it would takes months to replicate the same dashboard view in an enterprise project system.  Creating the view wasn’t hard.  It probably took as long as it did in the original Excel example.  But, the view wasn’t reliable until the data was of sufficient quality that the confidence in the dashboard could be established.  That was all about process and corporate culture, not about technology.

So, are you saying we need to give up on Excel?

Absolutely not. Excel is an excellent tool for when it’s appropriate.   How we dealt with this in our own TimeControl timesheet product at HMS was to embrace Excel as a likely tool to be used.  We made imports and exports directly with Excel files.  We made it possible to save reports directly into Excel.  We allowed Excel dashboard views to be embedded right into a TimeControl dashboard.  We made numerous views of data saveable right into Excel.

This allows the centralized system to put the controls in place that make the data collected of appropriate quality.  If we use timesheets for billing or for payroll, we have to be sure the data is accurate.  Business Validation Rules and tests for missing timesheets are something that can be built into the application.  Automated reports can still be saved in Excel and emailed to recipients but all the manual intervention of a personal tool is taken out of places it doesn’t belong.

Excel will not go away.  Spreadsheets have made a place in our business lexicon that make them the go-to solution for many on-the-fly analysis.

Where we can run into trouble is when demands for a view of our data goes from personal analysis to becoming a programming challenge.  Then we’ve made our PM spreadsheet expert into a programming shop.  We can become more effective by making sure that the right tool gets applied to the right problem.

Resource Management going all over the place? You’re not alone

Resource management is a subject that I lecture on often and, perhaps more interestingly, is a popular topic.  You might think that after all these years of the promotion of project management practices and tools that resource management would be an old and tired subject but apparently not so much.

What is it that has solving resource management challenges be so difficult?  The first and most obvious answer is that we don’t all mean the same thing when we talk about it.  Depending on who you are your interest in resource management will be very different.  The project management tools industry hasn’t made this any easier.

In the last 20 years or so, the pm software industry has promoted the idea of having everyone in a single system working against the same goals.  The features and practices that were promoted showed how you could create the project management data for an organization in which data would flow from the very top of the company to each and every individual and then back up again; providing everyone with up to date data from the front lines to management.

It hasn’t been a resounding success for the users.  The software industry, on the other hand, has been very successful in entrenching the idea that each and every user will need access to a user license of the project management software.  That was a massive change from only a few years earlier in which such software was left in the hands of a few highly trained professionals.

How did we get here?

We started by lumping all possible stakeholders in the resource management process into a single pool of users with homogenous interests.  But that’s just not accurate for most organizations.  If we are looking at resources from an enterprise project management perspective, it’s worthwhile to distinguish out a few stakeholder roles and how their interests might differ:

Portfolio Decision makers

In the top of the organizational pyramid; these people are typically in senior management and they are the central point of control of the budget.  They really want to know what is possible to accomplish with our existing budget this year and what projects we could conceivably take on within our capabilities.  Portfolio Decision Makers are interested in resource capacity but they have little interest in who does the work.  Their perspective on resource costs are very high level and the work on resources at this level is completely analytical.  You might think of them looking at all projects in summary with a focus down to the major skill level.

The decisions that Portfolio Decision Makers will make include:

  • What projects to continue work on
  • What new projects to accept
  • What the priorities of projects are
  • Whether to increase or decrease the resource pool
  • Whether to push a project’s schedule to later or pull it earlier
  • Whether to contract out temporary resource capacity or hire more permanent resources

The input that Portfolio Decision Makers will require includes the duration and skill requirements for new projects, the updated progress of existing projects and an accurate inventory of resources and their skills and attributes.

Project and Resource Managers

In the middle of our organizational pyramid are a small number of professionals.  On the project side we have Project Managers and on the resource side we have resource managers.  It’s common to think of these two groups as the two axes of a matrix environment.

On one side Project Managers manage the project requirements.  They determine what kinds of skills the project will require and organize the project’s schedule around how it must be created.  The project manager will also be responsible for managing the project to completion.  They must make requests of the Resource Manager for those skills.  Project Managers will be interested in hearing from the Resource Managers what the skill inventory is and who will be allocated to their projects.  They will also be interested in hearing from the Portfolio Decision Makers what the project priorities are and what new projects are expected to arrive.  The Project Managers will be interested in resources analytically at the skill level when they create estimates for the Portfolio Decision Makers to use in their decision-making.  They will be thinking of resources in a commitment paradigm as individuals when they think of resource allocation onto their projects.

On the other side, Resource Managers are responsible for their department of people.  They must manage the inventory of skills that their people possess and ensure that they can meet the needs of the projects but also take care of the needs of the people under their control.  A Resource Manager will be responsible for the advancement of people in their careers as well as their training and experience.  They will work to fulfill the requests of project managers with the people they have.  Resource Managers will think of the inventory levels of skills analytically when looking to see who to hire and who to train.  They will be thinking of resources in a commitment paradigm as individuals when looking to allocation resources to a project manager for a project.


The people actually doing the work are the greatest number at the bottom of our organizational pyramid.  They have little interest in resources at the analytical level.  What resources need to know is what you are requesting them to work on next and what they need to tell you is what effort they have expended on what they’ve been working on most recently.

There are numerous other elements of what we’re talking about but just from this short list, it’s easy to see how resource management can end up going in different directions at once.  It isn’t uncommon to see project management tools used analytically with the results pushed to every individual in the organization.  It’s also not uncommon for project managers to think of this entire exercise just from their own perspective of getting their project accomplished and for resource managers to think in opposition to this of just managing their people.  It’s not surprising to see individuals throw up their hands in despair at being pushed and pulled by different requests and finally being managed by emergency.

So, what is the answer?  I find it valuable to distinguish the resource management exercise in two ways.

  1. First to distinguish analytical interests separate from commitment based interests. Here’s an easy example: A scheduling tool like Microsoft Project is an analytical tool.   (It’s no surprise that its biggest competitor is Excel.)  We have task data in our agendas such as an Outlook calendar.  This is a commitment tool.  I write in a task or a calendar event with a start and finish as though to say “I’m committed to do that thing at this time.”  We do that even when the commitment is to ourselves like “Vacation”.  When we mix the analytical with the commitment elements, our agenda becomes chaos.  There was a school of thought a few years ago that said that this data looks the same so it should be the same.  Not so.
  2. Next distinguish the roles of those involved and how their input and output will be managed. Some great software demonstrations show how data can flow upwards and downwards effortlessly but when you look at the groups separately, that doesn’t always make a lot of sense.  Data at the Portfolio level will be summary level and may only be looked at once or twice a year.  At the project manager analytical level it might be every week.  At the individual time reporting level, every day.  Should they all be part of the same process?  That’s not at all certain.  Sometimes it’s better to have an integrated process and less integrated data.

The different needs of the different roles means that handing off data as a report rather than a data transfer may be much more effective.  The physical delineation of the data can make a clear moment of hand-off of responsibility in this way.

Building a process will be more than choosing tools and the resource management process is really multiple distinct but interrelated processes.  Take your time to make sure all your stakeholders are getting what they need.

Can you be the same but different?

“Can your system help us? We have two distinct groups.”

This is a remarkably common request here at HMS. In our case we’re talking about how to take care of timesheet collection for multiple groups using our TimeControl timesheet system but the request is common to many project management environments. 

This comes up whenever we have multiple groups trying to use the same project control environment. From one perspective, there are many benefits to grouping data together.  From a very different perspective, there may be many legitimate reasons to keep the data apart.

Some project systems have tackled this by using multiple project environments where independent projects are somehow linked together. Other systems use filtering to keep the data in one place but act as though it is distinct.

Let’s take a look at the benefits and challenges of each approach.


In a combined environment, all project management data is in one database. Some of the benefits of this include:

  • Global reporting
  • A single system for technical maintenance or licensing and;
  • One set of standards

There are, however some immediate challenges:

  • Difficulty supporting different system settings. This can be as simple as the number of working hours in a day or the time zone of one group vs. another
  • Individual group reports
  • Different forms of analysis by group

The decision to group data together can deliver some economies of scale that is often worth the challenges if, the distinct requirements of each group can be somehow met.


In a separated environment, each group maintains its data in a distinct database or instance of the system. There some benefits to this too:

  • Each group’s setup is easier to define and deploy as there is no compromise to be made for the groups of other requirements
  • Security can be wrapped around the entire environment instead of within the system.
  • Standards are faster to determine as only this group must be accommodated

There are challenges to this environment also.

  • Global reporting can be either impossible or, at least much more challenging than in a Combined environment.
  • Multiple systems or instances must be maintained technically
  • The lack of centralized standards will carry forward to process and procedure and this will make interpreting the combined data as much more challenging

So? Which is best?

There is no obvious answer to this question. But, as a system publisher, we have had to tackle this challenge.  Our decision with TimeControl was to prefer Combined environments.  But, even as we created the support for this, we have been faced with how to support the individual requirements to allow each group to enjoy their own individual settings while living in a single instance with other groups or divisions.

Our approach was to embrace flexibility across the spectrum of functionality within TimeControl. We put an emphasis on full-feature filters on every element of the system.  You could display or hide table records from one user-profile to another.  Profile security had to go to the field level so user defined fields could be displayed or hidden by role.  Business Validation Rules could be global or could be specific to only one group.  Languages could be adjusted by user profile so that terms that are appropriate to one group show up differently than another.  Reporting would show only the data to which that user had access.  This is all completely transparent to the user.  After all, all they care about is finishing that timesheet as quickly as possible late on a Friday afternoon so they can go home and enjoy their weekend.

Virtually all parts of the system could appear to be independent yet in the background still be part of the same database.

From the publisher perspective it has been a lot more work but the payoff is in the eyes of the client. We have been able to support organizations with thousands and thousands of users, divided by division or group or geography without having to resort to separate instances of the system.

Being able to be the same but different is just the water we swim in around here.

Why not start with Resource Capacity?

I get this question on a regular basis, “Why can’t I just start with Resource Capacity Planning? That’s all I want from our EPM anyway.”

In many lectures when I talk about what is Enterprise Project Management, I show a collection of possible definitions. Perhaps EPM is just system compliance, where everyone uses the same system.  Perhaps it’s document management, perhaps it’s timesheeting.  All of these answers are potentially accurate for any one organization but there is one answer that is by far the most popular.  When I ask what is it you’d like out of your enterprise project management system, they respond “Resource Capacity Management”.

So why isn’t this the first thing that people deploy?

The short answer is that resource capacity planning might have to be the last aspect of your project management system to deploy because it counts on almost everything else. Now, I’m going to take that back in a few paragraphs but let’s take a look at the challenge of the most common expectation for an EPM system.

What do we need for real resource capacity planning?

A schedule of work

We’re going to need to know when things are expected to happen and we’re going to need to know about everything that might have a demand on our resources. After all, what value would a resource capacity plan be if only a fraction of the projects were represented?  This can be the first major hurdle for any organization as it requires a centralized collection of all work.

All the resource availability

Of course we’ll need to have all the availability of any workers. That should be easy, right?  Well in some organizations it may be, but in many it is not.  The availability of contractors for example, may be hard to pin down.  It may be hard to identify how much of an executive we can allocate to work, vs their administrative responsibilities.  For the long term, are we able to be certain about hiring and firing of people who are, as yet unnamed who will be needed for projects?

The resource requirements

Didn’t we cover that in the schedule? No.  Resource loads are, of course, project work but many projects don’t have an accurate accounting of what resource requirements will be for each task.  And, the further into the future we look, the less certain we are.  Not only that, but resource requirements has to include all requirements, not just project requirements.  So, maintenance, overhead and administrative tasks need to be included.  Sometimes these are difficult to estimate

Project priorities

We’ll need to know how to sort the projects as we allocate resources or everything will be allocated as though it is just as important as everything else. This seems obvious until you try to do it.  Project prioritization can be one of the most contentious elements of resource capacity planning.

A flow of change

As projects, staff and risks change, the three elements above will change. That means that whatever system is created, it will need to be updated constantly.  So, updated schedules, updated global resource availability and updated resource requirements have to be brought up to date every week or every month or as often as you’ll make project decisions.

Ok, so that sounds insurmountable, doesn’t it? For many organizations it has been.  One of the reasons this is so daunting however has everything to do with the very software vendors who offer solutions to this problem.  Many years ago, it became apparent to EPM software vendors that their license revenue would be maximized if enterprise project management meant “top-to-bottom” integration.   Demonstration data was created that showed the project from the very highest perspective at the portfolio level all the way down to an individual’s week of tasks.  “Look,” they said, “we update this person’s task and it instantly shows up on the portfolio as a change.”  That was a compelling sales pitch and given it wasn’t just one vendor saying so, the industry magnified this view and many organizations bought into it.

Individuals were shown on a regular basis in such presentations and organizations dutifully bought licenses for each individual. Resource levelling algorithms promptly broke down.  We’ve talked about this too here in these pages.  When we apply such algorithms to roles or groups of resources they can be quite effective.  When we apply them to individuals they do not.  Some software tools instructed their salespeople to downplay the relevance of resource leveling calculations as “dated”.

But does this top to bottom notion make sense? We’ve already discussed in these very pages that when you move from the analytical domain of the project schedule to the commitment based domain of a to-do list that you’re going to end up in trouble.  Collapsing those two paradigms is almost never successful.  Perhaps those aren’t the only two paradigms that we collapse when we talk about resource capacity planning.

Many years ago I was speaking to someone who was a very senior engineer in an aerospace company. He told me that their project management office regularly sent him lists of “what to do” which he consistently ignored.  “If they’re so smart,” he explained to me, “they should get down here themselves and do the work.”  He was adamant that the PMO and all their fancy software couldn’t possibly know how to best allocate his team and get work done in the most effective manner.

So, is there a way to have resource capacity planning for the entire enterprise? As is often the case, it depends on how we define it.  If we are saying that the vision of top-to-bottom-all-integrated-to-the-individual-schedule is the goal, then you’ll need to create that much more complex corporate process of getting everyone on board.  However, there are other definitions that may be much easier and faster to deploy.

For a very long time I have thought that both a bottom-up and top-down analysis could live in harmony at one time. Think about this:

  1. Project Teams are asked to help define the complexity of projects in resource-group level terms. They give these estimates to management.
  2. Management, whether that is the PMO or a Strategic Portfolio Board or an Executive Level committee knows in rough terms how many people there are. They can also look at projects in terms of resource groups or even just total man power. Then they hand down to the project teams, project priority lists and guidance on when projects are to be expected.
  3. The Project Teams take this guidance and then refine the project in terms of resource role, skills or even individuals and execute the project.
  4. Tracking of projects is done timesheets and the results are sent in the individual level to the projects and in much more summary terms back to the portfolio with just summary costs and milestone accomplishment and projection dates.

Wait. Won’t that create a break between the portfolio / resource capacity planning analysis and the project tasks?  Yes it will.

Wait. Won’t that mean that the management level people won’t be able to just drill down to the individual schedule?  Yes it will.

But both of those things are not so bad. The break between global resource capacity decisions and day-to-day tasks is a break between strategic thinking and tactical thinking and that’s almost always appropriate.  The notion that upper management would ever be more effective by being able to drill all the way from their strategic plan to an individual’s schedule was always a fantasy anyway.  The upside of all of this is that senior management has a much easier to deploy resource capacity tool that is unaffected by how compliant each and every individual in the organization is and the project teams including the individuals can continue to be managed in a much more nimble and effective manner.

This is just one way of dividing different kinds of thinking to make an effective view for each audience and there will be many more. The key, I think, as you work towards what is the right plan for yourself is to keep distinguishing the domain of thinking that each part of the audience sees.  Keeping those domains distinct will almost always lead to better decision making.


Avoiding a bad case of broken telephone

When we think of Project Managers we tend to think of communications as one of their key skills. I’ve spoken numerous times about the importance of communications in project management.

These days we tend to think of how connected we are. In the last 20 years, communications has evolved at an ever-increasing pace.  We think nothing now of being connected 24×7 no matter where we are in the world.  We are linked to the Internet from the phone on our hip, from the tablet in a purse, from a laptop in a bag or from one of many devices.

Even the availability of cell phone coverage is becoming less of a factor. For an upcoming hiking trip, I purchased a Satellite/GPS device that can exchange email or text messages no matter where on the planet I happen to be.  The costs of such devices used to be prohibitive, but no longer.

We used to think of communications as speaking in person. Then voice-to-voice phone calls became commonplace.  For business we marveled at the FAX machine and the impact it had on getting signed contracts.  Email has now, of course, become a constant in our business and personal lives.

With all these new manners of communicating, project managers should be much more effective than ever before, shouldn’t they?

In some cases they are. Global communications has made some projects possible that we could have never thought of before.  Project teams that are not co-located but instead span many time zones and even countries are now commonplace.

But is it always more effective?

Consider this question: “Where does communication happen?”

Does it happen in your mouth as you utter a sentence? Does it happen on your screen as you compose an email?  Does it happen on your phone when you click Send on a text?

I don’t think so.

Communication always happens at the listener, not the speaker.

Oh yes, I understand that the listener wouldn’t have anything to listen to if it weren’t for the speaker but the only part of the communication worth measuring is where it arrives and is understood by the recipient.

Let’s say you get on a plane as a passenger and the intercom isn’t working  just as happened to me once years ago in a rather small country. The flight attendant stands at the front of the aisle and starts the safety briefing in a low voice that only they can hear.  Now I’ve flown some over my years and I’m pretty sure I could recite a complete safety briefing from memory but that day as they pulled out a lifejacket and mimicked putting it on, I became incredibly intent at what they were trying to communicate.  For the flight attendant, they may have thought that they could hear it themselves, so – communication delivered.  But it obviously was not.

In project management terms I’ve noticed an interested but disturbing trend among some project managers. It may have something to do with a new generation of project managers who are more used to digital communication than person-to-person or voice-to-voice so that the impact isn’t obvious but there are many project managers who have taken to using blogs, texts, collaboration messaging software or even social media to inform stakeholders without ensuring that their communications are being understood.

The result can be a mind-boggling disconnect. The project manager points to their communications plan and says “But I said I’d keep everyone up to date on our blog” and they have.  But just uttering the communication or updating the dashboard or progressing the schedule is an insufficient structure for ensuring that communications occur.

We’ve had our own version of this in our technical support group.

“Is that issue for the client resolved?” I’ll ask.

“Yes,” replies one of our technical staff.

“Has the client confirmed that the fix we sent resolved the problem?” I’ll continue.

“Oh. Um, not yet,” they say.  “I did send an email but they didn’t reply.”

“Well then the issue can’t be resolved,” I conclude. “Get on a voice-to-voice call and confirm.’

We’ve had to put structures in place to ensure that clients confirm that their problem is fixed and the same problem occurs with project management in many places.

Project managers have to guard that they don’t become a source or enabler of one-way project communications. As they make their plans for different types of communications and the myriad options of communication methods available over which to communicate, the most important principle to remember is this:

Communication happens at the listener, not the speaker.


Multi-device, multi-platform development means no more monolithic thinking

My company, HMS Software, just released a brand new version of our keystone product, TimeControl. That’s great news of course and you can read all about it at HMS at: but what went into this development and release has our company thinking about development quite differently and so this post is more about how software development philosophies are evolving.  It’s certainly a watershed moment for us.

TimeControl has been a browser-based product since 1999 which predates many companies in the software industry and certainly many companies with browser based products. For awhile TimeControl really only worked on Internet Explorer.  Seven years ago we took pains to ensure that our product would work on multiple browsers and on multiple devices.  We did testing on Internet Explorer of course but also on Firefox, Chrome, Safari and even Mozilla on Linux.  For a few weeks I took great delight whenever I would wander into an Apple store to point the iPads and Macs I’d touch to the TimeControl demonstration URL.  We were delighted to have expanded our view from the most prolific browser to support for many browsers.

We even made a mobile interface with a responsive design to allow browsers on different sized mobile devices to get access to the most common functionality of the timesheet system. But this was still through a browser.  Yes, it was groundbreaking at the time, but it was still inside a single direction of development.

In the last 3 years, we’ve seen a critical mass of organizations and users shift their computing time to more software as a service and mobile devices. TimeControl is already available both as a purchased license for on-premise deployment and as a subscription service so I’ll save that part of the conversation for another day.  The movement of computing to mobile SmartPhones and Tablets however is significant.

So, this month, as part of our new release of TimeControl, we released the TimeControl Mobile App. The development of the App over the last year came with plenty of design decisions.  Should we write native code for Apple and Android separately?  Should we use a hybrid design?  Should we make the product work asynchronously or just like the browser version? How different should the interface be? Should we make some functionality that just works on the App?

Yet, through all of that conversation, until near the very end, most of us were thinking of the App as an extension of our existing development.

Now, with the App already published on both Google Play and the Apple App Store, we have decisions we’ve never considered.

Do we sell it or give it away? We decided quite some time ago not to charge for the App.  We considered selling it as an additional feature or even using advertising to monetize the features.  In the end, releasing it for free still means that clients have to own a license of TimeControl as the App only works when connected to TimeControl’s Server.

Should development of the App continue on an independent stream from the main product? The App is dependent on functionality available in the server itself of course, but what might we be able to do without updating the server?  Or, should new features and improvements await the next major release of the server-based TimeControl?

It’s a quandary.

Many users, including myself, now wear a smart watch or other wearable technology. When something new like the TimeControl Mobile App come out, should I be expecting a watch version?


Users of Apps are less invested in these conversations than they’ve ever been. We have come to expect to look down at our phone and find the Apps we selected being updated with new features and better performance all the time.  We expect to find an App that requires no training, no explanation, and no headaches.  It is just supposed to “be”.  It is at the developer level that we are expected to take all the complexity that used to be so present for the user away.

Software developers all over the world are considering these questions and it is an evolving marketplace. There is little room left for monolithic thinking that we build one big thing and people will use it once we explain how.

One thing is certain, there have been many changes in how we look at the software market and there will be more to come.

Dashboard Disasters

We have an unnatural confidence in dashboards. When we see dashboard indicators we make all kinds of assumptions about them that may or not be true.  But we depend on them all the same.  This isn’t restricted to just project management dashboards though I have more experience with those than any others but dashboard indicators of all kinds.

Think about this. When you are driving and you see a green light, don’t you go through that intersection at full speed with complete confidence that it is safe to do so?  Yet, only a couple of weeks ago, I watched someone do that very thing and miss being hit by a fire truck by only a few feet.  He assumed complete confidence even though it’s possible to have emergency vehicles go through a red light from time to time.

While we’re talking about green lights, what else do we assume? We assume that the lights are working perfectly and that they haven’t chosen this moment in time to be green from all directions.  We assume that no one will run the red light and hit us from the side.  We assume that we are seeing all indicators.

If that’s so for driving to work, what about once we get there and we look at our real-time dashboard indicators of our projects or businesses? The same logic applies.

We look at a dashboard on our mobile device and make all kinds of assumptions. We see green and we know everything is fine.  We assume that the indicator is up to date; in real-time in fact.  We assume that it is complete; that all data is accounted for.  We assume that someone somehow has approved the data; that is has been authorized for publication.  We assume that the algorithm that is generating the indicator is not only accurate but that it has accounted perfectly for the display.

Yet, I’ve done a number of dashboard audits and found that indicators are often changed manually by the very people being measured. What is the incentive for these people to put a yellow or red indicator?  There is none.  “Might as well leave it green until I can get the project fixed,” they might think.

Even if the dashboard is working properly, would you make a decision about resource management if you didn’t know that you were looking at 100% of the data? Most dashboards don’t display the completeness or quality of the data.  What if you were only looking at 80% of your projects and it didn’t look like you were overloaded.  What might the incentive be of project managers of the hard-to-resource projects to make sure their data was up to date?  There is none.  “Better not to show how bad it is and just ask for more people,” they might think.

We also typically make another dashboard assumption that can cause real trouble. We assume that if an indicator is negative that someone must be doing something about it.  But I’ve seen many organizations where that’s just not the case or where there is no structured response to a negative indicator.  At McGill where I’ve taught Advanced Project Management in the past, we have used a real use-case IT study from one of the world’s leading aerospace manufacturers.  Part of the data of this study shows the history of dashboard indicators from a large multi-month IT project.  Several of the indicators are red for month after month and one question that is always asked is “What was done when these turned red?”  The answer is, “nothing”.  “We thought it would get better,” is the answer.  That reaction isn’t unique.  It could be true for almost anyone.

If you have a project or portfolio dashboard, here are a few tips on avoiding a dashboard disaster of your own:

Don’t measure too much
It’s easy to create a dashboard indicator but make sure it is measuring something that can leave the viewer empowered to take action of some kind.

Indicate the dashboard’s quality
Is the data complete? Is it timely?  Does all the data displayed come from the same time period?

Have an action for each indicator
This may be the most important tip of all. For each dashboard indicator, have a structured response of what must be done and by whom if the indicator is green, yellow, red, or whatever type of indicator you use.

If you have an existing dashboard, then a regular audit of what data are the indicators being driven from and is the data still valid and is the dashboard still relevant is healthy. If you don’t see documented standards for how to act based on the dashboard indicator, then putting those in can be a powerful improvement for very little effort.

Simplest can be best. A dashboard isn’t just a pacifier.  It should be something that enables decision making and, just like when the light turns red at the intersection, makes you hit the brakes to stay safe.