3 problems tracking operations in Project – Part 2

In part 1, we outlined the problems that many customers encounter managing operational work in Project. We need to capture this information for higher fidelity resource capacity. However, previous methods required more work on the part of Resource Managers than desired.

In this article, you’ll see how to set up an operational project plan template that enables you to treat each week as a distinct unit. You’ll also see how to set up the project in Project Professional and how to configure an Operational Project Enterprise Project Type.

Part 3 will also show how to set up the project using PWA only. The requirement is to enable the Resource Manager to manage the project easily via Project Web App. You’ll also be taken through how to use this setup in a day to day fashion and will see timesheet and approval configuration. Lastly, you’ll see how this information appears via Power BI reporting.

If you have comments or questions, please leave them below in the comments field.


The Benefit of One Simple Change in Project Online

What we typically do today.

This post is about what can be gained from making one simple change in your Resource Custom Field configuration. Many companies have an FTE Yes/No type resource custom field to distinquish between employees and contractors. This has been the approach for many years, as I see this many times in Project 2007/2010/2013 implementations.

A better approach.

I suggest using a Resource Company custom field instead. You would create a lookup table, Resource Companies, where you include the name of your company and the company names of all of your contractors. You then attach this lookup table to the new Resource Company custom field. Lastly, update the value for all resources, where FTEs are set to your company name and contractors are set to their individual company name.

So why do this?

This simple change creates richer data for reporting. For example, your vendor management team is in the process of renegotiating a contract with a specific vendor. That vendor is supplying a number of contractors across many projects. If you use this approach, the ability to extract how much work this vendor is doing and which projects are they working on is as easy as setting a simple filter.

For employees, you may even consider making the lookup value hierarchical, so that you can enable your company name.your division name reporting.

Are you using this approach today? If so, please share your experiences in the comments.

The Truth Shall Make You Miserable

Lack of Faith - Vader- Project Dashboards

When companies begin making their data more accessible via Self-Serve Power BI, they soon reach a critical break point in those efforts. The Project dashboards tell them something that isn’t pleasant or doesn’t match the narrative been publicized.

The Reality in Your Project Dashboards

Performance indicators go red. The data shows the stellar progress that was planned isn’t happening. Operational demands for time are much higher in reality than assumed in planning. In short, it shows the harsh reality, as captured in the data.

This is a moment of truth for organizations. Are we going to embrace the transparency or will we attempt to control the narrative?

Data Quality Challenges

The first question is normally, is this data accurate? This is quite reasonable to ask, especially at the beginning the data stream may not be as clean as it should be.

The approach to this answer can decide your success going forward. For some, questioning the data is a prelude to dismissing the use of the data. For others, it’s a starting point for improvement.

The data deniers will provide many reasons why “we can’t use the data.” They will complain that the data is inaccurate or incomplete. Therefore, they can’t trust their data to integrate its use into their daily work or to use it to make decisions.

These data deniers may have other hidden reasons for their position, such as political or power base protection reasons. Moving to data-centric culture is a big change for many organizations, as you have to be open about your failures. No company is always above average in every endeavor.

Data deniers also fear how business intelligence might impact their careers. If the corporate culture is such where punishment is meted out when the numbers and updates aren’t desirable, likely data transparency won’t be welcome.

Change the Focus of How Data is Used to Succeed

The key to overcoming the data fear is to change the intent for its use, moving the focus from punishment to improvement.

For the successful companies using data, they embrace two simple facts. One, the data is never perfect and that it doesn’t have to be to effect a positive change. Two, they’ve defined the level of granularity needed in the data to be used successfully.

How Imprecise Data is Changing the World

We see this approach in our personal lives. For example, the Fitbit device is not 100% accurate or precise. Yet, millions are changing their behavior of being more active because of the feedback that it provides. based on relatively decent data. You may also be carrying a smart phone, which also tracks your steps. Between the two, you would have a generally good idea of how many steps you took today.

From a granularity approach, we aren’t generally worried about whether I took 4103 steps or 4107 steps today. We took 4100 steps. Hundreds is our minimum granularity. It could easily be at the thousands level, as long as that granularity meets your information needs.

Cost Benefit of a Minimum Level of Granularity

One area we see this type of data accuracy dispute in the corporate world is with cost data. It’s been engrained in our psyche that we have to balance to the penny. Our default data granularity is set to the cent.

While that may improve accuracy and precision, it doesn’t make a material difference in the impact. For example, if your average project budget is $2M, then worrying about a 5 cent variance is a percentage variance of 0.0000025%. I’ve seen organizations who get wrapped up in balancing to the penny and waste an inordinate amount of time each week getting there.

Instead, let’s define a minimum granularity in the data such that a 1% variance is visible. For a $2M average, you would round up at the $10,000 point. Doing so then reduces work attempting to make the data perfect. Any variances of that size are significant enough to warrant attention and are more likely to stand out.

Implementing Self-Server BI using products like Microsoft Power BI and Marquee™ Project Dashboards will enable your organization to gain great improvements as long as they are willing to accept the assumptions above. The truth may make you miserable in the short term as you address underlying data and process challenges. In the long run, you and your company will be better served.

Please share your experiences in the comments below.

How to show Implementation Milestone Dates in Project Center

This technique illustrates how to use formulas to extract dates from tagged milestone tasks within your project plans and show the dates in the Project Center.

This technique has been tested with Project Online and Project Server 2013 On Premises. However, I don’t see a reason why it wouldn’t work in Project Server 2010. The primary difference is that 2010 will require a round-trip of the data in Project Professional to calculate the formulas.


I’ve had several clients ask “Can we show the next Implementation date in Project Center?”. The challenge is that the Implementation milestones are task level data. The Project Center only shows project level data, therefore you must extract and transform the data to show it appropriately.

Since you may have multiple Implementation milestones, this technique will show the next upcoming Implementation date. If there is no upcoming date, it will show the most recent past Implementation date. This way, the field should always show data.

Using Metadata Instead of Task Names

My first job in industry was converting old RPGII programs on the IBM System 38. I quickly learned the evils of using content as data as that was a very common technique in those days. This technique led to users accidentally breaking processes by inadvertently adding a space or changing a term. If you’ve told your users not to update a task name or the name of some other element, you too are using content as data.

Search engines later taught us to use metadata tags to separate functional data from content. Thus, this technique requires the creation of a task metadata field for tagging tasks with a specific reporting purposes. The illustrated design only allows one tag per task.

The benefit of this technique is that it is agnostic to the names of tasks and milestones, as long as they are tagged appropriately. PMs can change the task names and plan structure to meet their needs as long as they tag the tasks and milestones appropriately.

Metadata Lookup Table

The Reporting Purposes lookup table supports two levels of values. This enables multiple classes of tags, such as milestones and phases. This exercise focuses on the Milestone.Implementation value.


Metadata Custom Field

Create the Reporting Purpose task custom field and attach it to the Reporting Purposes lookup table. Specify that Only allow codes with no subordinate values is selected. This prevents the user from selecting Milestones without selecting a more specific purpose.


Extracting the Data

The technique takes advantage of the rollup capability within Project, that enables a task level value to be rolled up to Task 0 (Project Summary Task). Task 0 values can be retrieved and used in Project formulas, thus translating the task data to project data.

Task Custom Date Field Setup

Two task level formula fields are needed to determine which Implementation date is available as stated in the requirement above. Show me the next Implementation date or if not available, show me the most recent past Implementation date. These requirements constitute two separate conditions leading to the need for two separate task formula custom fields.

Next Implementation Task Date

The first task custom date field is Next Implementation Date. This field determines if there are one or more Implementation dates in the future. The future is defined as any date equal to or greater than today on any task marked with a Reporting Purpose value of Milestone.Implementation.

The rollup is used to retrieve the soonest Implementation date if there are multiples. When defining this field, specify the rollup behavior as Minimum so that the Implementation date closest to today will be shown. 



IIf([Reporting Purpose] = "Implementation" And [Finish] >= Now(), [Finish],

IIf([Reporting Purpose] = "Milestone.Implementation" And [Finish] >= Now(),

[Finish], ProjDateValue("NA")))

This formula may appear a bit odd when examined closely. It appears that there are duplicate conditions specified. This is done intentionally as a workaround to a difference between PWA and Project Professional in formula evaluation during the schedule edit.

The Reporting Purpose custom field is hierarchical so the tagged value is Milestone.Implementation. In PWA, the formula only sees the “Implementation” part of the value when you edit the schedule. The first check ensures that PWA evaluates the formula correctly. In Project Professional, the formula sees the whole value. The second check of the full value is added to ensure Project Professional evaluates the formula correctly. Both checks prevent data from being inadvertently deleted when editing in across both platforms. If neither value is found, the field is set to a special date value of NA, using ProjDateValue(“NA”).

Previous Implementation Task Date

This field helps determine if the most recent past Implementation date. This field determines if there are one or more Implementation dates in the past. The past is defined as any date less than or equal to today on any task marked with a Reporting Purpose value of Milestone.Implementation. The same double check of the Reporting Purpose is required to keep the editing behavior consistent.



IIf([Reporting Purpose] = "Implementation" And [Finish] <= Now(), [Finish],

IIf([Reporting Purpose] = "Milestone.Implementation" And [Finish] <= Now(),

[Finish], ProjDateValue("NA")))

Rollup to the Project Level

A Project level custom date field is created to perform the logic of determining the correct Implementation date to display in the Project Center. The formula checks the Next Implementation Task Date for a value of NA. If found, it assumes there is no future date and uses the most recent past date. If NA is not found, it uses the soonest future date.



IIf([Next Implementation Task Date] = ProjDateValue("NA"),

[Previous Implementation Task Date], [Next Implementation Task Date])

Add to the Task Summary View in PWA

I now add the Reporting Purpose, Previous Implementation Task Date and Next Implementation Task Date fields to the Project Task Summary view. This enables the PM to mark the appropriate tasks in PWA if desired. It also helps you see the effects of the formulas.

When I edit the project in PWA, I will see something like the following. Here, I’ve created a project with four Implementation milestones, two in the past and two in the future.


Today is April 16, 2014, so the next future Implementation date is 4/25, which is what should be shown in the Project Center, as seen at 1 below.


I hope you have found this technique to be useful. Please post any questions in the comments.

Don’t Get Burned By Your Security Templates



If you’ve ever tried to use the built-in security templates in Project Web App, you may have accidentally messed up your security model without realizing it. This problem applies to Project Server 2003-2013 versions.

Security templates are designed as a way to quickly apply or reapply permissions for predefined roles, when creating new groups and categories. However, the out of box implementation can lead to issues if you don’t realize the impact of applying them.


Groups and Categories have what is known as a many to many relationship.  A group can be associated to multiple categories and a category can be associated to multiple groups. The default security model relationships are shown below where blue boxes represent the Groups and orange boxes represent the Categories.


We’ll use Resource Manager as an example of the security template issue. Resource Manager has four relationships out of box by design:

  • My Organization so that they can see all resources and build team on any project
  • My Projects so that they can view any project of which they are part of the project team or own
  • My Resources so they can only see their resources below them in the RBS so that the Resource Manager can add them to a Resource Plan
  • My Direct Report which is reserved for you to customize functionality for the resources directly below the Resource Manager in the RBS The heavy lifting in the security model is at the intersection points between Group and Category. The intersection is where you set the what allowed Project and Resource actions (Group) can be taken on the data returned by the Category. If you’ve seen a “troubled” security model, it’s usually because this nuance was lost on whoever was maintaining the model.



Felix is a Project Server administrator who accidentally changed some category permissions in production on the Resource Manager – My Projects intersection. “No problem”, thinks Felix, “I’ll just reapply the Resource Manager security template and all will be good.”

    Felix then does the following actions.

He goes to PWA Settings under the Gear.


He clicks on Manage Groups under the Security section.


He clicks on the Resource Managers group to edit.


He scrolls down to Categories to access the Category permissions for the group for My Projects.

He selects My Projects in the Category list to show the permissions. At the bottom of the category permissions section, he selects the Resource Manager template and clicks Apply.


All good right? Not exactly.

The Issue

Remember, Resource Manager Group has four category relationships.


However, if you go into Manage Security Templates, there’s only one entry for Resource Manager.


So, which relationship does this security template represent? Was it the right one for Felix to apply? You don’t know without further research.

Suggested Fix For This Situation

If you choose to use Security Templates, I highly recommend doing the following prep work. This recommendation is based on the real world experience of managing two Fortune 250 company implementations and having cleaned up numerous security models for other companies. An hour or two of prep now will prevent tears later on.

Create a new template for group permissions and one for each intersection for the category permissions using this procedure. http://technet.microsoft.com/en-us/library/cc197679.aspx If you’ve heavily customized your security model, you will need to create a diagram similar to the one I have above first.

The resulting template list for Resource Manager will be as follows.

  • Resource Manager – Group Permissions Only
  • Resource Manager – My Organization
  • Resource Manager – My Projects
  • Resource Manager – My Resources
  • Resource Manager – My Direct Reports
    Now, when Felix applies a security template, he knows exactly which one he is applying to the security relationship.


You can find the default Project Server 2013 group and category permissions at these links for constructing your templates.