Category: Articles

Home Articles ()

There’s no cheese down that tunnel!

In my brief flirtation with Psychology in my first year of university, I learned more than I’d Wendy_300x274ever want to know about rats in a maze.  My distaste for the exercise would come back to haunt me last year when my stepson needed a dwarf hamster for his science project.  Wendy is now a part of the family.  You can see Wendy and our home-made maze on the right.

You’ve no doubt seen the images I’m talking about.  You put a piece of cheese that the mouse or hamster loves at one end of the maze and you drop him (or her) in at the other end and time them over and over and over and over again running through the maze to see if they can Maze_300x291learn how to get to the cheese more quickly by avoiding wrong turns.

Then, when you know the poor animal has learned perfectly where the cheese is, you remove it.

The mouse or hamster will go back down that tunnel over and over again, certain that the cheese will be there next time.

The difference between humans and hamsters is that eventually the hamsters will quit.

We humans are, as a species, obstinate.  If we think there’s a favorable result down that maze somewhere, we’ll keep going until we starve to death.

I’ve had a couple of projects that have been in this category for some time.  One project involves the link with a piece of software from a vendor that we’ve worked with for decades.  Some time ago, they released a new version of their software and suddenly the link we’d counted on for ages didn’t work properly.  We asked the vendor if they knew what we should do and they didn’t and the developers who have worked on this have made a number of attempts to solve the broken link.

The problem is, that despite being brilliant developers (much smarter than myself), they have focused over and over on the one bit of code that throws an error.  We know that error very well by now and no matter how many times we look at that one tiny bit of code, it won’t work.  Oh they’ve tried getting to the reluctant command in different ways, some of them very clever but we’re still at a standstill.  It’s the cheese-less tunnel for us.

This week I put the challenging project back on the books and told the staff to throw out all the legacy code for the module.

“Start from a blank page,” I said.  “Your job is not to make that code work.  We threw out the code.  Your job is to solve our basic business challenge as though looking at it for the first time.”

The thinking on the project has already changed.  Instead of working on the one command from this vendor’s product that isn’t working, we’re looking at all paths of movement of data from our system to theirs that results with data in the right place.  It turns out there are quite a number of options which we’d never tried.

It’s not unusual in a project to head down one path, hit some barrier and then pause while you wait for the barrier to be resolved but the lesson for me in this project is that you can wait at a barrier too long before it makes more sense to back up and try some other route.  In this case, closing down the path we’d been on for so long is forcing the developers to rethink the entire exercise laterally instead of literally.

I don’t actually care what the path to success is so long as we get there.  That a particular method fails is less interesting to me than the end result of solving the business problem I started with.

Over the last few attempts, we’ve had reactions from our staff that want to place the blame on the other vendor, or the indignation that their software doesn’t work as documented or on the righteousness of our approach.

None of those gets us the cheese.

I’m quite optimistic now that we’ll finally solve this particular challenge.  I’ll keep you all posted on our results.

Scope Creep in an Agile World

The whole concept of Agile was designed to prevent project bloat. Back in the 1990’s when software development and deployment projects became mega projects a little too easily, the notion of Agile became much more popular.

We’ve all heard about Agile.  The idea that we’ll develop incrementally in sprints and after each sprint we should have deployable code, each time with a bit more functionality.

It’s a great idea.

We use Agile project management within our own development at HMS. Using this methodology we can take an elephant sized project and gradually consume it one bite at a time.

But to make this work, there are some assumptions in the background that you can’t lose sight of. We assume that as we’re eating the elephant, no one is substituting an additional, larger elephant each time we go to our list of things to do.  In Agile, this list is called the backlog and we tend to think of the backlog as a constrained list.

But who in your organization is in charge of constraining it?

One of the great things about Agile is that it’s, well, agile. It allows the project to maneuver in different directions based on how the project evolves including how the users react to the early iterations of the code being released.

That’s awesome (really, it is), but this is just the formula that can result in the dreaded scope creep. As feedback arrives to push the functionality one way then the other, a few things become easy to forget about:

Who is doing the creeping?

Firstly, the very people giving feedback are probably the very people who helped with the original design. It’s not uncommon to have people respond in one way while a project is more theoretical and a very different way once they can see it.  The budget for the project which is likely to have gone through a whole process of tradeoffs and prioritization is built around those theoretical decisions, not the more immediate reactions to things from the field as the project is actually underway even if the people who did that budgeting and the people who are making these new requests are the same people.

Is everyone still on the same page?

It is common to be more expansive in ensuring that a project has all the design requirements built into it when it’s first budgeted. Perhaps someone from Finance was tasked to ensure a particular link would work and that the data would have been validated in some way.  Then someone from Payroll was tasked to review the design and make sure the payroll rules were followed.  But as the project gets underway, it’s often difficult to ensure that all the people who worked diligently on the design at the beginning are still giving the project the same level of attention as it is being coded in an Agile methodology.

There’s not a single simple answer to how to avoid these types of pitfalls. But blissfully moving on in an Agile world without thinking about some of the constraints and assumptions that other aspects of the business are counting on can lead to problems.

Our experience has been to institute a few checks and balances to projects:


First of all, communication is key and by communication, I mean discussion. We have seen projects where there was some upset at deployment and someone says “Oh that was in the June email last year” and, sure enough, there the change is, buried on page 12 of an email with many topics in it.  So, we’ve come to do more discussion of requested changes before they end up in the backlog.


Sometimes a request from the client or user will seem like a tiny impact in terms of developer hours but we have found some things that seemed easy to change in the code can cause enormous heartache in downstream processes and user impact. So, we ask that estimates include not just coding time but impact on QA both now and for future versions, upgradeability, backwards compatibility, documentation and future technical support.  Often an original estimate of a few hours becomes days or weeks long when we shine a light on all the other work involved.

Corporate memory

We have had to take the responsibility of being the corporate memory on numerous projects. That’s often because our team is quite stable and client teams often change faster.  So, even with lots of documentation and email threads and communications plans.  We are often the ones who say “You might remember that the reason you said last year that you wanted to do this in this way was because of this.”  Find someone who will be the anchor for the corporate memory.

Project Management Best Practices

Even while the Agile group is evolving the project in great strides, don’t abandon your basic project management principles. Did you have a budget?  The project charter?  Approved design?  Progress milestones?  They can be even more important at one level when Agile is involved at another.

Like all things, Agile has pluses and minuses. I always recommending taking from these methodologies the practices and processes that work for you in your particular environment.  In most organizations I’ve worked with, this usually means an environment with processes culled from several different methodologies.

All-in-one or Best-of-breed

swiss-army-knife-on-steroids_300x211.jpgAll in one thinking is built into our industry

Many years ago I wrote several articles about the differences in choosing an all in one Finance system vs best of breed functionality.  My focus was mostly about project management, but the concept can carry across many systems.

The notion of all-in-one corporate systems became popular in the 90s.  Large integrated systems like SAP or Oracle Financials were able to point to multi-function systems which included in their core modules the General Ledger, Accounts Receivable and Accounts Payable systems that we think of as common to all Finance systems.  Then in a second tier of functionality: Invoicing, Project Costing, Payroll and Inventory were attached.

The biggest barrier to these systems becoming pervasive was that integrating such varied functionality was often complex.  The stated benefit of using the all-in-one provider was that there was less work to integrate the different modules yet just defining the business logic of multiple such modules linking together can be an overwhelming project in itself.

So, the disadvantages of choosing best of breed didn’t seem so disadvantageous after all.

Yet, the concept of going with all one vendor has continued.

In the last 5 years there has been a push from the large scale integrators to move all business functionality to the cloud.  Office is the dominant word processing, spreadsheet, presenter suite and it is available online as Office 365.  Microsoft will explain that you can build any additional functionality you wish in its accompanying Azure system.  That’s awesome so long as you are ready to embrace all the Microsoft technology that’s already there.  So, if you prefer to do your work with any Oracle tools, this won’t be your best plan.

Oracle now has cloud offerings.  Enterprise Business Suite is one of the big competitors to SAP and it too is now available online.  Here too you can build whatever you wish inside of the Oracle cloud based architecture.  But what about Microsoft SQL Server?  No.  That’s found over on the Microsoft side.

What I’ve found fascinating about this is that in the last few years, just as it was in the 1990s, these systems have not become all powerful.  Microsoft has softened its “we’re all in” slogan to endorsing hybrid architectures where some functionality is online and some in house as the ideal.

Online infrastructure offerings such as Amazon’s Web Services (which host such modest online offerings as Adobe, Netflix and Intuit) continue to flourish.  How is this possible if all-in-one is all-powerful?

CRM systems are offered by both Microsoft and Oracle yet Salesforce still seems to be growing.  That makes no sense if all-in-one means always-better since Salesforce doesn’t offer core Finance modules such as a General Ledger or Accounts Receivable.

In my own industry, TimeControl has always lived as a best of breed solution.  Over the last 25 years we’ve had many requests for it to be extended to include all-in-one functionality.  We’ve been enticed to create a complete project planning or project portfolio management system.  We’ve been asked outright if we would extend TimeControl to be a payroll system and/or a Human Resources system.

Thus far we’ve resisted all these suggestions.

We are committed that TimeControl be the best of the timesheet world and TimeControl has become just that.  It is already the most flexible timesheet in our industry and the timesheet home for hundreds of thousands every week.

Yet that alone doesn’t mean that TimeControl is the ideal solution for everyone who finds it.  We encourage organizations to define their business problems before considering the solution and our prospective clients take us to heart.  We have asked more than one organization to pause for a moment to be sure they know what they are looking for before deciding that we are it.

Shouldn’t the same type of thinking apply to all software vendors?  Back in the early 80s when I first entered the IT industry, there was a saying “You never get fired for buying blue”.  It referred to IT purchasers selecting IBM as their vendor.  IBM’s logo was blue, you see and they were by far the dominant computing vendor at the time.  Large IT vendors who espouse all in one solutions have similar pitches.

How could you go wrong buying all Microsoft?  Or all Oracle? Or all SAP or all… well you pick the vendor.  The decision will always be defendable and in a complex IT market, it takes a seasoned purchaser and business analyst to pause long enough in the evaluation stage to make sure that the benefits of going with one vendor outweigh getting the best of breed for different functionality.

Yet, even in the large scale vendors, there is room to bring in “outside” systems.  We had a client this past year who informed their large scale vendors that their systems must support TimeControl as they had already deployed thousands of TimeControl licenses and the data from TimeControl was already well established as a core process and a core source of key metrics for the organization.  Magically, vendors who had said the only option was to go with an all-in-one, found their integration functionality much more interesting and the winning vendor got to work with us on integrating their systems with ours.

I would be remiss if I didn’t say that for some organizations, the all-in-one approach is ideal and a great fit for their requirements.  We have known many organizations who have successfully solved their IT business challenges this way.  My own HMS is partners with some of the largest IT vendors and we are able to work together on many occasions to make a solution fit the client.

Yet, as we approach that most festive of times for IT vendors (the end of the 4th Quarter and the end of this year’s quota’s), it is a better time than ever to make sure as an organization you are putting the business problems at the core of your search, not the promises of whatever vendor shows up next.

Make us do the work to show you how we can solve your particular business challenges rather than taking the path of least resistance and matching your requirements to fit the functionality presented.

Is the answer “All-in-one” or “Best-of-Breed”?

Doesn’t that depend on the question?



When is the solution complete?

There I am at the PMI 2016 Global Congress in San Diego listening to keynote speaker Sue Gardner.  Ms. Gardner’s resume is enough to make you pause and take notice.  She has worked with numerous Silicon Valley companies including Wikimedia who run the famous Wikipedia.  She has been on Fortune Magazine’s whenisdeliverycomplete.jpg100 Most Powerful Women list and that alone is saying quite a bit.  So, I was interested to hear her views on the future of leadership.

As is often the case when I listen to a good keynote speaker, I don’t usually get the benefit I’d have thought of prior to the talk but what I do get is surprising and surprisingly valuable.  In this case, the realization of something important to me came as Ms. Gardner was talking about the movement of IT in many organizations from a “staff” function to a “line” function.  She was describing how the world has changed in recent years, making IT services within an organization more a part of the delivery of whatever the organization creates than a support function to help behind the scenes.

This makes perfect sense in today’s world.  Are you in banking?  You’re not going to be in it long if you don’t have a hot new mobile app to deliver your service.  Are you in travel?  Your travel product almost certainly now needs to be delivered through the Internet.  Are you in energy?  Your products have to be “The Internet of Everything” enabled if you have any chance of being a leader in your industry… and so on.

So that’s where we were in the keynote when I had this realization.  The reason that some organizations are reluctant to follow this model, I suddenly realized, is some of them think that the delivery of their product or service stops at the moment it leaves their building.  If it’s software, then the second it has been downloaded (or if you’re old fashioned, shipped on a DVD out the door), the sale is complete.  If you’re in travel, then the second you’ve completed the sale of the ticket, the transaction is over.  Benefit delivered, money collected.  Thank you very much.

The problem is the perspective.

If you’re the manufacturer; the deliverer of the service or product, it may seem like you’ve accomplished what’s important to you.  But if you’re the client, this might only be the first step of many before you’re done.  The client bought your service or product because they had a problem and they believe that what they bought from you will solve their problem.

It’s remindful of a conversation I had many years ago with an executive at a large project management software company.  “If you’re committed to solution selling you’ll need to invest more effort in determining the problem,” I said to this VP.  “Our problem is we need to sell more boxes,” he said.  “Well that’s your problem, sure,” I replied.  “But, it’s quite unlikely that it’s the problem of your client.”

He was stunned.  He got it right away of course.  He wasn’t stupid.  But he realized in that moment that his thinking had been all from his own perspective.  Solution Selling required getting into the shoes of the people who were buying.

The same thought process occurred to me this week listening to Ms. Gardner.  If we think the delivery of the service of product is the end of the transation; the end of the sales process then who cares if IT makes a better app or a better in-the-cloud service.  We’ve delivered the thing you asked for.  Time for us to move on.

But, if you take the perspective of the client, then you’ll need to build into your thinking time, effort, money, services and attention that go from the delivery until the point where the client acknowledges that they have received benefit from whatever it was they acquired.

Did it solve the problem?  Is the client’s world a better place?

Delivering a solution in a way that has your firm stand out from others means you have to ensure that whatever it is you sell actually solved something.  It’s something that’s so easy to forget as part of the business is caught up in the next sales forecasts and another part of the business is busy building whatever the next client needed.

A good lesson for us all.

The balance of software releases

At my firm, HMS Software, we were delighted to launch the latest new version of TimeControl this week.  software_dev_road_sign_300x210TimeControl 7 was released on Monday and there’s no one happier about that than I am.  I’m excited about the new release but it sparks a conversation in my firm and with people in my industry about how often should clients go between software versions.  There’s several aspects to the conversation.

What is a “new version”?

The first thing to consider is what you mean by a new version.  At HMS we have a 4-tier release model for TimeControl which is not uncommon.  We use the version numbers to distinguish different types of releases:

New Version

The first digit in a release number is a completely new version and generally means there is underlying changes in architecture.  While we may incorporate all the functionality of old releases and even improve upon them, there is certainly new functionality.  In the case of our TimeControl release this week, version 7 heralds a new wave of the pro
duct.  The last time we changed the first digit in a release was for version 6 and that was released in 2010. In this version, we’ve changed some underlying design to allow for our upcoming TimeControl Mobile app and rewritten major sections of the product including the timesheet interface itself.


The second digit in a release number means we’ve added new functionality and changed or enhanced existing functionality.  So version 6.10 of TimeControl which was released 9 months ago was the last New Upgrade for the product.


An Update for us is shown in the third digit of the release number.  It signifies for us that we’ve kept all the major functionality but have perhaps enhanced several functions as well as corrected issues with any functionality that we’ve found issues with.  We release an Update to TimeControl every 3 months or so.  The last update for TimeControl 6.10 was 6.10.1.


A Build number is found in the fourth position of the release number and is usually a hotfix or bug correction version.  In almost all cases, our builds correct issues that occur for certain clients under very specific circumstances.  The last Build for TimeControl 6.10.1 was which was released 2 weeks ago.

Other version numbering systems

So that’s our system but there are many others and those systems are also compounded by the proliferation of software as a service.  If you are not upgrading yourself but are just subscribing to a service in the cloud, do you care as much about the actual version number?  Perhaps not.  Some publishers have taken to naming their versions after years and seasons.  Salesforce for example is currently at version “Spring 2016”.  Not hard to keep track of.  Microsoft’s office is “2016”.  Again, not hard to track.  But internally, the Microsoft system looks a lot like HMS Software’s I’m using Word 2013 as I write this at the internal version number is 15.0.4849.1000.

So that’s how versions work but how often should they be released?

For those who use TimeControl on premise, we have to consider the impact on their operations.  Unlike some publishers, we support versions for years after they were completed because a change in a corporate timesheet can have an enormous impact on so many internal systems.  Also, installing every upgrade is not a favored activity by most of our clients.  So we try to keep a steady stream of improvements but also support clients skipping numerous updates before going to a next big release.  If past experience is any guide, we’ll probably be spending a bunch of time at HMS in the coming months, helping clients upgrade from 6.0 to 7.0, skipping all the releases in between.

For our clients who subscribe to TimeControl Online, our in-the-cloud timesheet service where we’ll be updating them in early October, we will want to give them as much notice as possible so they can prepare their personnel for the updates.  We also will make sure that as we upgrade the old service that all the client data migrates seamlessly and that old settings are transformed into new settings to minimize the impact for the majority of each client’s users.

Software updating is a balance, keeping our clients competitive by keeping them up to date with the latest technology yet supporting existing and working critical systems and processes without interruption.  We think about this balance more on weeks like this when we’re releasing a major new piece of technology.

If you’d like to find out more about the TimeControl 7 release, you can see the Press Release  or see What’s New with TimeControl 7.

Critical Chain – It’s everywhere and you may not like it

waiting at dfw.jpgYears ago, when most of us in the project management software industry were discussing critical path theory and how resource levelling should work, a new paradigm emerged called Critical Chain.  It was developed by Eliyahu Goldratt.  The issues that caused Critical Chain theory to evolve were sound.  The problem with Resource Levelling is that it assumed a perfect world with perfect distribution of resources and a world where when one task was complete, the next task and its resources would immediately be available.  Of course that’s not always the case.

If we focus on where the resources become critical, the theory went, we could focus on actual work rather than theoretical work.  After all, actual work is accomplished by applying resources to outstanding work.

The paradigm was picked up by some project management tools but not many and the popularity of the algorithm was obscured by new developments in communications and collaboration but there are still some aficionados of the methodology who swear by it.

If you’re thinking that you’ve never heard of or care about Critical Chain Methodology, think again.

It’s everywhere.

Been to the airport lately?  If your project schedule is a commercial aircraft then you’ve been living critical chain for sure.  The critical resource is, sadly, not you.  It’s the aircraft.  The next most critical resource is, again sadly not you, but rather the crew.   Critical chain methodology would say, let the non-critical resources queue up and stand by for the much more critical resource to appear.

So, you get a notice to appear at the airport 2 hours prior to your flight.  In some airports, that’s 3-4 hours.

Is the plane there?  No.

The crew?  No.

But you’re there and you’re definitely important to the project schedule at some point in the process.  But not now.  In the meantime, queue up and wait.

That’s because the project isn’t you.  The project is getting the plane through it’s schedule as efficiently as possible.  You’re not the project.  You’re the cargo; what’s delivered in the project.  If you arrive or not, that’s much, much less important than the arrival of the plane on time at its next destination.

One hour prior to your flight, if all is going well, the all-important aircraft appears.  One crew possibly deplanes.  Another boards.  Critical resources like fuel arrive and are loaded.  Critical resources like Maintenance check the tires and make sure all is ready to go.

With 30 minutes left before departure, the least important resources to the project are loaded.  Yes, that’s you.  The passengers are loaded in what airlines hope is the fastest path to getting onto the plane.  Some airlines load from the back to the front.  Others load from the outside in, putting window passengers on before aisle passengers. If some of these least critical resources don’t appear.  The project isn’t delayed.  The plane still leaves as close to schedule as possible. It has other critical project resources it has to account for such as air traffic control space and other airport gates when it lands.

As someone who travels by plane often, I often wish that the plane project was oriented around me but that’s just not so.  I’m the most available resource in the entire equation.  There are hundreds of me.  There is only one plane.

So you may not have used critical chain in your own project schedules thus far, but it’s certain that you are encountering the methodology every day in your day-to-day activities.

How can miscellaneous = mischief?

It’s the dreaded 999 code that can turn a project upside down.  The miscellaneous charge code into which all bad hours go can be the source of a great deal of upset and difficulty a project. contingency_300x172.jpg

In the timesheet business that we live in at HMS, we’ve see clients who have an unhealthy attachment to the 999 charge code.  When you just don’t know where those hours should go or you just don’t want to own up to how many hours you spent on some task or you know you shouldn’t have been doing that task and you need to put the hours somewhere or (and this is my favorite) you just can’t for the life of you, remember what you spent those hours on!  For all of these situations and a hundred more, there is the miscellaneous code.

We recommend that the catch-all miscellaneous code be used sparingly but if it is available at all, it carries such a powerful attraction that it is hard to resist.

Timesheets are not the only industry that has a miscellaneous category.  The last time I moved houses, we had the miscellaneous room we called the “room to be named later”.  Into that room went every single box that didn’t have a label, didn’t fit into another room or the carrier of just didn’t have enough energy or will power to carry it anywhere else.

In the project management business the miscellaneous charge is often called “contingency”.  In theory good project managers shouldn’t need any contingency.  After all, isn’t contingency just a way of saying “unplanned”?  How could a good project manager have anything that is unplanned?  Yet all good project managers tuck a little contingency into their plans somehow.  The very first employer I had in the project management industry back in 1982 was in the construction business.  He used the end-phase, called building commissioning to hide his contingency.  He would put a floor-by-floor dry-wall and painting phase near the end of the project.  It would be scheduled sequentially but Gerry always knew that if he was pressed for time right near the end, he could put 20 dry-wall and painting teams into the building simultaneously and magically get back on schedule.

The problem with all of these constructs is a lack of shared rules for using them.  In the timesheet business, we’ve often gone looking for the miscellaneous hours in a client’s timesheet, found an unconscionable number of them and recommended disabling the ‘999’ code until we can get a better handle on where those hours are being spent.  It generates some upset at first but it ultimately ends up with a stronger understanding of the business.

In the project management business, the most common problem with ‘contingency’ is everyone thinking they can use it.  Monte Carlo risk analysis is process that tries to take this very problem out of critical path scheduling where everyone thinks they have slack to work within but in fact, they are sharing it.

Is some slack a good thing?  Almost certainly but if this is a part of your management plan, make sure you have a solid process of how and when it will be used so that not everyone starts to take advantage of it.  If you don’t, like me, you might end up moving and finding every belonging you own has been put into one room of your new house!

You can’t get there from here

It’s an old joke that is typically attributed to the people of the State of Maine in the US.  A visitor stops to ask an old timer for directions and says “I need to go to this place.”

The old-timer resident thinks for a moment and then says, “Oh sure.  That place.  I know that place.  You can’t get there from here.”

The joke almost always gets a laugh but I was reminded of it earlier this week as I was preparing for a talk I’ll be giving at the PMI Global Conference in San Diego this September.  I’m doing research of the writings of Buckminster Fuller whose thinking I have admired for years and who I think is particularly relevant to project managers.

In his book Critical Path, Fuller reminds us that the critical path schedule for the Apollo project to put a man on the moon and return him safely to Earth was about 2 million activities.  It’s an overwhelming project and the fact that it was accomplished in under a decade is a testament to the results that can come from a group of committed humans all working in concert.

Fuller goes on in the book to make the point that was more important a couple of pages later.  He says, “The critical path of the Apollo Project – one-half of whose two million or so tasks to be accomplished involved the development of technology that was non-existent at the outset of Apollo.”

That’s crazy.

It makes no sense.  Right?

We have no idea how to get from here to there but we are committing to do it anyway.  In fact, we have about a million tasks that we do know how to do that we are investing in right now with the faith that we as a team will overcome the challenge of inventing technology we haven’t invented yet in order to be successful.

Who would take on a project like that?  Yet when I read it and am reminded of everything that was accomplished in the Apollo mission I am not left overwhelmed, I’m left inspired.

In far too many projects I work on, we are plagued with only doing what is predictable.  Yet, when circumstances make that impossible, the innovativeness of man emerges.  It’s always there.  I am reminded of so many projects in which some challenge arose that was unforeseen and yet had to be overcome and ultimately it was overcome because there was no choice.  A nuclear refurbishment project over 20 years ago had a nuclear physicist explaining to me how he could “encourage” a rubber spacer to move on the other side of a metal wall by creating some field of energy on this side of the wall.  That one invention saved billions of dollars of investment and made the project a much safer place.

The old joke of the old-timer from Maine is funny because on its face it’s obvious that of course you can get there from here.  It’s just not obvious how.  As project managers, I think we need to keep our inventiveness muscles sharp with practice.

For information on Bucky Fuller, visit the Buckminster Fuller Institute.
For information on the Apollo project, visit


Time for Time Zones?

It wasn’t that long ago that the world was a much bigger place. In the olden days (about 10 years ago) we didn’t have to think too much multi-timezone-watchabout the real-time impact of global project teams.  The world just isn’t that big anymore.

Collaboration challenges

Modern communications technology means that every team member probably has a mobile phone and the Internet is available virtually everywhere (well, almost) and the collaboration tools for video conferencing and screen sharing are so sophisticated that many people prefer to attend meetings from their desks over getting together in person. But technology gives us the tools to communicate, not the practice.

It’s a pretty common occurrence now that when you are looking at how to have a project team communicate, thinking of what time it is in different parts of the world is essential. Here at HMS we have been working for some time with multiple clients whose users are located all over the planet and we have to accommodate not only access to the users but members of the project team as well.

If you are located in North America’s eastern time zone as HMS Software’s headquarters is, then you may find you need to coordinate meetings where some participants are in different North American locations, some are in Europe, some are in India.

There is no convenient time to meet. Well not convenient for everyone anyway. So to make things work, we all have to be a little flexible.

Project Tracking made easy?

The same challenge carries over to the use of project tracking software like our TimeControl. Getting a weekly timesheet from everyone should be an easy win, right?

Not so much.

First of all, what is the end of the week? In Montreal, New York and Chicago it may be Friday or perhaps Sunday. See? Even in the same time zone we might not agree. Ok, here in North America let’s say Sunday is the end of the week and Saturday and Sunday are the weekend. Monday would be the start of the week.

That’s true everywhere, right?

Sorry, no.

In Saudi Arabia for example, the weekend is Friday and Saturday with Sunday being the beginning of the week. If you’re about to complain, don’t be so quick. Only a few years ago, the weekend was Thursday and Friday with the start of the week being Saturday. In 2013 many countries including Saudi who had Thursday and Friday weekends switched to have more of the week match with other international businesses.

Whew. Problem solved. Kind of.

But when should we collect our weekly timesheets then or update our project status? The question isn’t trivial. One of the things that we define in our project update process is the as-of date for statusing. We look at a progressed barchart and we make numerous assumptions about the data:

  • We assume that it was all reviewed and approved.
  • We assume that the data is all current; not that some of the data was updated last week and some only a year ago.
  • We assume that the data goes together; that the progress of time isn’t jumbled together with the progress of material usage.
  • And – we assume that the data has a common status date; that the date we progressed one task is the date we progressed the others.

Ok, it’s kind of overwhelming so far but we haven’t even talked about time zones yet.
Timesheet data for example, is often thought of as real-time data. As people submit their timesheets and they are approved, the data will become instantly available for reporting and exporting to other systems. If that is your goal, then the challenges of what time is it become a heartache.

As you are finishing up your timesheets in New York at 5pm on Friday, it is already 11pm in Paris (depending on daylight savings time). It is midnight in Riyadh, Saudi Arabia. But wait. It’s not even the end of the week in Saudi. They won’t finish their week until 5pm tomorrow at which time it will be noon Saturday for you. At 5pm on Friday it is 7am in Sydney Australia and it is 2am in Bombay India. That’s 2am tomorrow.
Some project managers try to manage this by getting everyone onto their own time. “You’ll need to work in Eastern Time,” they say. Good luck with this. The military has this notion. They work on Zulu time which is Greenwich Mean Time (GMT+0). That’s key for coordinating a military strike from numerous places on the globe and avoids confusion but it’s almost always impossible in practice for a project team.

Is it hopeless?

Well, if your goal is time tracking in real time then it may be theoretically possible but it’s highly impractical. But let’s go back to that list of assumptions for a moment. Is it practical to think of project data as real time data? In some limited aspects perhaps but can you act on a project that has only a fraction of its tasks updated? Probably not. Let’s say that you are looking at a resource management report in which only 80% of your tasks have been updated because 20% of your tasks are still being updated by people in different time zones. Should you act upon the information? Perhaps not.

Project data as a rule is batch data. That is to say, it is data that is grouped into a collection and updated and approved all at the same time. We tend to update a who project or a project’s whole sub-section. We tend to group timesheets for the whole week or the whole day even but we update and approve the whole selection.

If that’s the case for our timesheet selection then perhaps the completion of timesheets for our groups in North America which will be done after those in India but before those from the Middle East will all work out because we can set Monday as the lowest common denominator “start of week” day and use that day to determine if all the data has been collected and start our processing of the data then.
Some tips on working around time zones

Here are a few other commonly used tips for making time zones work in your project:

  • Divide and Conquer
    If you divide your systems and data into sub-systems in different areas and use consolidation features such as sub-nets in Primavera, Master-Projects in Microsoft Project and Consolidation in our own TimeControl you could have different rules in different systems and consolidate the data into a central source for reporting. There are pluses to this approach such as accommodating each group and their own local rules and minuses such as extra system maintenance and data reconciliation.
  • Filter, filter, filter
    Some systems allow the data to appear divided even though it is not. We do this with TimeControl and other systems do this with their project planning data.
  • Separate the data
    You can separate your project files and let each group work independently. Then instead of managing at the task level, you can manage your sub-project at the project level or at a more summary level approach such as weighted milestones.

Making a successful multi-time-zone project work is mostly about cooperating and understanding that your processes will have to adjust. The world isn’t getting larger anytime soon so managing time zones and non-co-located team members has become a fact of life. You can make this work for you too if you can get your different locations to collaborate on a system that works for you all.


Resource Skill Scheduling Skills


skillscheduling_300x232Since I started in the project management software industry in the early 1980s there has always been an interest in managing skill scheduling.  It’s easy to see why.  When you need to build something whether it is a house, a pipeline, an aircraft, a new drug or a piece of software, you are going to require resources who have specific skills.  Skill scheduling has been designed and even delivered in different project management tools for years.  The idea is that instead of allocating tasks to a generic resource category which contains individuals within that category (e.g. programmer) or an individual, you would define a skill and allocate that skill to individuals and then allocate a task to the skill required to complete it.

Sounds pretty good so far and, with all the decades of time dedicated to creating great skill scheduling you’d think that we would all be using awesome skill scheduling tools, right?

Not so much.

The problem isn’t a lack of interest or a lack of smart programmers.  The challenge is that skill scheduling is a highly complex problem. There are certainly tools that purport to solve the skill scheduling problem and it’s unfortunately one of those concepts that is easy to demonstrate at a superficial level. That can make it easy to sell software but skill hard to solve the problem.

Let’s first take a look at some of the difficulties involved.

Skill definition

The first of several difficulties in creating a skill-scheduling process is getting agreement on what constitutes a skill.  If you work in the construction industry for example, this is already well defined.   The trade organizations have already created these skill categories for you and have levels of effectiveness for what certification is required for each one.  An apprentice carpenter is not a journeyman plumber, and so on.

That’s great if you’re in an industry as well defined as the construction industry but not as much if you are in another industry.  In IT, for example, certifications are only relevant to a small percentage of jobs.  On everything else, we are stuck saying things like “That task will take one of our more experienced programmers”.  Not nearly as helpful.

But, if you’re committed to a skill-scheduling paradigm, getting agreed-upon definitions is essential.

Multiple skills

In the construction example, I just spoke of, one of the things that makes skill scheduling understandable is that an individual typically lives inside only one category but in many other industries, that isn’t necessarily the case.  In IT someone might be a programmer, a database designer, a designer, a business analyst and, a documentation specialist all at the same time.

This one challenge makes skill scheduling an algorithmic nightmare.  Let’s say we create a process and some analytic project management software to go with it to schedule by skill.  I have a task that requires a programmer.  Great.  I assign a programmer who is also a business analyst.  Now a task comes up for which I need a business analyst.  Hmmm, I should really take the person I tried to put on that other task as a programmer and reset him or her here as a business analyst and put someone else back on the other task as a programmer.  But wait, the person I’m now selecting as a programmer for that first task is also a documentation specialist and they’ll be needed on yet a third task to write documentation.  Hmmm, let’s go back and start over.

This problem is compounded by the likelihood that multiple skills are often grouped into smaller numbers of people.  Once someone becomes multi-functional, it is more likely that they will add more skills to their repertoire than it is for someone who has one skill to add only one more skill to their name.

Software systems that have tried to create tools to do this work use reiterative heuristics (ironic because that word is in the very name of my own firm Heuristic Management Systems) to go through the analysis over and over, trying to rework alternatives into the different assignments to get the best possible picture.

If your mind is reeling like it might looking at fractal graphics with the infinite permutations of how we get the right skills onto the right tasks, you’re not alone.  It’s a complex challenge that computing horsepower alone doesn’t solve.

Double and triple counting

If I have Bob and Sally as my only two resources, it’s not complicated to figure out how much work I can get accomplished.  If Bob and Sally each work an 8 hour day, then before I look at the first task to schedule I know there are 16 person-hours available to accomplish my tasks each day.

But let’s say that Bob can do programming, documentation, design and project management and Sally can do project management, programming and, quality assurance, the availability becomes more complex.  If Bob and Sally each work an 8 hour day and we look at the skill capacity available before we start the first task, we have to come up with a list like this:

  • Design: 8 hours
  • Programming: 16 hours
  • Project Management: 16 hours
  • Documentation: 8 hours
  • Quality Assurance: 8 hours
  • Total: 56 hours per day

Now that’s nonsense of course.  It’s just poor old Bob and Sally but it’s a fact that we could possible do 16 hours of programming today *or* 16 hours of project management.  The difference is that if I use Bob or Sally for one of their skills, all the other skills become less available.  That is a difficult concept to wrap your head around and for people trying to write a skill scheduling tool, it’s also challenging.  For management, it makes it difficult to think about how much capacity you have to get work in a category done and even more difficult to think about the impact on other categories of work.

Skill Effectiveness

Years ago I was in design meetings with the publisher of a project management software system who had come up with an obvious idea.  We should be able to tag each person with how effective they would be doing a particular skill.  I might say that Sally is a pretty good programmer so we’ll tag her at 100% meaning that if we give Sally a 40 hour task, we have a reasonable expectation that she will be able to accomplish it in 40 hours.  I might also say that Bob, being a bit newer is less effective than Sally.  We’ll tag him as a programmer at 50% meaning that if we give him the same 40 hour task, we’d expect him to accomplish it in 80 hours.

Sounds awesome, yes?


We couldn’t see it at the time but the human resources implications of what we’d designed were enormous.  As soon as we started trying to get people to self-assess their skills, they all assessed themselves at 150%.  That obviously was a problem.  Then if we asked supervisors to assess their skills, the backlash once people found out that they were assessed at less than the person at the next desk was horrific.  Yet managers and team leaders do this kind of assessment all the time.  It’s natural to do.

We abandoned the idea and tried not to talk about it ever again.

Trying to mix tactical and strategic management

The core problem with all of these issues stems from trying to do different kinds of analysis simultaneously.  When we attempt to get a handle on how much capacity we have for certain kinds of work with trying to determine which individuals should do what tomorrow, we end up in a mess.

But all of those challenges doesn’t mean that skill scheduling is a useless goal or an unattainable pipe dream.  After all, managers and supervisors naturally do skill scheduling every day just by looking at a project and using common sense.  So, if you are in a project situation where skill scheduling makes sense, here are a couple of things to keep in mind:

Separate tactical analysis from strategic

The first and most productive thing you can do is to separate out your strategic analysis of what capacity you have for different projects from your day-to-day management of individuals.  If you give up on the idea that you’ll be able to drill down from the very top strategic view of the organization’s skills into each person’s daily assignment, you will save yourself a world of upset.

You can use skill scheduling in one top-down exercise to determine in rough terms whether you have the skills to accomplish a project and roughly whether you have enough people.  Then, in a completely separate exercise, turn the individual level of scheduling over to your in-the-field supervisory people who can keep a list of skills for each person and group them or search them that way but who will use common sense to get the right people on the right tasks.

Use top-down planning at first, then shift to bottom-up planning

If you are using top down planning to get the project started, make sure at some point early after the project’s activation that you put that aside in favor of what is likely to be a much more accurate bottom-up plan that comes from the people actually expected to do the work.  Your team leaders and individuals may come up with a plan that is quite different from the strategic view and it’s natural to go back and forth trying to reconcile those early in the project but at some point it is no longer effective to use your strategic plan for day-to-day management.  It’s always more effective to manage people against a promise they made to you than it is to manage them against a promise you made for them.

Squint your eyes out of focus

When someone says, “We’re going to finish this project in 2 years, 3 months, 4 days and 6 hours.” I have very little confidence.  Managing something like skill scheduling down to the last second is an entertaining goal but isn’t productive.  Better to have a fuzzy end and have a chance of making it.  Someone saying that “We’ll finish between January 15 and February 8,” is more likely to sound reasonable to me.

The desire to locate the skill scheduling Holy Grail of resource analysis may never go away and I have no doubt that there will be many tools that arrive on the market in the years to come with promises to solve all your skill scheduling woes.  If skill scheduling is something that you have to wrestle with, take your time to define how you will resolve some of the challenges we’ve talked about here conceptually before you pick a tool that promises to solve it for you.