Looks like when I wrote that post on how to incorporate Resource Engagements into the portfolio analysis module of Project Online / Project Server 2016, I left out one critical step.
For resource engagements to show up in the calculated portfolio demand, you’ll need to open the Project Information dialog box within Microsoft Project Professional and toggle the calculation settings – then republish the project.
Note that the option only appears after the project has been saved to Project Server.
Catching up on some of the discussions from the last conference I attended, the Critical Path Management conference. Had a good hallway conversation about the concept of Critical Path Drag.
Not familiar with the concept of drag? If you’re at all interested in the world of scheduling, it’s well worth the time to check out this article in Wikipedia.
Read the article and curious how to calculate this in Microsoft Project desktop? Here’s a helpful macro courtesy of Tom Boyle.
One of the takeaways from the recent Construction CPM Scheduling Conference in New Orleans last week (other than a couple of hurricanes on Bourbon street) was an acknowledgement that while Microsoft Project does indeed enable best practice scheduling, by default many of the required features are turned off. This causes some frustration on behalf of the scheduler who must hunt deep into the Options panel to identify and select the appropriate options for each new project.
To assist in this endeavor, I wrote this little macro. It basically goes through the options and sets them to optimize the scheduling interface for detailed construction scheduling (and therefore may have to be tweaked to support project scheduling in other domains). In the past, I’ve triggered this macro whenever I run any other scripts on the schedule, i.e. I’ve written scripts to facilitate the update process….which call this routine up before going into collecting the update data.
Did I forget a key setting? Let me know and I’ll update it accordingly.
Sub ApplyDefaultSettings() Dim Continue As String Continue = MsgBox("This macro will now apply the standard PMO settings to the project schedule.", vbOKCancel, "Confirm") If Continue = vbOK Then '1 - Project Settings With Application.ActiveProject .AutoTrack = True 'Sets the task status updates resource status setting .MoveCompleted = True 'Move completed work prior to the status date. .MoveRemaining = True 'Move incomplete work after the status date .SpreadPercentCompleteToStatusDate = True 'spread %Complete to the status date .NewTasksCreatedAsManual = False 'Turn off manual tasks .DisplayProjectSummaryTask = True 'Display project summary task .AutoLinkTasks = False 'Do not automatically link tasks when added to the schedule .MultipleCriticalPaths = True 'Calculate multiple critical paths End With '2 - Display Settings Application.NewTasksStartOn (pjProjectDate) 'Sets new tasks to default to the Project Start Date Application.DisplayEntryBar = True 'Displays the Entry Bar Application.Use3DLook = False 'Turns off 3D which used to cause printing issues '3 - Gantt Chart Settings GridlinesEditEx Item:=12, NormalType:=3 'Set the Status Date line GridlinesEditEx Item:=12, NormalColor:=192 GridlinesEditEx Item:=4, NormalType:=0 'Turn off the Current Date line GridlinesEditEx Item:=0, Interval:=3 'Set dotted lines on every third Gantt row GridlinesEditEx Item:=0, IntervalType:=3 GridlinesEditEx Item:=0, IntervalColor:=8355711 GridlinesEditEx Item:=13, NormalType:=3 'Set dotted lines on every vertical top tier column GridlinesEditEx Item:=13, NormalColor:=8355711 End If End Sub
Reading James O’Brien and Frederic Plotnick’s definitive book on construction scheduling, and I came across this passage that was rather thought provoking (well, it is for me, but I’m a bit of a scheduling nerd):
“….the primary and secondary purpose of the [schedule] must be to promote the project. A tertiary purpose to support cost control, facilities management, or home office concerns should be acceptable as long as such do not detract from the primary purpose.
“Enterprise Scheduling software and implementation must be carefully managed to prevent increasing the burden of such on individual projects.”
First off, I’ll emphasize that Enterprise Project Management (EPM) is a rather broad term encompassing many of the capabilities required to deliver projects effectively: portfolio optimization, business case development, business architecture, etc. In this case, we are focusing on a subset of these capabilities, specifically the field of enterprise scheduling.
Now, when it comes to enterprise scheduling, it seems to me that we are typically confronted with two different kinds of organizations in a “normal” engagement:
I would say that outside of simple question of visibility, most of the organizations I’ve worked with that fall into the latter category are also dealing with issues related to the ongoing “Great Shift Change,” where many of the schedulers who have highly mature (albeit unconsciously competent) processes are retiring, and enterprise scheduling is seen as a way of capturing their knowledge in the form of process and templates so that it may be passed on to the next generation of schedulers.
This also speaks to the role of the dashboard in an EPM engagement. Specifically, as I always point out, there are two sets of controls being implemented here:
As annoying as they may be, the latter set of criteria are what’s important in driving up scheduling maturity. They provide the reinforcement metrics required to take a group of engineers with limited scheduling experience and drive them up the maturity curve – which is most often what is called for when an organization decides to embark on an EPM journey.
The risk though, and I’ve seen this again and again, is that the organization gets lost in the wilderness of dashboard visibility into key milestones without spending the time and effort to build scheduling maturity. That’s probably the main place where EPM engagements go off the rails. In this case, the “schedulers” become obsessed with reporting the desired data – at the cost of developing valid schedule models. (Your Schedule is Totally Mental)
So how do we avoid the dead end low-value result of having a bunch of simple reporting schedules? Through education of the actual folks doing the scheduling. Through emphasis of the right metrics. Through the use of the correct information in driving the day to day decisions required to manage complex programs and portfolios of projects. Most importantly, perhaps, through not skimping on the level of effort required to train and support these schedulers (and their bosses) as they make a mental leap from project managers who do some scheduling to actual bona fide schedulers.
That’s right, excited to be heading out to New Orleans for the Construction CPM Conference…..where I will attempt to strike an appropriate balance between “Three Full Days of Study and Training in the Critical Path Method of Planning & Scheduling Analysis” and enjoying the run up to the annual festivities (in a restrained and tasteful fashion, as always).
Come look for me in the vicinity of either the Microsoft booth or the bar – depending on what time of day it is.
http://www.constructioncpm.com/
Looking for some more posts on leveraging Microsoft Project for construction scheduling and/or implementing project controls in an environment that supports the same?
One of the fun things about my job is that often I find myself knitting together multiple disparate systems and scheduling philosophies. In this case, I’m working with a client on a field scheduling problem and we’re identifying how the multiple constituencies within the organization can collaborate to deliver a high level of service to the customer base – while at the same time ensuring an appropriate level of cost.
From a very macro level, we are now trying to solve an equation for two optima…..how do I deliver world class service to a customer base that needs responsive, predictable performance….while at the same time juggling crews and equipment such that I am ensuring maximum capital utilization?
When we are solving for one or the other optima, life is simple. I can simply get more resources than I need, have them sit idle and waiting for the work to pass through – in which case the work doesn’t get delayed. Or I can simply schedule the crews according to their optimal schedule – which may not respect commitments to my clients (the classic “cable man” or “appliance delivery” scenario).
We see the same discussion in other domains. For example, from some of the discussions I’ve participated in within the last couple of weeks:
Theory of Constraints provides us some guidance here, as in TOC, we would identify the bottlenecked resources, i.e. the crews, and then ensure that the deterministic scheduling approach creates a backlog of work in front of them, i.e. the bottlenecked resources are always utilized.
First, let’s look at how to approach this via scheduling – and this is quite similar to a discussion a while back on release scheduling. The basic gist is that the deterministic schedule only predicts an early readiness date for the construction crew to start their work….and then identifies a window within which they will perform the work. The length of that window is then defined by the anticipated volatility and workload of the crew schedule. (Which would mean that the more work they have….or the more variables that would be expected, say during a season where weather disruptions are to be expected…would mean we would want to lengthen that estimated window.)
As the readiness date approaches, the deterministic schedule dates may be adjusted based on real time field conditions. At a defined milestone, the readiness status is handed off to the construction team….who then slot the work into the schedule for the next planning period, i.e. 2 weeks or 1 month.
This means a couple of things:
From a communication perspective, we need to ensure that the systems/groups communicate very specific data between each other. Using the model above, that would look something like this…and feel free to substitute any relevant constituency for “Crew” in this picture, i.e. drilling rigs, IT testing resources, etc.
The key here is to recognize the respective value that both perspectives have on the fundamental problem, i.e. that we’re attempting to solve an equation for both speed and efficiency. Hence, we need to build a system (which includes people, process and technology) that can solve – and reconcile – for both.
As many PMP trainers will tell you, one of the advantages of enterprise wide PMP certification is that all of the PMs within the organization start using the same terminology. Everyone suddenly is able to speak in the same language. That’s a significant part of what we do when we work with clients. We often need to unpack the terminology that’s in use within the organization – and often we need to evaluate the actual practices being performed and map them to an EPM framework.
In this vein, it’s always impressive how much organizations attempt to pack into a project schedule. Often times, there are very disparate concepts that get thrown into a project schedule – which don’t make too much sense, and may present an obstacle to the organization actually managing projects effectively.
Take the example of the word “phase.” The PMBOK defines a phase as a collection of tasks, usually culminating in the creation of a major deliverable. In the software world though, and I’m talking specifically about the world of Microsoft Project Server and SharePoint workflow, a phase implies that the project (or entity) is in a specific state, i.e. “Pending Authorization, Active, On Hold, Completed.” In effect, a lifecycle phase is a label that we apply to the project that is then inherited by all of the various entities that comprise a project: resource work, allocated cost.
In this way, we have cost that is associated with projects that are still pending approval, and we have cost that has been allocated to projects that are currently active. The phase label presents a convenient way of classifying this cost. If we use this mechanism, by default, a project may only exist in a single phase. For a project to exist in multiple phases at the same time typically requires that we model the project differently, i.e. as a program – where we have a program lifecycle that is comprised of multiple projects – and each project is in a distinct phase of the project lifecycle. In fact, I typically use that as a test to see if we’ve defined the phases correctly. If it’s possible to be in multiple phases at the same time, we didn’t get the lifecycle definitions correct.
So that’s how the term “phase” is now used in the world of PMIS system design. Now let’s talk “schedule.” On this, I tend to go with the PMI definitions, which state that the schedule is a static representation of a schedule model – with a schedule model being the accumulated logic and information related to a project combined to provide a predictive forecast of time, cost and effort. Each week, you input the latest developments into the model and generate a revised schedule.
This is where things may get confusing. Schedules often include a logical grouping of tasks – often called a phase. Note, however, that this is generally not the recommended way to structure a project schedule, as the general consensus in the scheduling world (at least within the circles I run in) is that schedules should tie directly back to the WBS, and a WBS should always be product oriented, not phase oriented.
Hence while a schedule model may be structured to map to a specific phase structure, that’s not necessarily required or even desirable. In fact, one could argue that a phase structure supersedes the actual schedule of a project – as it’s very rare to actually incorporate the preauthorization, business case development steps in the schedule – which doesn’t typically get developed until a bit later in the lifecycle. The same applies for post-project benefits analysis – which needs to occur, but is rarely incorporated into a project schedule.
On the other hand, it’s quite common to leverage the schedule model to forecast when a project will transition from one phase to another, i.e. to include milestones within the schedule that provide some prediction of when the project will progress to the next phase.
So we now have two terms which are often conflated:
And the last item that often gets confused with these two, surprisingly enough, a checklist. What is a checklist? It’s a collection of tasks or conditions that must be met for a specific item to be declared completed. Sound familiar? Sounds kind of like a phase, i.e. we have a collection of things that must be completed before the project may move from preauthorized to authorized. Similarly, it sounds a lot like a schedule, which contains a series of tasks that must be completed for the project to be completed.
The difference is that a checklist defines either conditions that must be met – or tasks that must be completed, but those tasks are so small and granular that they are not worth including in the schedule model. We simply summarize the checklist process as a single task within the schedule, and capture the verification procedures that drive the checklist outside of the schedule. At least, that’s how it should work – too often we see clients incorporate the checklist into the schedule model and try to model overly granular tasks in the schedule.
Once we’ve unpacked these terms, we can focus on improving each one. Until that is done however, what we have is an unwieldy procedural mess.
In my training sessions, I often use sports metaphors for project schedule modeling – this, despite my utter lack of any sort of athletic ability and pathological indifference to most sporting events. The thing is, sports events are great examples of predictive models.
Take the World Cup for instance. If I were to ask you who would have taken the Cup way back at the beginning of this thing, you would have selected from 32 teams. At a basic level, we could say that each team has an equal chance of winning. Of course, we can make the model more complex. We can look at individual player performance, historical records, playing style, locations in which matches will be played….. When we throw all of those together, we can create a model of the top 5-10 favored teams.
What is this doing? It’s adding information to the model to predict the future – and providing a range of potential outcomes. Like any schedule, as I learn additional information, I include that in my model and refactor the results. From where I sit at the time of writing, we have now gotten down to the quarterfinals. Of the 32 teams that started, 8 are left. Clearly, I can remove 24 of the original candidates from the list of potential winners.
Simply by removing those 24 from the list, I have greatly increased my chances of being correct about who will win the championship. Can I tell exactly who will win? No, but I can apply my data modeling structure to the remaining teams and come up with a much better prediction than when the games started.
Extrapolate that forward, and as each game is played, the potential outcomes for the competition narrow even further. Eventually, we’re left with two teams – which greatly simplifies the modeling. Finally, at the end, we know who won.
Apply this model to a schedule. We forecast a range of potential outcomes, with a more probably outcome and a less probable outcome. As the project plays out, the range of potential outcomes diminishes. The most probably path becomes more and more apparent.
Another metaphor I commonly use is a toothpaste tube. If you assess the amount of risk, or uncertainty, associated with the schedule. As events increasingly transform from the potential future to the recent past, the amount of uncertainty goes down. It’s the same as squeezing toothpaste from a tube. At the end of the day, there’s no uncertainty as the project is complete. All of the risk has been squeezed out of the tube.
Figured this out a while back for the forums, but then promptly forgot and shot myself in the foot.
Consider the following scenario:
It turns out the schedule is sync’d to the first task list it finds on the site alphabetically. If you have a task list named something like, My Workflow Tasks, the schedule gets sync’d to that list.
The solution is to always make sure the task list that you want to sync with the project comes in first in the alphabet. Optionally, the other method is to modify the Project Summary Webpart so it points to the correct list – although I’d probably check out option #1 first.
‘Ware the resource hoarders in your organization. You’ll know them because they’re the ones who refuse to provide detailed task estimates for their projects. When pressed for details on their resource plans, they’re like as not to produce an Excel chart that shows the resource allocated evenly for 32.75 hours across the length of the project.
If you see a spike in a given week, you might ask something like “What are they doing in March?”…only to be told that they’ll be working on “Release stuff.”
“Great,” you say, “Where’s the schedule that shows when the release will occur so we know if that spike in resource demand will move out if the release moves?”
And the hoarder responds with, “Well, we’re not getting that detailed with our planning.”
The issue here is that the hoarder has been given resources by the organization. “You will have X resources for 6 months,” the organization declares. The response, logically, is to ensure that, on paper at least, we will use those resources.
The problem is several fold here:
The thing is, in organizations that tolerate and/or encourage resource hoarding, you’ll have all sorts of latent resource capacity sitting under the radar. That capacity represents a tremendous opportunity cost in the work that is not getting done – because the resource is dedicated to a project that may not be really using them. Start prying into resource visibility, and you’ll be shocked at how much excess capacity scurries out from under a rock.
Project Epistemology 