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.

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 NASA.gov.

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-watch about 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.

Archive: July 19, 2016