Defining an Update Methodology (Part I)

Every organization has a different level of scheduling maturity, and it’s rare that this scheduling maturity is homogenous across the entire group of schedulers.  Some are invariably more advanced than others, which necessitates almost a sliding scale of process definition – a rigid, detailed definition for the more advanced schedulers, and a less defined process for the schedulers still learning the “dark arts” of project scheduling.

..or perhaps I have that flipped.  Maybe the more rigid processes should be for the less mature schedulers, and the less rigid process should be for the experienced ones.

Regardless of which side on that debate you take, I would say that inevitably in any exercise in EPM maturity bootstrapping, there will be a discussion about what the planned organizational update methodology will be.  That may be a broad discussion with the entire organization as an effort to define a standard or that may be a limited discussion with a specific group of schedulers who have proclaimed themselves ready for it after scheduling for some time.

Like many events in the EPM deployment lifecycle, it can be difficult to gauge when schedulers are ready for this discussion.  Try it too soon and you turn them off the engagement due to overly rigid processes.  Try it too late, and you end up with multiple, very specific views on how to update projects that need to be reconciled into a single consensus.  I personally prefer to wait until a couple people start asking me very specific questions around updating schedules.

…and sometimes, just sometimes, the update methodology is logically derived from stated organizational reporting requirements.  That always simplifies things.

So I figured I’d waste a couple of electrons and go ahead and post a recap of various update methodologies to give a range of options.  In this post and the next couple of posts, I’d like to address how to define an update methodology, and then throw out some examples from diametrically opposite fields, specifically IT and construction.  Hopefully, those examples may give you something to think about as you design your own update methodology.

For today’s post, I’ll focus on the basic principles of updating projects….

Focus On the Why and Then the How

The first question I always ask a scheduler when attempting to suss out an appropriate update methodology would be “What information do you really care about?”

Let’s face it, Microsoft Project, and any other desktop scheduling tool allows users to input a whole slew of data to update a project: Actual Start, Actual Finish, % Complete, Physical % Complete, % Work Complete, Actual Work, Actual Duration….not to mention timephased actual data imported from timesheets or LOB applications.

At the end of the day though, I would submit that there’s really only one point of data that is absolutely required at each status update cycle: “Are you done yet?”  That keeps things simple and binary.  Picture it, at your next status meeting, just ask every resource that one question about any ongoing tasks.

Of course, that question only works when your tasks are defined granularly enough.  Specifically, my recommendation is generally to cap your task durations at a maximum of one reporting period, whether that be a week or a month. When tasks begin to exceed a single reporting period, that one question of “Are you done yet?” begins to lose effectiveness.

But think of it, and not to quote fellow MVP Eric Uyttewaal too much, but there was a great section in his Forecast Scheduling book which talked about how project managers only care about the future.  Accountants care about the past.  Do I really care about all of the historical data in a project schedule?  Nine times out of ten, I would say, no, I don’t care about the actual duration.  All I want to know is if it’s done or not.  That gives me enough data to replan my remaining schedule.

That simplicity begins to break down when we start throwing effort and cost into the equation.  Once I begin tracking that, I do need to start collecting a whole lot more data points – although again, the data collected needs to be mapped to my specific needs.  Do I need to know when the work was performed?  Not really.  All I care about is how much of my budget has been consumed, so that I can define how much of my budget is left, and how much work there is remaining that needs to get performed within the constraints of that budget.

So even in a resource consumption scheduling model, I often don’t need a complex update system.  I just need whatever will tell me what’s left in the resource bucket, how much work is left, and how much time I have left to get that work done.

Let’s throw another layer of complexity onto our analysis.  What about if we’re performing these projects under the guidance of a PMO charged with “continual process improvement” or as I wrote a couple of weeks ago, managing outcome improvement?  Then again, we need to start tracking more data, as continual process improvement usually comes hand in hand with metrics on performance, and identification of methods of improving (i.e. shortening) the duration of similar tasks on similar projects.

So that’s the ‘why’…

…But Let’s Be Realistic…

The second question you should ask yourself when planning an update methodology is really “how much authority does the PM have to request/demand data from the resources?”

If you’re a lowly PM working in a research organization where you’re trying to collect task status from highly educated Ph.D’s, good luck collecting historical data, timephased actuals, or any of the other points of data that a PMO might desire.  Unless that practice is deeply embedded in the organizational culture, you’ll have a tough time getting the time of day from your resources.

Similarly, unless you have the organizational might backing you up, if you’re a construction scheduler working to support a construction PM, it may be tough for you to penetrate the complex network and relationships of contractors that are actually doing the work on your project – although there you’re assisted by the fact that you can always define your data requirements as contractual obligations.

Hence, you want to balance out how much data the organization is requiring with how much data you can actually get from your resources.  Ensure that you factor in the difference between the level of both your formal and your actual authority.

Oh Yeah, One More Thing

In writing this series of blog posts, I also realized that there’s probably one other key bit of environmental background that we need to consider when planning an update methodology.  Are the resources dedicated or not?  If the task is behind schedule, can we make the default assumption that it’s behind schedule because the resource was pulled into another endeavor (IT) or because the resources doing the work encountered a variable that slowed progress (Construction).  There’s never going to be a firm rule that applies to 100% of the cases, but you can generally identify a default behavior.

Next up…we continue to look at the basic concepts of updating a schedule and how those are configured in Microsoft Project.

Defining an Update Methodology (Part I)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s