Blogroll

Month: December 2011

Since it’s that time of the year, here’s a quick list of the top ten blog posts (on this blog) from 2011.

A quick note about the methodology (or lack thereof)….top posts were determined to be so based on the number of hits they received over the year. This probably skews the results to the older posts, but let’s face it, I don’t have the energy to try to calculate a list based on average hits / day to account for this issue (although I could probably gin up a custom formula in Project to do so….maybe next year).

Also, by “2011” I really mean the last 9 months, as this blog was officially launched in mid-March.

This post wraps up the discussion on developing update methodologies. The first three posts addressed some of the basic principles of updating schedules as well as some of the specific mechanical elements within the Microsoft Project desktop client.

The last post reviewed how those principles and mechanisms could be applied to an IT scenario. In this post, I’ll talk about how construction projects may get updated. The goal is hopefully to provide suggestions that may be applicable to your own environment.

Again, there will always be nuances, but the general process will likely be as follows:

In the simplest case, we first update the Actual Start or Actual Finish for the tasks that have actually started or finished. I update the following:

Actual Finish for the Project Started milestone.

Actual Start for Task 1.

Actual Start for Task 4.

Then I set the Remaining Duration field for each of the tasks. Generally, I would enter a Remaining Duration that pushes the new Finish date out to the estimated finish date that my resources are reporting to me.

If I am using Project Server, I might add a custom field for Estimated Finish to the My Tasks sheet, then roll the Estimated Finish field into the Remaining Duration field using a macro as part of the update process.

Then I select the option to Update the Project from the Project tab. In this case, I select the started tasks first and set the options to progress the tasks as follows:

I could also use the Mark as Scheduled option in the Task tab to accomplish the same thing.

Note how % Complete automatically updates…

From there, it’s a simple step to reschedule any unstarted tasks to after the status date – again using the Update Project button.

Facilitating the Process

One method to facilitate this process is to add a custom field and grouping that would group tasks by whether or not they are in progress or unstarted. A formula to establish that in a spare text field might look as follows:

Review the process above, and the view makes things simpler. If I apply the view after I’ve entered all of the Actual Start and Finish dates, then I can simply select the In Progress tasks to progress to the status date and the Unstarted tasks to reschedule after the status date.

Better yet, as discussed above, I could develop some form of VBA automation to refer to that field and update my project with a single key stroke.

Comparing Construction and IT

So now we’ve looked at two different scenarios, what is the fundamental difference? In both examples, we follow the two commandments of schedule updates, i.e. no incomplete work before the status date and no completed work after the status date.

However, we make different assumptions about why the task took longer than expected, i.e. whether the estimate was incorrect or whether the team was pulled off of the task. In the example above, we assume that the team has been working continuously since the Actual Start date for the task. In IT, we assume that the work was interrupted. Are either examples always true in any industry? No, what we’re attempting to do is to define a process that captures the bulk of the project updates, but there will always be tasks that don’t match this particular model.

Once we remove that assumption that the work was interrupted, % Complete becomes essentially useless for data input. In that case, once the resource identifies the Actual Start and the Remaining Duration, the scheduler calculates % Complete for the resource.

Continuing in an ongoing discussion on defining an update methodology….in this episode, I’d like to talk about a couple of scenarios specific to IT. Tomorrow, I’ll talk about construction. The general concept is to introduce two diametrically opposite update methodologies to hopefully identify patterns that may be useful to your onw specific circumstances.

IT Scenarios

Typically, I see IT update scenarios come in two, or maybe three flavors:

Percent Complete

Timephased Actuals (no Project Server)

Timephased Actuals (with Project Server)

Regardless of the specifics, the general process invariably is as follows:

So let’s take the simplest example for illustration purposes. In this case, we have a couple of tasks that should be in progress or completed. The status date has been set for a week after project start.

I then update several of the tasks:

Project Started is 100% complete.

Task 1 is 25% complete.

Task 4 is 100% complete.

Task 5 is 50% complete.

As we can see, since I had the Project settings configured properly, the entire schedule updates automatically. In all, I entered exactly 4 points of data.

Let’s fast forward another week. The status date has been pushed out another week. Let’s say at this point that Task 1 was completed, but Task 5 made no progress as the team was pulled off the project temporarily to perform break-fix work. Similarly, Task 2 hasn’t been started.

I update Task 1.

I then use the Update Project button on the Project ribbon to reschedule incomplete tasks.

…which yields the following result…

…and means my schedule no longer violates the two commandments of project updates, i.e. there is no incomplete work prior to the status date, and there is no completed work after the status date.

Note however that the tasks appear to have been interrupted – which in fact was the case as the teams were pulled off the tasks and put on other work.

Adding Complexity

Now, how do we add complexity to this model? Let’s say that we want to track Actual Start as well as % Complete. In this case, we add the Actual Start field to the project, enter that data, then pretty much continue as discussed above with % Complete.

Easy enough. Now how about Remaining Duration? In this case, I might implement the following process:

Set the status date.

Import/Enter/Add the Actual Work or % Complete.

Reschedule incomplete work after the status date.

Update Remaining Duration.

Dealing with Interruptions

To focus on a specific scenario, what about if the team was pulled off of a task, and you’re not sure when they will be able to return to the task? If we follow the process above, the task will resume again right after the status date. That may or may not be the case. Perhaps we might assume that Task 5 will resume a week later.

In that case, we would add the Resume field to the project, and update that to control when we believe the team will return to the scheduled task.

…and that’s essentially an oversimplified view of updating projects in an IT setting. If you actually imported timesheets from Project Server (or manually entered them in the Resource Usage View), you wouldn’t really change up the process all that much. In that case, simply import the data, reschedule incomplete work after the status date, then review the Remaining Duration and Resume fields to ensure that the project data appears correct.

Now, of course there are nuances and complexities that will be specific to your own scenario, but hopefully that captured the essential basics of updating an IT project.

Tomorrow, let’s look at the same principles applied to construction projects.

This is the third post in a short series on determining an appropriate enterprise-wide project update methodology….or actually, just determining an appropriate project update methodology – as what I am writing about could be implemented on a single project just as well as across a large number of projects.

In the previous posts, I talked about reviewing some of the organizational factors that might influence how the update process is structured. I then went into the Microsoft Project client to review some of the settings that control how updates are applied.

In this post, I’d like to continue looking at the mechanics that govern how updates get entered in the system.

On Setting the Status Date…

First off, the status date is a critical bit of the update methodology. I am constantly amazed by end users who attempt to update their schedules without using the status date. Personally, I don’t really understand how such a thing is possible.

Put simply, the status date is the last date upon which the the data input into the schedule model was complete. If we update the schedule every Friday, and today is Wednesday, then the last status date would be the previous Friday.

The issue with the status date is that when it is used in a Project schedule that doesn’t display the time, simply entering a date will default the status date to 8AM of that date. So if I enter Friday as 12/16/2011, then the system will assign a default of 12/16/2011 8:00AM, which in a traditional corporate calendar translates essentially into 12/15/2011 5:00 PM. Depending on the specific update methodology, this may get confusing.

Take the following example….in a construction scenario, I am importing Actual Costs from an external application and applying them to the project, having them accrue as of the status date. If I update my schedules monthly at the end of the month, and I set my status date for 12/31/2011, then the system will accrue all costs as of 12/30/2011 and not as of 12/31/2011. In theory, no status will appear on that day.

For this reason, I’d recommend as best practice either specifying the status date as 5:00 PM on a specific date or simply set the status date for the day after the “real” status date. In an IT project, where I update the schedule each Friday, I would simply set the status date to the Saturday following to make updates easier. In a construction project where I update at month end, I would set the status date to the first of the month following.

Lastly, here’s a trick to get the status date to appear in your schedule…and a filter to show in progress tasks…

Identifying Tasks to Update

So now we’ve identified how to enter the status date properly, the next issue lies in identifying which tasks need to be updated. In theory, depending on your schedule granularity, you probably will never have to update more than a couple of tasks each update cycle. If you set up your schedule properly, with the appropriate dependencies, updating the in progress tasks each cycle will result in an up to date schedule model.

My recommendation is to simply develop a filter or a view that will identify any task that requires updating. This process has been made a bit more complicated with the introduction of manual scheduling in Project 2010 which necessitated the conversion of the default Start field to a Text field. In 2010, the way around this is to develop a filter on the Scheduled Start field. (Click here for more on that…)

This is also complicated by the fact that the Status Date is not available as a task level field. Hence, the first step is to make the status date available for use in a filter. To do this, we use a custom Date field, and set it equal to the Status Date.

Then we create a filter that looks something like this:

…and I think that’s that. Now we have the stage set, let’s get back to some process discussion with my next post on the topic….

In that last post, I talked about some of the basic considerations in defining a schedule update methodology, and in ascertaining whether or not a process is fit for purpose. In this post, I’d like to continue that discussion and then get a bit more tactical to look at how Microsoft Project may be configured to support your requirements.

First off, let’s look at the two commandments of scheduling….

The Two Commandments of Updating Schedules

…and I should mention that these are probably heavily inspired by some of the content found on fellow MVP Jim Aksel’s blog here. There’s a lot of great content over there worth checking out.

After updating your schedule, you should always review it to confirm that the following commandments have been met:

Thou shalt have no incomplete work prior to the status date.

Thou shalt have no completed work after the status date.

Now the actual implementation of these two commandments may vary by organization, but as long as these conditions are met your schedule is probably pretty good – or at least better than the other PMs in your organization, which is really the quality standard we should all strive for.

Flipping the Right Switches

There’re a lot of checkboxes and radio boxes that control how data gets into the Project schedule, but I’ve almost always focused on the same basic ones. The primary settings reside in the File > Options > Advanced tab.

Here, I would almost always recommend toggling the settings the way they’re displayed above. I can’t recall if that is the default, but it really should be. These settings affect tasks updated using the % Complete method. For instance, if you configure your project as shown above, entering 25% on a behind schedule task will automatically push the remainder of the work after the status date…

Similarly, all completed work will be shoved to the left of the status date which makes logical sense. You can’t exactly do work in the future can you? Similarly, you can’t go into the past and do your work on schedule given that we’ve already missed that opportunity.

The secondary options in the above illustration, i.e. the options to move the start of remaining work and the end of completed parts forward to the status date are determined by how your organization wants to track work.

For instance, the first unchecked option, “And move start of remaining parts back to status date” is basically governed by how optimistic your organization is. If you’re an optimistic sort, you can check that. Then, if any task progresses ahead of schedule, the finish date will move to the left. In the real world, I rarely see this, as what typically happens if we’re ahead of schedule is that the team slows down….and even if the task finishes ahead of schedule, the successor team is probably not ready to start ahead of schedule….assuming of course that we don’t have dedicated resources. If you do have dedicated resources, you might make different sets of assumptions around how you would like the update cycle to work.

Note that, as I learned recently, all of those settings are negated if the Updating Task Status Updates Resource Status checkbox is unchecked. I am not sure why the functional dependency is there, but if that box is unchecked, the schedule will not apply the options above.

I almost always define a default setting for these options and incorporate that into the installation package – something which can be done either with these instructions from Paul Mather, ensuring each template is configured with these settings, or if a macro is used to facilitate the update cycle, adding those settings to the macro to ensure they’re all set the way we need them to be.

Lastly, for good measure, the status date is correctly set in either of the two locations identified below.

The status date may also be set on the ribbon, but note in 2010, that this setting is a bit misleading. There’s an issue where if the status date hasn’t been set, it appears to display today’s date. That’s not really the case though, as in the above illustration, the status date is blank.

Next up…let’s talk more about setting the status date and on a couple other mechanical details before we get into specific scenarios.

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.

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?”

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.

I figured that I’ve been focusing on issues of process and strategy for a while, and it was probably time to get back into the mundane world of technical delivery for a post or two. Variety, after all, is the spice of life (which leads me to suspect that this idiom probably doesn’t translate well into some languages and cultures that don’t really respect spice or culinary diversity, but that’s a digression for another topic.)

Back to the point of this posting though, this is a Project Server 2010 question that I’ve seen come up quite frequently both in client discussions and on the newsgroups: “How do I prepopulate specific fields within an Enterprise Project Type?”

The answer is that it’s actually quite simple to do so. Essentially, all we have to do is to populate the fields in a Microsoft Project Professional template and save the template to Project Server. Associate the template to your EPT, and voila, when you create the project, the custom fields are already populated…..sort of.

Kicking it off….step 1: open a MPP file and populate the fields. Even if you’re not ready to include tasks in a standardized template, that doesn’t matter. You can still create a template with no tasks.

Save the project file as a template.

Now, go into PWA and associate the template with an Enterprise Project Type.

….and that’s pretty much it…with one relatively minor caveat: the fields will appear blank within the PDP until the project record is saved for the first time.

For this reason, I’d recommend keeping only the basic minimum required fields on the first PDP created with the project, and then add any prepopulated custom fields to a subsequent PDP. Honestly, that’s probably a best practice anyway. When you save the project after completing the first PDP, the fields will be populated by the time you navigate to the second PDP.

If you add the prepopulated custom fields to the first PDP, they will appear blank until the project is saved – which needless to say is confusing to the end user and would probably result in them just filling out the field anyway, thereby defeating the purpose of the exercise.