The Right Way to Configure Administrative Backup

Ran into this again this week, and figured it was worth a blog post.  As any administrator will tell you, Project Server provides the option to create scheduled backups of projects, settings, resources, and custom fields.  This is a great feature, but the user interface often leads to some confusion.  The goal of this post is to alleviate some of that confusion.

Before we do that though, let’s first address where to actually find the Administrative Backup settings:

  • Project Online (Office 365) – It’s not available for end user access.  That makes it simple.
  • Project 2013 (On-Premises) – Now found in the Manage options for the Project Web App in Central Admin’s Project Server Service Application (go ahead and send this link to your SharePoint administrator because they’ve probably locked you out – and if they haven’t, they probably should have.)
  • Project 2007-2010 – Project Server Server Settings.

Here’s what it looks like in the pre-release version of Project 2013:


Here’s what I typically see this set for in many clients:


Note that unless you have extenuating circumstances, the items highlighted in red probably need to be revisited:

  1. Project Retention Policy usually should be set to something along the order of 10 or less versions.  Anything higher than that would probably need to be vetted by your SQL folks and combined with the development of some database management protocols.  Otherwise, your Archive database is likely to grow too large to be safely managed.  I’d also point out that it’s a rare organization that truly requires more than 5 versions of the project.
  2. Everything else should be set to Never.  Why?  Because Project Server doesn’t retain multiple versions of these settings.  Every time you save a new version of the settings, it overwrites the old ones.  This means that if you make a change to the environment, and don’t catch an error, the setting will be overwritten that night when the administrative backup is run again.

Hence, I always encourage my clients to configure these settings as follows:


While I am on the topic, a couple other common misconceptions around this screen are probably worth mentioning:

  • Project versions are archived daily.  This means that if the project is edited multiple times in a single day, only the latest version is archived at the end of the day.
  • Project versions only get archived if something has changed.  If the project hasn’t been edited on a given day, the new version won’t be archived.  Note that you may need to revisit these settings if you have some sort of customization running that automatically updates the project file on a daily or weekly basis.  These updates would trigger the archive process, and potentially could result in overwriting the last good version of the project.
  • When you trigger an Administrative Backup, the backup may not simply overwrite the existing elements.  For example, if I backup the resource pool, then add a couple of resources accidentally, the administrative restore won’t really do all that much.  The only thing the administrative restore will do is restore any resources I may have accidentally deleted.  The same applies for views.  (Fields on the other hand appear to be restored to a point in time, so any new fields get removed.)

As for how this should all be used?  My general recommendation is to set the project retention policy to 5-10 projects, and then manually trigger the backups for everything else prior to a major change event.  I also tend to use this in conjunction with the Playbooks tool, which helpfully documents all of the configurations and custom fields into an XML file that may then be opened into Excel.  I’d definitely recommend including both options in your typical release checklist.

The Right Way to Configure Administrative Backup

Project Management Systems vs. Accounting Systems

As many of you are aware, UMT has long been in the project financial governance space, and for the last several years has been proud to offer a tool that brings financial governance into the project portfolio management fold.

Often, when working with clients in designing their project financial governance processes, the question arises of how such a system would interact with an existing Line of Business (LOB) application such as SAP or PeopleSoft.  The LOB application is the official enterprise system of record and, as such, must contain the latest and greatest financial figures.

So what purpose can be served by effectively taking those figures and copying them to a secondary data repository?  As any enterprise architect would tell you, unless doing so enables a specific strategic capability, data should never be replicated into a secondary repository.

First off, let’s look at simple reporting.  One common scenario is for project managers to desire to capture accounting data in the same interface as project data.  For this purpose, creating a second data repository actually defeats the point, as we want for PMs to have access to the latest and greatest financial data.  In this scenario, we may be better served leveraging the rich SharePoint Business Intelligence features to surface accounting data through the use of Excel Services, SSRS, or PerformancePoint.

But what happens when we move beyond simple reporting?  Let’s take a look at a couple of scenarios that are enabled by the Project Essentials tool:

Preliminary Estimate Development – Often, as projects are developed, an initial business case is developed.  This financial business case may be captured in a project request form, a request database, an estimating tool, and occasionally within the PMIS.  Rarely is this sort of data captured in an information system that allows roll up and analysis.  Even rarer would be when this sort of data is captured within a LOB accounting application.

The general workflow we’ve seen is for the initial estimate to be prepared outside of the accounting application and then imported into the application upon project approval and funding (which then allows the organization to utilize portfolio analysis and optimization techniques).

Status Reporting – Nothing indicates the difference between project management and accounting more than status reporting.  This really hits to the heart of what Eric Uyttewaal once claimed in his book on project modeling, “The difference between accounting and project management is that accountants are focused on the past while project managers are focused on the future.”

Common scenarios in status reporting include the fact that the accounting application typically doesn’t display actual costs until the invoices for the work have been received.  This might happen anywhere from 30 to 90 days after the date of the actual work.  From a status reporting perspective, the project manager is better served depicting an unofficial “incurred” cost in the status report for work performed that has not yet been invoiced.

While this may violate basic accounting best practices, the reality is that this practice enables more effective status reporting and emphasizes the difference between the world of accounting and the world of project management.

Benefits Management – Another key aspect of project portfolio management lies in defining project financial benefits.  The general model involves defining timephased financial benefits before approving the project.  Upon project closeout, or at a predetermined period thereafter, those same benefits will be reviewed to assess whether or not the project was successful.

Since benefits are very often hypothetical values, they often have no place within the data structure of an accounting system.  Hence, benefits tracking is often relegated to the PMIS.

Integration with Project Management Workflow – It’s a lot easier to integrate with your project management workflow when you can replicate at least some of your accounting data into a PMIS. For example, imagine that you would want to take a snapshot of all of your actuals as well as project cost forecasts at each stage gate approval. This would allow you as an organization to assess how much you’ve spent within each stage gate, and what the forecast looks like upon the conclusion of each phase.

While a LOB accounting system will allow you to roll back time to identify the value of specific elements at any given period, it is often difficult to map those periods to the phase gates approvals in a true project management solution.  How could you determine how much you’d spent at the end of the Build stage from your LOB application without first looking up the date that you exited Build in your PMIS, and then cross referencing that with your LOB estimates?

Performance Management – And last but not least, what about financial requirements for performance management?  Often times, the project performance must be measured against various baselines.  For example, we may have a data structure within our accounting system to capture approved annual planning budget.  We may also have a structure to capture our current project forecast.  If a project has been approved out of cycle however, the annual planning figures will be zero.  We need to capture a snapshot of the forecasted cost at the time the project is approved to ensure that we are tracking against the appropriate financial baseline.

Looking for something a bit more substantial on the topic?  Check out UMT Chairman Mike Gruia’s white paper on the need for project financial governance.

Project Management Systems vs. Accounting Systems

My Very First Post on the New Project Release

Much has already been said on all of the wonderful goodness that is part of the new Project that is now in technical preview.  From a blogging perspective, new releases are wonderful things as they allow us bloggers to basically rehash all of our existing posts with new screenshots and feel productive without any requirement for creativity.  Don’t worry about that, I already have a plan in place to rehash all of my standard reports into OData queries.

The main place where I would expect long time Project Server admins to get confused with the new release is probably the security model.  Some folks found it a bit confusing before, perhaps, and now that we actually have two distinct security models to choose from, that just adds to the fun.

Luckily, as part of the Project Server security refresh, we’ve gotten a nice tool that’s kind of been around for a while, but sort of vanished in 2010, and is now seemingly back for good in 2013: the View Effective Rights tool.


Now this was a tool that used to be in the Project Resource Kit for the 2007 version of Project Server.  I vaguely and probably incorrectly recall it being around for 2003…..and if the stars are in alignment, and you get things to work just right, you can still use the 2007 version in Project Server 2010.  That being said, it was never released for the 2010 version.

The way it works is basically to query the database for a specific user and his permissions to a specific project.  Based on the result, it tells you what combination of group and category permissions govern the user’s relationship with this project.

This tool was invaluable in troubleshooting security models, and as mentioned above, I still use it when I get into tricky 2010 situations – although I haven’t completely validated the performance for such.

To use, select the user, and click on Check Effective Rights.  From there, it’s pretty simple:


My Very First Post on the New Project Release

Bringing Workflow Tasks to the PDP

Well, it’s been quite a summer this year.  Had a great vacation, started an exciting project, and everything was going gangbusters until my left knee unilaterally declared a work stoppage and decided to go on strike until further notice.  (No worries, the doctor tells me it’s fixable).  Being on crutches and somewhat immobile has inspired me to get back into the blogging again.

Since it’s been a workflow kind of month, I figured I’d kick off this blogging with a nice easy post where I took the same old trick I’ve been using for the last year, and apply it to the Workflow Task List.


In this case, I realized that it was getting annoying to validate a solution in development when I would push a project into an approval stage, and then have to close the project, navigate to the workflow list, approve the item, and then navigate back to the project via the Project Center to resume where I was.

The other option, of course, was to have two browser tabs open, one to the Workflow Task List and one to the project in question – but I found that kind of annoying to keep having to do that.

So, on the theory that what is annoying to me is probably annoying to the end user, I decided to see if I could just extend the Workflow Task List to a PDP, meaning I wouldn’t have to leave the project record itself to get to the list of relevant tasks.

Turns out, it was quite easy.  Here’s the run down:

1) Take a look at the Project Workflow Tasks List.  You’ll see that each task has the Project UID embedded in it.


2) Knowing that, all we have to do is add this list to a PDP and filter on the project, and we have a customized list of workflow tasks for the specific project.  Create the PDP and add both the Project Server Workflow Tasks list and the Query String filter.  Configure the Query String filter to filter on the Project UID and pass the value to the Workflow Task List.


3) The next trick would be to identify which view you want the PDP to display.  My preference is just to show all tasks for the project, as this may be relevant to anyone looking for information about the project.


4) Add the PDP to your project and you’re good to go…


You no longer have to navigate out of the project context to review or approve workflow tasks.

Bringing Workflow Tasks to the PDP