All About Time…for Project Managers

 

An even briefer history of time…

After the turn of 20th century, Albert Einstein famously published his Theory of General Relativity, where the general notion of time became space-time! Before that, great minds from Newton on agreed that “time” was simply a measurement between two points on a clock. Imagine project managers of the day (Henry Ford, Henry Gantt, Fredrick Taylor, Lillian Gilbreth, etc.) muddling over this new idea of space-time, and having their heads all explode at the same time. Surely this was not relative to the factory floor, where X number of widgets could be produced in Y amount of time. After all, that was what could be observed, and therefore must be true, right? Years later, we would all know differently…

 

From Newtonian to “something else”

Since the world of theoretical physics was light-years away from earth’s manufacturing floors, now cranking out locomotive, automotive, and all forms of money-motivated products, this new wrinkle in time was blithely ignored by almost all, and the world went on to become what we have today—an entire society still operating under an illusion of time (or, at best, a misunderstanding of time). In fact, if one cares to think deeply about it, things are much worse…

Let me pose this axiom: every human being perceives time differently, dependent on where they are, who they are, how they feel, and what they are doing. We can look to Einstein for a good example:

“When a man sits with a pretty girl for an hour, it seems like a minute, but let him sit
on a hot stove for a minute — and it’s longer than any hour. That’s relativity.”
 -Albert Einstein

Let me throw in another example of my own. This is one seen repeatedly in various forms while doing humanitarian work in Asia and Africa where, sometimes, I find myself helping ancient cultures do ultra-modern things like installing toilets or programming computers. What I’ve noticed is that different cultures can perceive time quite differently, or with just slight variations from the norm (the Western European norm is the oscillation of a single atom of caesium-133, spun over nine billion times and thus representing 1 second of time). That definition of normal time is the basis of an atomic clock, and already, I’ve lost half my PM class…

I’ve worked with folks whose perception of time ranged from “the Past…to Now…and into the Future” to something less conventional like, “there is only Now” or “there is a Future, but I’m not sure how long it takes to get there,” or “the Future is just the Past, only later – rinse and repeat.” In Nepal, we have a saying, “bholi, bholi,” which roughly translates into English as, “If you want this next week, I can deliver next week, or a few days later than next week… or perhaps, not at all.”

 

Implications of time not traveling well…

The implications of these discrepancies from the norm are often disregarded by project managers, and certainly ignored by all PM apps on the market today. After all, time is an important variable used in all PM math. To be more specific, in PERT we see this for calculating expected durations of linked tasks:

 

Figure 1. https://youtu.be/_-rrXdPal8U

 

Figure 1, time is represented as ta, tm and tb, – as a representation of a most optimistic time period, most probable and most pessimistic, respectively. We may think, “That’s solid, great job!,” but each of these base numbers (see Activity A) are essentially pulled from the ether by a range of project managers, each with differing experiences, backgrounds, cultures, and in general, perceptions of time. Paraphrasing the arguably greatest genius of our time, were you sitting next to a pretty person, or were you sitting on a hot stove when you came up with that number?

Alas, we have come to the root problem that defines all ills of project managers worldwide. While, as PMs, we have figured out how to calculate the efficiency of schedules (to some unknowable degree of accuracy), we have no math for the effectiveness of our schedules. Hence, most all projects are under-performing or failing about 2/3 thirds of the time. Unfortunately, this is causing great waste (and suffering) for most of humanity.

My favorite example is a project intended to provide home toilets for a small village in Nepal, which was completed very late and way over budget (“bholi, bholi”). While the outdoor home toilets were efficiently built to Nepali standards, they were not effectively useful. In fact, the toilets had been repurposed into “menstruation huts” (where women were imprisoned during menstruation). Males were continuing to defecate in the fields.

 

Time and MS Project

Henry Gantt was a mechanical engineer and management consultant who is best known for his Gantt chart developed back in the 1910s. Here, time is represented using the 1582 Gregorian calendar, and overlaid onto that calendar is a two-dimensional representation of time for tasks (task bars). Additionally, we have, in the Gantt chart, a one-dimensional representation for milestones (just a dot in time) all linked and flowing from left to right.

International PMs working in remote parts of the world are already troubled, as many don’t use a Gregorian calendar in their daily lives. For example, there are billions using calendars based on another religions, such as Hinduism or Buddhism.

To build this visualization in Microsoft Project (now 35 years old), we enter our atomic clock-like representations of time in minutes, days, weeks, months, etc. and encapsulate the amount of time it takes to do the task specified in terms of Fixed Duration tasks, Fixed Units tasks, or Fixed Work tasks. These values are, in turn, used by the scheduling formula employed by MSP (Work = Duration x Units) to give us the amazing feature of just entering in two of the variables to calculate the other. In short, this is what sold millions of copies of MSP and allows PMs to enter actual work or progress values for a task and then have MSP re-calculate and adjust the schedule accordingly… but according to a lot of seemingly obscure rules.

 

https://www.teachucomp.com/task-types-in-microsoft-project-tutorial/

 

Okay, now I’ve lost the other half of my PM class…

Sure, all of this MSP stuff works programmatically, and has for over three decades, but I have to ask (much to the chagrin of my PMI buddies), how effective is this type of scheduling in the real world – especially when humans are involved?

 

Is it time for Time to be represented differently?

I’ve spent a lot of time working in this field, probably for about as long as Microsoft Project has, and I’m thinking that it is high time for a different way of representing project work – still based in math – but in the math of the 21st century and not Newton’s 17th. To illustrate this need, here’s a thought experiment for PMs who are also sci-fi fans.

Imagine you are on an interstellar mission to another star, with a planned return to earth, and traveling through the universe at the speed of light (or close thereof). Could you use Microsoft Project to plan the mission before you left? While on the spacecraft, could you use MSP’s Newtonian math to calculate task completion dates en route? As it turns out, according to the confirmed laws of 21st century physics, you can’t (see the twin paradox). So, that’s something to think about.

It comes down to this: is there a better way to represent a project, instead of within Henry Gantt’s 1910 2D-chart? Logic tells us,“Of course, good heavens, I hope so.” Well, let’s start by adding “space” into the mix, as that’s one of the missing ingredients, right?

If you are confused at this point, just hold up a printed Gannt from your current project, pick one task bar, and bend the paper to line up the starting point of the task with the ending point. Now take something sharp like a pencil, and forcefully pierce the paper at that point, connecting the dots. That’s curved space time. Useful? Not really, but I bet it felt good skewering your schedule.

What about a more traditional geometric representation of the Gantt, such as a 3D cube would provide? Take a look at this idea from Jean-Yves Moine, who in conjunction with Dr. Paul D. Giammalvo and Xavier Leynaud, published a paper titled “The 3D Work Breakdown Structure Method,” where they demonstrate how many PM-related 2-D tree structures (such as an org chart, WBS, etc.) can be linked and shown in a 3D space (albeit with a few new conceptual axes). With this idea, the model calculates Earned Value (EV) and several other PM favorites using different (but traditional) math without anything related to worm holes and collapsing wave functions (see Figure 2).

 

Figure 2. Jean-Yves Moine, The 3D Work Breakdown Structure Method, PM World Journal, Vol. II, Issue IV, April 2013.

 

Love it! Moine also adds that this model can give back answers to important project questions, depending on how the model is “twisted” on its axes, just like a rubrics cube. I find that fascinating, don’t you? While we are now seeing time in relation to space (Einstein would approve), the model is still dependent on the notion that we humans can accurately estimate initial durations while factoring in all the other variables of our physical (and perhaps spiritual) world. Until we have a way to factor in the bits that represent effectiveness (vs. efficiency), we won’t ever have a predictive and truly representative model of our projects on hand. We also won’t really understand how a change in one project changes another, or why one project fails, and another succeeds.

 

Conclusion…or is it?

While we project managers stare at time two-dimensionally all day long, modern physicists think that time is a dimension on its own, and that this has implications that are profound making our current PM math seem woefully out-of-date.

Our software tools also remain fixed in the absolute Newtonian world of days gone by. While we can enter time in our schedules in various ways (using the atomic clock and the formula, Work = Duration x Units), we must understand that this approximation can be wildly inaccurate and ineffective as we try to predict project success, react to changes in our plans, and yes, even to calculate an accurate budget.

We might need better visual representations (and better math), in order to cut down on the waste we currently see within project work today. It makes sense to look at “a project” in the same way that we look at any other collection of matter in the universe. We should think of better ways to predict “project results over time” just as we predict other states of matter found in nature. (After all, we did predict the Higgs, and then even found one.)

This likely requires a rethink of what a project really is for the 21st century and beyond. It certainly requires a rethink of what project time is, vis-a-vis with our newer understanding of quantum mechanics to include entanglements, de-coherence, and an explanation of why wave (and perhaps work) functions collapse or not.

Let me leave you with one last time-based thought experiment! Imagine you are a PM scheduling work in 2019. How much time does it take to have an idea? Let me know in the comments below J.

 

Next Webinar

Attention PMs! How to Create a Healthy Project Environment

Written by Jigs Gaton
Jigs Gaton is CEO of Phoenix Consulting and Training Worldwide, a company that helps developers design and implement better programs and build capacity with training and other resources. Jigs has over 30-plus years of experience in both the private and public sectors working as a project manager and PM consultant. He's currently based in Kathmandu, helping organizations with post-earthquake reconstruction and other disaster-relief efforts.
Share This Post
Have your say!
00
4 Comments
  1. A very interesting article with insights that all PMs should understand.

  2. Worst of all is a conservative estimate for the task, “Produce an idea.” It contains the median estimate, plus a task buffer, which together may give it about an 80% chance of success and 20% chance the estimate will be exceeded. A schedule consisting of tasks with conservative estimates will be longer than a schedule with median estimates. With median estimates, half the tasks are expected to take less work than the median, half more.

    However, with the objective to complete each task by it’s planned Finish date, human nature causes most resources to delay the task’s Start until there remains before the planned Finish date only time for the median estimate. Hence, 50% of the tasks will be late; less if there are surprises, e.g. how most students studying for an exam.

    Better is to have projects finish in a shorter time and have a more reliable delivery date. The Critical Chain method provides this pattern. It uses a schedule with tasks estimated with median values, plus a project uncertainty buffer just ahead of the product delivery task. If the project buffer is penetrated 1/3, prepare a recovery plan; if penetrated 2/3, implement the recovery plan back to what is needed for the remainder of the project. But, rather than the objective to finish tasks on time, the objective has to be to start tasks on time.

    But, creative tasks, such as getting useful ideas, have two parts, the discover part and the productive part. The discovery part is like solving a maze in which the number of turns correspond to the number of alternatives to be investigated.

    Try the left path, try right path, and walk at a particular speed. Each turn has 50% chance of being the useful direction. If the maze has N turns, then the likelihood of all turns being correct is 50% raised to the N power, which becomes a tiny probability. The maximum time through a maze if all turns are initially incorrect may be double the time to go down all paths. Assuming a distribution, a range estimate can be made that have a probability of being sufficient. Once an idea at the end of the maze is found, there remains the productive task, which may be estimated with a narrow range.

    So, using range estimates and Critical Chain recovery management, projects are shorter and rarely need descoping or sacrifices of testing coverage. But, how can range estimates be entered in Microsoft Project. Easy. Insert two number columns, one for median estimates, the other column for high estimates (mistakenly called the “pessimistic” estimate, since attitude is irrelevant). Then, copy/paste the high estimate column into the Work column to get the delayed delivery date. Copy/paste the median estimate column into the Work column and get the expected delivery date. Take the difference. Use part of this difference as the project uncertainty buffer. The larger the part used for the uncertainty buffer, the smaller the number of products delivered late, descoped, or insufficiently tested. Track progress against the median estimates.

    One more factor: adjust each resource’s Assignment Units to include their average productivity. For example, if Bill averages 4 hours a day for working on tasks but takes 50% longer than the average resource, for a 16 hour task for the average resource, Bill faces a 24 hour task, taking 6 days duration, rather than 4 workdays. Thus, Bill’s Assignment Units is 16/(6*8) = 33%, not 50% for the average resource.

    So, time is relatively flexible.

  3. @Oliver Gildersleeve Jr, I loved every word of that comment, thx! But let’s think about Bill for a moment, if Bill is taking 50% longer than the average bear, why not replace Bill with Jill? I’ll be discussing these and other people conundrums in the upcoming 3rd part to this series: All About PEOPLE… for Project Managers. Part 2 of this series will deal with WORK, and the problems there 🙂 Cheers, Jigs

  4. @ Gary Richardson, thx 🙂

Leave a Reply