Project Online Service Description

Contents
Project Online
Get started with Project Online
Step 1: Sign up for Project Online
Step 2: Add people to Project Online
Step 3: Set up shop in Project Online
Add Project Online to your Office 365 account
Add Project Online to a site collection
Migrate to Project Online from Project Server
Connect to Project Online with the Project Online Desktop Client
Set up another Project Online site
Delete a Project Web App site
Turn on notifications in Project Web App
Periodic tasks for Project Online administrators
Create unique Project IDs for my projects in Project Online
Supported languages for Project Online
Project Online client requirements
Configure Office 365 Project Portfolio Dashboard
Timesheets
Set up timesheets
Set up categories for timesheet rows
Configure time and task progress
Customize timesheets and task progress for your organization
Set up time and task progress approval
Set up policies for capturing time and task progress
Set up your fiscal year
Set up vacation, sick leave, and other non-project work categories
Set up how time and task progress are captured
Reporting
Grant reporting access in Project Online
What reporting tools can I use with project data?
Configure rollup of timephased reporting data in Project Online
Resources
Configure the Resource Center
Activate resource engagements in Project Online
FAQ: Resource engagements are replacing the old resource plans
Workflows
Using workflow for demand management in Project Online
Troubleshoot Project Online workflows
Best practices for creating phases and stages
Security
Change permission management in Project Online
Plan SharePoint groups in Project Online
Using Project Online with external users
Understanding identity management in Project Online
What should I do if my Project Online administrator gets locked out?
Performance
Tune Project Online performance
Project Online: software boundaries and limits
Best practices to improve Resource Engagements performance
Portfolio analysis
Portfolio analysis in the Microsoft Project Web Application
Defining portfolio analysis business drivers
Prioritizing portfolio analysis business drivers
Creating a new portfolio analysis
Resource analysis in the Microsoft Project Web Application
Establishing the resource pool
Using task level assignments to define resource demand
Using resource engagements to define resource demand
Defining project portfolio dependencies
Prioritizing the portfolio with custom fields
Modeling cost scenarios in portfolio analysis
Modeling resource scenarios in portfolio analysis
Comparing multiple portfolio analysis scenarios
Committing the selected portfolio scenario
Configuring workflow to support portfolio analysis
Project Management Office
Supporting your Project Online adoption with a Project Management Office (PMO)
Project Online implementation cookbook
Enterprise system best practices
The project management system maturity model
EPM: Centralized or decentralized?
Dashboard directions
Creating an EPM Deployment Plan
The challenges of selecting enterprise software
The Seven Deadly Sins of Project Schedules
7 Ways to Sustain Adoption of your PPM Solution, Post-Implementation
Cancelling a project without cancelling your career
We're selling holes, not drills!
The Bat phone
Balancing the matrix
Charging Ahead on Charge Codes
Being a solutions buyer
Track or Treat
Beat the Half-life (t 1/2): Governing Your PPM Solution, Post-Implementation
They say they want a resolution
Breaking Bad...News that is
The executive connection
Is there a pilot on board?
Would you like some EPM with that?
Are we there yet?
GPS assistance in roadmapping an EPM deployment
Top-down or bottom-up
Aligning projects with strategic drivers
A phased approach to deploying enterprise project management
Resource management
Maintain user data
Delete user data from Project Online
Export user data from Project Online
Find customized user items in Project Online and Project Server user export data
Project Online and Project Server export data definitions
License management
Important information for Project Online customers about plan changes
Renew your Project Online plans in a larger organization
Roadmap
Turn Roadmap on or off
Remove Project Roadmap
Delete user data from Project Roadmap
Learn how to plan for, implement, and maintain Project Online in your environment.
Get Started with Project Online
Plan to Implement Project Online
Best Practices to Improve Performance
Project Online Software Limits and Boundaries
Set Up Timesheets
Configure Rollup of Timephased Reporting Data in Project Online
Featured articles
Best practices to improve Resource Engagements performance
Understanding identity management in Project Online
Get started with Project Online
7/18/2019 • 2 minutes to read • Edit Online
Overview
Project Online is web-based, and is great for:

Managing multiple projects.
Tracking work on timesheets.
Balancing broad resource needs.
(If you're looking for a hosted version of Project Server, this is
it!)
To be clear, Project Online is NOT a web-based version of Project Professional. Project Online is an entirely
separate service that offers full portfolio and project management tools on the web. It includes Project Web App,
and can, depending on your subscription, also include Project Online Desktop Client, which is a subscription
version of Project Professional.
Got the wrong thing?
If you need to cancel and subscribe to something else, choose Billing > Subscriptions in the Microsoft 365
admin center, choose the subscription you want to cancel, and then click Cancel subscription in the pane on the
right. Then, you can find the right product to subscribe to and add that to your existing Office 365 account.
Need help?
Take a look through the Project help on Office.com. If you're still stuck, try posting your questions and issues on
the Project Online discussion forum.
Step 1: Sign up for Project Online
First, subscribe to Project Online
Start from scratch Add Project Online to Office 365

New to Office 365? Start here! If you already have an Office 365
account, you may be able to add
Project Online to that account by
choosing Activate offers from the left
menu on the Microsoft 365 admin
center under Billing. Learn more
Next, make sure you can get in!
It may seem a little backwards, but after you sign up, the first
thing you should do is make sure your account is assigned
a Project Online license. Some accounts are and some
aren't.
To check if you're assigned a license:
Choose Users > Active Users from the left menu on the
Microsoft 365 admin center.
Choose your account.
Confirm that the Project Online is listed under Product
licenses.
Even if, as the administrator, you don't actually plan to
use Project Online, the only way you'll be able to see that
Project Online is, in fact, included in your Office 365 account is
by giving yourself a license to use it. You can go back in later
and remove your license to free it up for another user, if
needed.
Be patient...
It takes a while for Project Online to finish getting set up. Go
have a cup of coffee or catch up on email. Setup will
generally be done within 30 minutes to an hour, but it can
sometimes take longer (or shorter!). Don't panic if yours is
taking longer!
When you come back to check on setup, refresh the page. If
you see Project listed in the app launcher , you're ready to
go!
> [!TIP]> Need more than one Project Online site? You can set
up as many as you need.
Top of Page
Step 2: Add people to Project Online
1. First, add people to Office 365
Start by adding users in the Microsoft 365 admin center. If

you are adding Project Online to an existing Office 365
subscription, you may have already added all the users you
need and can skip this step.
IMPORTANT! Planning to use your own domain (like
contoso.com)? Add a domain to Office 365 before adding
your Project Online users. Changing domains after you've
added users is not supported!
When you're ready to add someone to Project Online,

start by adding users:
1. Choose Users > Active Users from the left menu on the
Microsoft 365 Admin Center.
2. At the top of the list of users, choose + Add a user.
3. Fill out the account information.
4. Under Product licenses, make sure a Project Online license
is assigned, and then choose Add.
5. Choose whether to send the new user's password in email,
and then add another user.
For more information, see Add users individually or in bulk to
Office 365 - Admin Help
2. Next, group people by what they'll be doing with Project Online
Now that you've added people to

Project Online, the next step is to divide
them into groups by how they'll be
using it.
Not everyone needs access to
everything available in Project Online.
Usually, your organization can be
sorted into the following roles:
Role Description Permission name
Admins People who need full control over your Administrators for Project Web App
Project Online subscription. Admins [Full Control]
manage your user list, who gets what
level of access, and also manage all the
main project settings.
Project managers People who will create and manage Project Managers for Project Web
project files. Project managers will App [Design, Manage Subsites]
create projects and tasks, assign
resources, manage timesheets, and
otherwise be in charge of projects and
project files.
Team members: People who perform project tasks. Team Team Members for Project Web
members receive assignments and fill App [Read]
out progress and timesheets.
For the full list of permissions available with Project Online, see Plan SharePoint groups in Project Online.
To more easily manage people in Project Online, create

a security group for each of the roles you need:
1. Choose Groups > Groups from the left menu on the
Microsoft 365 Admin Center.
2. At the top of the list of groups, choose + Add a group.
3. For type, choose Security group. There are other group
types in Office 365, but this is the one that can most easily
manage your Project Online users. For more information on
different types of groups, see Compare groups.
4. Type a name for your group. It might be easiest to pick a
name that refers to the permission level. For an organization
named Contoso, you could name your group "Contoso
admins" or "Contoso team members".
5. Choose Add.
Then, add users to groups.

To add users to groups:
1. Choose Users > Active users.
2. Select the check box for each user you want to add to your
first security group, and choose + Add to group in the Bulk
actions pane.
3. Choose a group from the Group memberships list, and
then choose Save > Close.
3. Then, add people as resources

Not every user needs to be a
resource. Sometimes, people like
higher-level executives only need access
to Project Online to keep an eye on
how projects are going across the
organization.
If you know a person will work on projects and tasks,

make that user a resource:
1. On the Office 365 app launcher , choose Project.

2. Choose Resources on the left menu. You can either:
Add many resources at a time: If you haven't added any resources yet, you can synchronize with an
existing group.
a. On the Resource Center page, choose click here in the first sentence: "To add resources, click here to
synchronize with an existing group."
b. On the Active Directory Enterprise Resource Pool Synchronization page, type the name of a
security group in the Active Directory Group box.
c. Choose Save.
d. Repeat for any other security groups you want to create resources for. When you've added all the
security groups you want, choose Save and Synchronize Now.
Add resources one at a time:
a. On the Resource Center page, choose Resources > New.
b. There are a lot of things you can fill out here, but only two things are really important right now:
- Under Identification Information, choose Associate resource with a user account.
- Under User Authentication, in the User logon account box, type the name of the user you want
working on projects and tasks.
c. Choose Save when you're done.
4. Finally, share Project Online with the people you added
Now that you've added people to Project Online, the next step
is to share the site with them so they can actually get in!
When you share the Project Online site with a user, you
also decide what they can do in Project Online:
In Project Online, choose Share, just below your name in the
top-right portion of the page. You can share with individuals
or security groups. Share by security group if you've created
security groups for each permission level you want to use.
Type either the name of the security group or the name of
the individual user in the top box, and then choose Show
Options. Under Select a group or permission level, choose the
permission level that matches what the security group or
person's role is in your organization. For example, for the
Contoso admins security group, choose Administrators for
Project Web App [Full Control]. Choose Share. Repeat this
process for all additional groups or individuals you want to
use Project Online.
NEXT STEP...
Next, learn about Step 3: Set up shop in Project Online.
Top of Page
Step 3: Set up shop in Project Online
At this point, if you really want to, you can dive right in and start a new project! Everything is there for
you to just jump in and run. But...there are a few things that you can set up now, to make Project Online more
useful for your organization.
Set your time zone
Got users in different time zones? Project Online stores

times and dates in UTC (Coordinated Universal Time) format,
and then converts times to the local time zone of your Project
Web App site when you view a page. If you have users in time
zones outside the time zone for your Project Web App site,
you should have them change their personal time zone
settings to match their location to ensure that they're seeing
times and dates properly in Project Online.
Set up timesheets
Want your team members

to turn in timesheets for
the work they're doing?
Before your team members
can start filling out
timesheets, you need to set
up a few things.
Basic Advanced
Set up timesheets Set up how time and task
Set up your fiscal year progress are captured
Set up categories for Customize timesheets and
timesheet rows task progress for your
Set up vacation and sick organization
leave time Set up time and task
progress approval
Set up a streamlined way to manage users and resources
Want to use groups to manage who's doing what in

Project Online? You can set up Project Online to use the
same Active Directory groups you might already have set up
in SharePoint Online. This can make it a little easier to keep
track of who's doing what across the different tools in your
organization.
If you want to go this route:
Make sure you're in SharePoint Permission Mode . Plan
SharePoint groups in Project Online . Configure the Resource
Center to use your Active Directory groups .
And there's more...
There are lots of ways to map Project Online to the way

you run your business. Here are a handful of other things
you can start looking through, when you're ready to dive
deeper. Some of these resources are written with Project
Server in mind, but the steps are relatively similar.
This is complicated stuff. If you're not ready for complicated, ignore this section and move on to Create a
project in Project Web App. You don't need to know this advanced level of setup to be able to use Project Online.
(It's okay if you let out a sigh of relief now!)
If you're ready for complicated, here are some places to start:
Enterprise custom fields and lookup tables in Project Web App
Using workflow for demand management in Project Online
Portfolio analysis overview
If you get overwhelmed or confused, the discussion forums on TechNet are a great place to get your
questions answered.
Ready to move past setup?
Next up, Create a project in Project Web App!

Stuck? Try the Project discussion forums on TechNet!
Add Project Online to your Office 365 account
If you already subscribe to another Microsoft service, such as Exchange Online or SharePoint Online, then you
already have an Office 365 account. If you are using Office 365 Enterprise, Government, or Academic, you may be
able to simply add Project Online to that account.
How do I know if I have the right

kind of Office 365 account?
To check, go to the Purchase Services
page in the Microsoft admin center.
If you see Project Online listed, this

means you can add it! Keep reading to
learn more.
If you don't see Project Online listed,
this could be because your account isn't
Office 365 Enterprise, Government, or
Academic. These are the only
subscription levels that currently
support Project Online.
To add Project Online to your existing Office 365 account:

1. Log into your Office 365 account.
2. On the Microsoft 365 admin center, choose Purchase Services on the left menu.
3. Choose Add next to the Project Online plan that you prefer, and follow the on-screen instructions.
NOTE
If you are using a trial version and want to pay for a subscription, choose Buy Now.
Add Project Online to a site collection
Adding Project Online to an existing site collection helps you use the permissions and users that you have already
set up. It also lets you bring SharePoint tasks into Project Online, and share your enterprise projects on your team
or project site.
TIP
To learn more about using SharePoint and Project Online together, take a look at Overview: View a SharePoint task list in
Project Web App.
To enable Project Online on an existing site collection:

1. Log on to the Microsoft Office 365 portal site.
Tip If you're not sure of your User ID, refer to the 'Get Started with Microsoft Office 365' email message that
includes your User ID and other account information.
2. Click the app launcher , and then click Admin.

3. In the admin center, under Admin centers, select SharePoint.
4. On the SharePoint admin center, select Classic features.
5. On the Classic features page, in the Classic site collections page section, select Open.
6. Hover over the URL for the site collection where you want to enable Project Online, and then select the
check box that appears to the left of the URL.
IMPORTANT
You can only add Project Online to a site collection that uses the Team Site or Project Site template.
7. Click Project Web App on the ribbon, and then click Add.
8. On the dialog box that appears, click Enable to add Project Online to the site collection.
NOTE
After setting up the site, wait 15 minutes before using it, so that Project Online can finish installing.
Migrate to Project Online from Project Server
Learn more about upgrade from your Project Server 2016 or Project Server 2013 on-premises environment to
Project Online.
Is Project Online for me?

The following are considerations you need to make when planning to migrate to Project Online from your existing
Project Server environment:
THINGS THAT MIGHT PREVENT ME FROM MIGRATING TO PROJECT

WHY WOULD I PREFER TO MIGRATE TO PROJECT ONLINE ONLINE
I have mobile users. Business rules restrict me from operating my business in the
Cost savings on hardware and software installation. cloud.
After migration, low costs to maintain my environment (for I need control of updates to my environment.
example, automatic updates, guaranteed uptime, etc.).
Migrate to Project Online

You can do the following to manually migrate your project plan data:
1. Save your project plans from Project Server to MPP format.
2. Using Project Professional 2013, Project Professional 2016, Project Professional 2019 Preview, or the
Project Online Desktop Client, open each MPP file, and then save and publish it to Project Online.
You can also manually create your PWA configuration in Project Online (for example, recreate any needed custom
fields or enterprise calendars).
For more information about Project Online, see:
RESOURCE DESCRIPTION
Get started with Project Online How to setup and use Project Online.
Project Online Service Descriptions Information about the different Project Online plans that are
available to you.
Need help with your migration?

A number of factors can affect how much effort you will need to put into your migration (for example, number of
projects, complexity of projects, version of Project Server, etc.). If you need help with this, there are several options:
Get help from a Microsoft Partner - Upgrading to Project Online from Project Server can be a challenge,
and requires a lot of preparation and planning. It can be especially challenging if you were not the one to
setup and configure Project Server originally. Luckily, there are Microsoft Partners you can turn to who can
help you with this. You can search for a Microsoft Partner to help with your migration on the Microsoft
Partner Center. You can pull up a listing of all Microsoft Partner with expertise in Project by searching on the
term Gold Project and Portfolio Management .
Get help from Microsoft Services - You can also use Microsoft Services to consult with Microsoft
solutions experts who have the knowledge and experience to migrate you from your on-premises Project
Server environment.
Connect to Project Online with the Project Online
Desktop Client
The Project Online Desktop client is included with your Project Online Professional or Project Online Premium
license. While you can use it as a standalone client to create and manage your project plans offline, you can also
use it to connect to Project Online in your Office 365 environment to work with your Project Online users. For
example, you can create, save, and publish your projects to Project Online, and team members assigned to your
project tasks can use Project Online to give you updates on their task status.
NOTE
See Install Project if you need to learn how to install the Project Online Desktop Client. Follow the instructions to download
and install the subscription version (Project Online).
How to connect to Project Online

You can do the following to connect to your Project Online site in your Office 365 environment:
1. After opening the Project Online Desktop Client, at the login screen, for Profile select Computer, and then
select OK.
2. On the next screen, select Blank project.

3. On the new project page, select the File menu.
4. On the Backstage menu, select Info, and then select Manage Accounts.
5. On the Project Web Apps Accounts page, select Add.

6. On the Account Properties page:
For Account Name, type a name for this profile.
For Project Server URL type the URL for your Project Web App home page in Project Online. Check
with your Office 365 admin if you do not know what it is.
Select Set as default account if you want to use this as your default profile each time you open Project
Online Desktop Client.
Click OK.
7. Your new account will now show On the Project Web App Accounts page. Click OK.
8. Close and then reopen the Project Online Desktop Client. At the login window, select your account and click
OK to connect to Project Online.
NOTE
You can also connect to Project Online with supported versions of Project Professional. See Project Online client requirements
for more information.
Set up another Project Online site
You may decide that you want to set up an additional Project Online site, to manage projects in a separate
environment from your first Project Online site. You can do this by creating another site collection with Project
Web App.
To set up another Project Online site:
1. Where to sign in to Office 365 for business with your work or school account.
2. Select the app launcher icon in the upper-left and choose Admin.
TIP
The Admin tile appears only to Office 365 administrators.
3. In the lower-left navigation, select Show all, expand Admin Centers and open the SharePoint admin
center.
4. In the SharePoint admin center, select Active sites.
5. On the Active sites page, select Create, and on the Create a site page, select Other options.
6. On the Other options page, from the Choose a template menu, select Project Web App site.
7. Give the site a name, type the name or email address of the site's Primary administrator, select a time zone,
and select a language.
8. Select Finish.
NOTE
After setting up the site, wait 15 minutes before using it, so that Project Online can finish installing.
Delete a Project Web App site
After you subscribed to Project Online, you may have created a couple of different Project Web App sites to try
things out before rolling it out to the rest of your team. When you're ready, you can delete an unused Project Web
App site.
1. Sign in to Office 365 with your work or school account.
2. Go to the SharePoint admin center.
3. Point to the Project Web App site that you are deleting, and then select the check box to the left of the URL.
4. On the ribbon, in the Contribute group, select Delete.
5. Select Delete to move the site collection to the Recycle Bin.
The site collection stays in the Recycle Bin for 30 days, and then is permanently deleted. During the 30 days when it
is in the Recycle Bin, you can Restore a deleted site collection at any time, and the Project Web App database is also
restored.
Make room for a new Project Web App site

Project Online allows you to have seven site collections with Project Web App. If you have seven sites, and you
delete one using the steps above, Project Online will continue to count the deleted site as one of your seven sites
until it is permanently deleted from the Recycle Bin in 30 days.
If you would rather not wait 30 days to free up a Project Web App site, you can disable Project Web App on a site
collection.
NOTE
Already deleted the site collection?Restore a deleted site collection, and then follow the steps below to disable Project
Web App.
Disabling Project Web App is not reversible, so be sure that you will never need to restore the Project Web
App site that you are disabling. Once Project Web App is disabled, the database with all of your project information
is permanently deleted.
1. Sign in to Office 365 with your work or school account.
2. Go to the SharePoint admin center.
3. Point to the Project Web App site that you are deleting, and then select the check box to the left of the URL.
4. On the ribbon, in the Manage group, select Project Web App > Remove.
5. Select Disable.
After you disable Project Web App, you don't have to delete the site collection. When you are at your seven-site
limit, disabling Project Web App is enough to make it so that you can create a new Project Web App site.
Turn on notifications in Project Web App
Project Web App can be set up to send email notifications, helping people stay on top of what's going on in a
project. When notifications are turned on, users can decide which notifications they'd like Project Web App to send.
NOTE
This article covers how an administrator turns on notifications across all of Project Web App. Get email reminders about your
work in Project Web App
To turn on notifications
1. In Project Web App, choose Settings > PWA Settings.
2. Under Operational Policies, choose Additional Server Settings.
3. Under Notification Email Settings (at the bottom of the page), select the Turn on notifications check
box, and then choose Save.
Periodic tasks for Project Online administrators
This article describes periodic checks Project Online admins should perform to maintain their environments.
Project Online administrators should perform the following periodic checks to their environment as an important
part of their job:
DAILY
Check the queue for Failed and Blocking jobs.
Review the errors related to Failed and Blocking jobs to troubleshoot.
Cancel Failed and Blocking jobs.
WEEKLY
Check Active Directory synchronization

jobs to ensure they were successful.
Update Resource Breakdown Structure

(RBS) values for new users. Newly
synched users won't have an RBS.
NOTE: This may be the job of the PMO.
Clear any overly long delegation Delete Enterprise Objects User Delegation.
sessions in Server Settings
Maintain a valid enterprise resource

pool by checking for users who haven't
logged in for 60 days and find out why.
For example, they may have left the
company, are unaware of PWA, or could
have been added mistakenly when
someone else needed access.
Check the ADMINISTRATORS group for

admins that should be removed.
Check with Office 365 Global admin for

news on upcoming features or updates.
MONTHLY
Provide timesheet training to new users.
Provide project manager training to new project managers.
Check with Office 365 Global admin on license usage. For example, use data to follow up with users on licenses that are not being
used.
QUARTERLY
Close timesheet periods for the previous quarter plus one or some similar period. For example, if you are in Q4, close the
timesheet reporting periods for Q2. The interval will be based on business or reporting needs.
Check with the project manager first, then close tasks to updates on projects that are complete or mostly compete or that have
older tasks.
Delete timesheets from the past. Again, this will be defined by a policy that is based on business needs for reporting timesheet
data.
YEARLY
Create fiscal periods for the next calendar year.
Create timesheet periods for the next calendar year. The prefix might equal "Week.", starting at 1, and the suffix might be the
calendar year, such as ".2016". Week 1's period will show as "Week.1.2016".
Consider deleting timesheets for long-ago periods.

Create unique Project IDs for my projects in Project
Online
When creating new projects in Project Online, some companies may want to create a unique Project ID to
associate with each project. This allows users to reference each project by a unique Project ID instead of a project
name, since project names can be changed.
A Project admin can configure Project Online to generate a unique Project ID for each new project through
Enterprise Project Type (EPT) configuration settings. You can configure the EPT's Project ID settings so that when a
new project is created through the EPT, it will generate a unique Project ID for the new project based on the
naming properties you configured.
Configure Project ID settings when creating a new Enterprise Project

Type in Project Online
1. On the Project Web App home page, select Server Settings.
2. On the Server Settings page, in the Workflow and Project Detail Pages section, click Enterprise Project
Types.
3. Select New Enterprise Project Type.
4. On the New Enterprise Project Types page, in the Name field, specify a name for the Enterprise Project
Type you want to create. For example, if the EPT is going to be used by the Finance Department for high risk
projects , you could enter ** Finance Dept (High Risk) **.
5. In the Description field, type a description of the EPT. For example, Use this EPT to create high-risk projects
for Finance .
6. In the Project ID section, you need to enter information that will be used to create a unique Project ID for
your projects that are created through the EPT template:
In the Prefix field, you can enter characters that will be at the start of each generated Project ID. For
example, you may want the Project ID for projects created through the Finance Department EPT to begin
with FIN_. This field is optional.
In the Starting Number field, enter a number that will serve as a starting point for Project IDs that are
going to be generated for this EPT. For example, enter 10001 if you want the first Project ID to be 10001.
This field is required.
In the Postfix field, you can enter characters that can be used to append your Project IDs that are generated
by this EPT. For example, if this EPT is used to create only high-risk projects for the Finance department, you
could enter _HR. This field is optional.
In the Minimum Digit Padding field, enter a number of digits that you want to have for newly generated
Project IDs. For example, if you enter 3 and have a Starting Number of 1, then the first three Project IDs that
will be generated are 001, 002, and 003. If you enter 5 with a Starting Number of 1, the first three Project
IDs that will be generated are 00001, 00002, and 00003.
For example, with the sample settings used in the procedure above, the Project IDs generated through the Finance
Dept (High Risk) EPT will be:
FIN_10001_HR
FIN_10002_HR
FIN_10003_HR
Etc.
NOTE
While the Prefix and Postfix fields are optional, the easiest way to ensure uniqueness across all EPTs is to make sure you
provide either a unique Prefix or Postfix.
Best practices
For larger organizations, it is a good idea for the Project admins or PMO to agree upon a Project ID naming
convention and a numeric range to ensure uniqueness. Additionally, it is also a good idea to document the EPT
settings for reference. For example:
USED TO MAKE
MINIMUM DIGIT PROJECTS FOR THIS
PREFIX STARTING NUMBER POSTFIX PADDING TEAM
Fin_ 10001 _HR 1 Finance Team: High-

risk projects
IT_ 10001 1 Information

Technologies Team
MKT_ 10001 1 Marketing Team
Other best practices to consider:

It is important that you come up with a naming convention on how you want to segment your Project IDs
before starting the configuration of your EPTs to ensure uniqueness across different EPTs.
If you're planning to update the Project ID value programmatically via the Client-side Object Model
(CSOM ), the uniqueness of the value will have to be managed by your custom code to avoid duplicates.
A Project ID can be edited if it is added to a Project Detail page. You can use this approach to perform ad-
hoc edits of the Project ID value if needed. As always, ensure that there is a standardized naming convention
in place to ensure uniqueness of your Project IDs if you need to make ad-hoc changes.
Supported languages for Project Online
When you set up a Project Online site, you need to select a language in which the site will display. If you are in an
environment in which you need to set up Project Online sites for multiple languages, you need to know:
Which languages are supported by Project Online?
What happens if I select a language that is not supported by Project Online?
Which languages are supported by Project Online?

Project Online supports the following language. If you create your Project Online site and select one of the
following languages, Project Online will display in the selected language.
NOTE
SharePoint Online supports all of the languages that are supported by Project Online.
LANGUAGE LL-CC LOCALE ID (LCID)
Arabic ar-sa 1025
Chinese (PRC) zh-cn 2056
Chinese (Taiwan) zh-tw 1028
Czech cs-cz 1029
Danish da-dk 1030
Dutch nl-nl 1043
Engish (US) en-us 1033
Finnish fi-fi 1035
French fr-fr 1036
German de-de 1031
Greek el-gr 1032
Hebrew he-il 1037
Hungarian hu-hu 1038
Italian it-it 1040

LANGUAGE LL-CC LOCALE ID (LCID)
Japanese ja-jp 1041
Korean ko-kr 1042
Norwegian nb-no 1044
Polish pl-pl 1045
Portuguese (Brazil) pt-br 1046
Portuguese (Portugal) pt-pt 2070
Romanian ro-ro 1048
Russian ru-ru 1049
Slovak sk-sk 1051
Slovenian sl-si 1060
Spanish es-es 3082
Swedish sv-se 1053
Turkish tr-tr 1055
Ukrainian uk-ua 1058
What happens if I select a language that is not supported by Project

Online?
Project Online sites are built on SharePoint Online. When you create a new Project Online site, all of the languages
that are listed in the Select a language list are those that are supported by SharePoint Online.
However, Project Online does not support all of the languages that SharePoint Online supports. If Project Online
does not support a language that is supported by SharePoint Online, Project Online will display its interface in an
alternate language.
If you select a language that is supported by Project Online, the Project Online and SharePoint Online interface
provided through the site will display in the selected language. For example, in the graphic below, Spanish was the
selected language, and all components on the Project Online page (SharePoint Online and Project Online) will
display in Spanish.
If you select a language that is not supported by Project Online, the Project Online interface will be displayed in an
alternate language, and the SharePoint Online interface will display in the selected language. For example in the
graphic below, Thai was the selected language when creating the Project Online site. Since Thai is not supported by
Project Online, Project Online components and data will display in the alternate language specified for Thai, which
is English. SharePoint Online components will still display in Thai.
The following table lists SharePoint Online supported languages in which an alternate Project Online language is
provided.
SHAREPOINT ONLINE SUPPORTED LANGUAGE IN WHICH PROJECT

ONLINE DOES NOT SUPPORT THE SAME LANGUAGE PROJECT ONLINE ALTERNATE LANGUAGE
Azeri (Latin) English
Basque Spanish
Bosnian English
Bulgarian English
Catalan Spanish
Croatian English
Dari English
Estonian English
Gaelic Irish English
Galician Spanish
SHAREPOINT ONLINE SUPPORTED LANGUAGE IN WHICH PROJECT
ONLINE DOES NOT SUPPORT THE SAME LANGUAGE PROJECT ONLINE ALTERNATE LANGUAGE
Hindi English
Indonesian English
Kazakh Russian
Latvian English
Lithuanian English
Macedonian English
Malay English
Serbian (Latin) English
Thai English
Vietnamese English
Welsh English
Learn which web browsers and Project Professional client versions are supported to work with Project Online.
Browser Requirements
Project Online is supported to work with the following web browsers:
Internet Explorer: The most current or immediately previous version.
Microsoft Edge: The most current version.
Safari, Chrome, or Firefox: The most current version.
Project Professional Requirements

When connecting to Project Online with Project Professional, there will always be a minimum supported build that
will be noted to customers. Project Online admins can see what the current minimum supported build number is
by looking at the information provided in their Project Online settings :
To check the minimum supported build for Project Professional connectivity
1. In the Project Online quick launch, select Server Settings.
2. On the PWA Settings page, in the Operational Policies section, select Additional Server Settings.
3. On the Additional Server Settings page, in the Project Professional Versions section, under Minimum
Versions you can see the minimum supported build numbers for Project Professional clients that can
connect to Project Online. These include:
Project Professional 2016
Project Professional 2019
Project Online Desktop Client (subscription version included with Project Online Professional and Project
Online Premium licenses)
All builds that are at or higher than the current minimum build number posted on this page are supported
to connect to Project Online.
IMPORTANT
The minimum supported build of Project Professional clients that will connect to Project Online changes over time as
updates for new features and fixes are introduced. Always check the Project Professional versions setting on the
Additional Server Settings page to see the most current information.
How do I find what Project Professional client and build number I am

using?
You need to determine the Project Professional client and build number you are using to find out if the version you
have is supported to connect to Project Online.
If you do not readily know what you are using, it can be easy to confuse Project Professional with the Project
Online Desktop Client. You can easily check your product and build number though the following procedure.
To determine your product and build number
1. In any open project, select the File menu.
2. In the left pane of the backstage page, select Accounts.
3. On the Accounts page, under Product Information:
You will see Project Online Desktop Client if you are using the Project Online Desktop Client.
You will see Microsoft Project Professional 2016 if you are using Project Professional 2016.
4. Select About Project.
5. On the next page that displays, you will see the build number for the Project Professional client you are
using at the top of the page.
For example, if Product Information shows that you are using the Project Online Desktop Client,
16.0.7629.1000 might display as the build number.
As another example, if Product Information shows that you are using Project Professional 2016,
16.0.4266.1001 might display as the build number.
See also
Project 2016 Updates
Project Online Service Description
Configure Office 365 Project Portfolio Dashboard
NOTE
This article has done its job, and will be retiring soon. To prevent "Page not found" woes, we're removing links we know
about. If you've created links to this page, please remove them, and together we'll keep the web connected.
The Office 365 Project Portfolio Dashboard app provides a variety of project, task, and resource-based reports,
including issues/risks/deliverables reporting for Project Online. You can download it from the SharePoint Store for
free.
To install Portfolio Dashboard
1. Under Site settings, click Add an app.
2. On the Your Apps page, in the left navigation, click SharePoint Store.
3. In the SharePoint Store, search for Office 365 Project Portfolio Dashboard.
4. Click Add It, and then click Continue.
5. Make sure the Add this app to Project Web App check box is selected, and then click Return to site.
6. Click Trust It.
In order for users to be able to access the Portfolio Dashboard, they must be members of one of the following
SharePoint groups in Project Web App:
Administrators for Project Web App
Portfolio Managers for Project Web App
Portfolio Viewers for Project Web App
Note that even if you're using Project Permission Mode, you still need to add users to these SharePoint groups.
Project Permission Mode security groups cannot be used to grant access to Office 365 Project Portfolio
Dashboard.
See also
Customize SharePoint site permissions
Set up timesheets
Before your team members can start Step 2: Turn in a

timesheet, an administrator needs to set up a few things.
Some things are required, and other options are there in case
you want to go beyond the basics.
The easiest way to set things up

If you don't want to do a whole lot of work to get timesheets up and running, the only one thing you really need to
do is set up how often you want timesheets turned in.
If you go with the default options when you set things up, you'll end up with everything you need to have
your team members turn in timesheets once a week for a year. Simple! The only thing you need to define is the
start date for the first week, and Project Web App will take care of the rest.
1. Go to PWA Settings.
In Project Web App, choose Settings > PWA Settings.
Under Time and Task Management, choose Time Reporting Periods.
2. Set a start date.

If you want timesheets turned in weekly, the only thing you need to change under Define Bulk Period
Parameters is Date the first period starts.
TIP
A best practice here is to set your first week to start on the first day of the week containing the first day of your
fiscal year. For example, if your organization's fiscal year starts on Tuesday, July 1, it might make sense to have your
first batch of timesheets start on the Sunday or Monday before that.
3. Set the format for period names.

Under Define Batch Naming Convention, you can leave things alone if you want and everything will
work just fine. However, a lot of organizations prefer to add some structure to how each time reporting
period is named.
Without a Prefix or a Suffix, your time reporting periods will use simple incremental numbers (1, 2, 3, and
so on). Team members will be able to turn in timesheets just fine with this basic naming.
Adding some structure to the naming gives each reporting period some context. For example, you can set
up reporting periods that are named "Week1_FY15," "Week2_FY15," and so on. This can be helpful if you
need to refer to older timesheets.
As you add a prefix and suffix, an example name is shown.
4. Create periods and save.

Choose Create Bulk.
Choose Save.
Need your timesheets to do more?

If you find that the basic timesheets aren't capturing enough information, you can make them a little more
substantial.
Here are some ways you can take things a bit further:
Add categories of work to capture different types of time, like research or development, or to capture
bigger-picture efforts where your organization may be investing across multiple projects.
Add non-project categories for time spent on other aspects of work, like training or travel.
Set up your fiscal year so that you can map project work against your overall financial plans.
There are also some settings you may want to change that affect how time and task progress is captured and
handled in your organization.
Set up categories for timesheet rows
The rows on a team member's timesheet are used to capture hours spent on specific project tasks, or on other,
non-project activities, like training or vacation. Sometimes, it can be helpful to categorize the task-related hours in
other ways too. Need an example?
To set things up to capture different categories of task-related work, you can create line classifications in Project
Web App.
Create a line classification to categorize task work

2. Under Time and Task Management, choose Line Classifications.
3. Choose New Classification.
4. In the new blank row, type a Name for the category of work, and provide a Description that team
members will understand.
5. Choose Save.
Need an example?
Sara is a consultant who travels a lot to work directly with customers. Her company has just landed a contract with
Contoso, to upgrade their payroll system. As part of the "Contoso Payroll System Upgrade" project, Sara is
assigned to the "Install and configure system" task, where she will travel to Contoso's headquarters and help them
roll things out.
Sara spends part of her time traveling to and from Contoso's offices, and part of her time doing the actual
installation.
On her timesheet, Sara can include the "Install and configure system" task on two separate rows: one row to
capture her travel time ("Travel"), and one row to capture the installation work ("Standard"). This helps Sara's
project manager keep an eye on how much time Sara and other team members are spending on travel for this
particular customer contract.
But wait, what about administrative time?

**Aren't we supposed to use administrative time to capture things like travel and training?**Project Web App also
lets you create administrative time categories, for things like travel, training, vacation, or sick leave. What makes
administrative time different is that the hours recorded in those timesheet rows are not part of any particular
project or task. It's perfectly okay to have some overlap between line classifications and administrative time.
For example, you may need a line classification for travel, for times when people are traveling to work on a
particular task, like Sara going to Contoso for their installation.
You may also need an administrative time category for travel, to capture time spent traveling between different
branch offices to get things done on multiple projects, or to attend training sessions that aren't directly related to
any one project.
Want to set up administrative time categories?
What if I don't want a category anymore?

If you no longer want team members to be able to use a category in their timesheets, you can make it inactive.
NOTE
But I want to delete it! You can delete line classification categories too, but only if they haven't been used on any
timesheets. Choose the row you want to delete, and then choose Delete Classification. > Inactive categories are not
available for team members to choose, but they can still be used in reports that include previous timesheet data.
To make a line classification category inactive

1. Choose Inactive in the Status column.
2. Choose Save.
Configure time and task progress
There are several ways you can set up time and task progress for your organization in Project Web App.
1. First, decide how task progress should be captured in your organization. Do you want it reported in a
timesheet, along with the hours a team member has completed, or do you want it split out?
2. Next, consider different ways you might customize timesheets and task progress. Every
organization does things differently, and there are several settings that let you control what gets reported.
3. Figure out how you want approval to work. Is the project manager the only person who needs to
approve things? Or are more people involved, like a resource manager or a payroll specialist?
4. Refine your settings by enforcing other policies. Generally it's good to keep things simple, but
sometimes you just can't avoid complexity (especially when timesheets are involved!).
Still stuck?
If you're still not finding the answers you need, try searching for content on support.office.com.
You may also find it helpful to post your questions and issues on a discussion forum. The Project discussion forums
tend to be very active, which make them a great resource for finding others who may have worked through similar
issues, or encountered the same situation.
Customize timesheets and task progress for your
organization
There are several ways to customize timesheets and task progress in Project Web App.
When choosing the right settings for your organization, there are two different spots where you'll need to make
changes. Start by going to Settings > PWA Settings.
From there, some of the settings will be under Timesheet Settings and Defaults.
Other settings will be under Task Settings and Display.
SETTINGS WHERE TO CHANGE THEM WHAT TO CHANGE
What do you want automatically Timesheet Settings and Defaults Under Default Timesheet Creation
included? Mode, you can choose to pre-populate
timesheets with Current task
assignments or Current projects.
Things like vacation and sick leave may
also be automatically included, based
on settings that you choose when you
create administrative time categories.
Report time per day or per week? Timesheet Settings and Defaults Under Timesheet Grid Column Units,
choose whether you want the columns
on a timesheet to represent Days or
Weeks. If you choose Weeks, each
column in a timesheet represents 7
days, and the date in the column
reflects the first day of the week.
This setting is tied to the Reporting

Display.
Report time as hours or as days? Timesheet Settings and Defaults Under Default Reporting Units, you
can choose to have team members
report time as Hours or as Days. You
can also set how many hours are in a
standard timesheet day and in a
standard timesheet work week.
Can team members add personal Timesheet Settings and Defaults Some team members may want to track
tasks? time spent on their own personal tasks,
alongside their hours for tasks and
other work. Personal tasks will not
show up outside of a team member's
timesheet or task status. They are not
mapped to any project or task, or to
any administrative category you may
have set up.
If you want to allow team members to
add personal tasks, select the Allow
new personal tasks check box, under
Timesheet Policies.
Report task progress as hours per Task Settings and Display Under Reporting Display, choose
day or total hours per week? whether you want team members to
report task progress as hours per day,
or as a total for each week. If you
choose weekly reporting, also choose
the start day for the week.
How far ahead do you want to look? Task Settings and Display Sometimes team members are assigned
to so many tasks that it can be
overwhelming to see them all in one
big list. By setting the near future
planning window, you determine which
tasks show up as coming soon, when
the team member goes to report task
progress.
Under Define Near Future Planning
Window, set the number of reporting
periods that you're considering to be
the "near future," in terms of projects
and tasks in your organization.
For example, if you consider the next

two weeks to be the "near future," and
you report time and task progress
using weekly reporting periods, you
could set the near future planning
window to 2 to highlight tasks
happening in the next two weeks.
Set up time and task progress approval
When you decide that you want to use timesheets in your organization, you should also take a few minutes to do
some thinking about how you want timesheet approval to work.
How do I set up approvals in my organization?

Before you jump in and get approvals set up in Project Web App, it's a good idea to step back and think through
how things currently work in your organization, and how you want them to work going forward. Here are some
questions you should try to answer before locking in on a formal approval process.
Do you actually need an approval process in place?
While it may seem natural to set things up so that a manager approves the work that a team member does, it's a
good idea to spend some time chatting about whether you really need to have that formal approval process in
place. What are you really trying to accomplish by requiring approvals? If your organization's pay structure is tied
to the hours entered on timesheets, then the answer is probably yes. But if you're managing projects entirely
separate from your financial systems, you may not really need to maintain a step between your team members
getting work done, and that work being applied to the project plan.
NOTE
You aren't required to set up an approver for everyone! If you don't need someone to approve the hours a person
worked before those hours are applied to the project plan, you don't have to. Simply make the team member his or her own
approver. In fact, that's how Project Web App automatically sets things up when you add someone new, so you really don't
have to do anything. It doesn't get much easier than that!
Who's responsible for approving time?

When a team member does work in your organization, who should be on point to approve the hours spent on that
work? Is it the project manager? Is it someone from payroll? Maybe it's both. To be able to set up Project Web App
in a way that maps to how your organization actually works, you need to figure out the right people to approve
time for work that happens in your organization.
Sometimes, more than one person needs to approve a timesheet. An example of this might be approvals from a
resource manager as well as someone from payroll. If this is the case in your organization, you can set up a chain
of approvers, similar to this:
Bob Jill Frank

Bob is a team member, and Jill is his Jill is a team lead, and Frank is her Frank is in payroll, and is his own
timesheet manager. timesheet manager. timesheet manager.
Bob fills out his timesheet and submits Jill approves Bob's timesheet, and it is When Frank approves Bob's timesheet,
it to Jill. automatically submitted to Frank for the hours Bob entered are applied to
approval. the corresponding project plan.
Only those people listed on the Timesheet Managers page can approve timesheets.
To add someone as an approver
1. Choose Settings > PWA Settings.
2. Under Time and Task Management, choose Timesheet Managers.
3. Choose Managers > Add Manager.
4. Choose the person you want to add as an approver, and then choose OK.
How do I set someone's timesheet approver in Project Web App? You can set a person's Timesheet
Manager in the Add a resource to Project Web App.
Who's responsible for approving task progress?
Remember that Step 3: Update progress, even if both are tracked on a team member's timesheet. Sometimes,
different people are responsible for approving task progress than those who are responsible for approving time.
For example, you may need someone from payroll to approve the number of hours worked (time), but you may
not need that person to approve the percent of work that has been completed (task progress). On the flip side, you
may need a team lead to approve updates to how much work is left to do on a task before it's completed (task
progress), but you may not need that lead to approve the actual hours worked (time). In Project Web App, the
project manager always needs to approve task progress, before it is applied to the project plan.
How do I set someone's task progress approver in Project Web App? Much like approving time, there is also
an approver for task progress too - and this is set to be the project manager making the assignments and is
referred to as the Status Manager.
What other options are there?

There are a couple of other options that might be appropriate for approvals in your organization. Both of these
options are set by going to Settings > PWA Settings. From there, some of the settings will be under
Timesheet Settings and Defaults.
Can managers approve timesheets line by line?

In the Timesheet Policies section, under Task Status Manager Approval, choose Enabled if you want
managers to be able to approve individual timesheet lines. You can also choose to Require line approval before
timesheet approval. Click Save when you are done with your changes.
If you only want managers to approve entire timesheets, choose Disabled.
Can a team member change who approves his or her timesheet first?
Under Approval Routing, select the Fixed Approval Routing check box if you don't want team members to be
able to change the first person who approves a timesheet. Click Save when you are done with your changes.
If it's okay for team members to change the first approver, leave this check box cleared. Once the first approver, set
by the team member, approves the timesheet, the regular approval routing for the timesheet will kick off.
Can team members choose anyone they want as a first approver? No, they can only choose from the list of
people that have been added on the Timesheet Managers page.
Set up policies for capturing time and task progress
In addition to some of the standard settings available for time and task progress in Project Web App, there are also
some more granular policies that let you fine-tune how your organization will work.
POLICIES WHERE TO SET THEM WHAT TO SET
Can team members submit overtime Timesheet Settings and Defaults Under Project Web App Display,
and non-billable time? select the The timesheet will use
standard Overtime and Non-Billable
time tracking check box.
Got limits on how much time can be Timesheet Settings and Defaults Accounting systems, customers, or
reported? other internal factors may require that
you have policies around how much
time can be reported.
Under Hourly Reporting Limits, you
can set Maximum Hours per
Timesheet, Minimum Hours per
Timesheet, and Maximum Hours per
Day.
Can team members report work Timesheet Settings and Defaults By default, team members can't submit
ahead of time? actual work for future time periods. If
your organization is okay with reporting
hours before they actually happen,
select the Allow future time reporting
check box, under Timesheet Policies.
Can team members report time Timesheet Settings and Defaults In Project Web App, tasks can be
against top-level summary tasks? indented below other tasks, and the
work done on the indented tasks will
roll up to the top-level task to
summarize all of the work done in that
area. For example, your task list might
look like this:
Produce white paper
Research subject
Write content
Review content
Incorporate feedback
Publish content
Typically, team members report work
on the indented tasks, and those hours
roll up to the top-level summary task
("Produce white paper"). However, in
some organizations, it might make
sense to allow team members to report
time spent on the summary task, too.
If you want team members to be able
to report time spent on summary tasks,
select the Allow top-level time
reporting check box, under Timesheet
Policies.
Don't want project managers Task Settings and Display Under Protect User Updates, choose
changing actual hours? Only allow task updates via Tasks
and Timesheets.
Want all types of work copied from Task Settings and Display Team members can import their
timesheets to task progress? timesheet hours into their task
progress, to get a jump on filling out
how much work they've finished. By
default, only work that uses the
standard line classification (in the
Billing Category column of a
timesheet) will be imported.
If you want all work across all categories
to be copied to task progress when a
team member imports a timesheet,
select the Import all timesheet line
classifications check box, under
Protect User Updates.
Can team members set the time Task Settings and Display Task progress is different from
frame for a task progress report? timesheets, in that it doesn't necessarily
need to reflect a specific accounting
period. If you want team members to
be able to choose what dates they're
reporting task progress for, select the
Allow users to define custom
periods for task updates check box,
under Protect User Updates.
Set up your fiscal year
Most organizations have a fiscal year (FY) that is used to

calculate finances on an annual basis. Within that fiscal year,
there are typically quarters, months, or other periods used to
evenly distribute financial plans. By setting up fiscal periods in
Project Web App, you can map project work against your
overall financial plans.
What do I need to do?

1. Go to PWA Settings.
In Project Web App, choose Settings > PWA Settings.
Under Time and Task Management, choose Fiscal Periods.
2. Set a start date.

Under Manage Fiscal Period, choose a year, and then choose Define.
Under Define Fiscal Period Start Date, type or choose the first date of your fiscal year.
3. Choose how you want periods set up.

Under Set Fiscal Year Creation Model, choose a method:
Using quarters? Choose one of the numbered methods ( 4,5,4, 4,4,5, or 5,4,4).
The numbers in these methods have to do with how many weeks you want in each fiscal period during
each quarter. For example, here's what one quarter in the 4,5,4 Method looks like:
If you choose the 4,5,4 Method, it will configure four quarters, with three fiscal periods in each quarter. The
first period will be 4 weeks long, the second will be 5 weeks, and the third 4 weeks.
A total of 12 fiscal periods will be set up for any of these numbered methods.
Using months? Choose Standard calendar year to create 12 periods that go from the first day of each
month through the last day of each month.
Or, if you're thinking of months as 4-week increments, choose 13 Months. With this option, a total of 13
fiscal periods will be set up.
None of these work for me. Choose whichever one is closest to how your organization works, and you
can go back and refine things after you've saved.
4. Set the format for period names.
Under Define Period Naming Convention, you can leave things alone if you want and everything will
work just fine. However, a lot of organizations prefer to add some structure to how each fiscal period is
named.
Without a Prefix or a Suffix, your fiscal periods will use simple incremental numbers (1, 2, 3, and so on).
Adding some structure to the naming gives each period some context. For example, you can set up fiscal
periods that are named "Sprint1_FY15," "Sprint2_FY15," and so on. This can be helpful for reporting
because it provides a little more information about what's being captured.
As you add a prefix and suffix, an example name is shown.
5. Choose Create and Save.
After saving, you can change the information or delete rows in the table to refine your fiscal year.
What else can I do?

While you're getting set up, here are some other things you might want to do:
Set up timesheets to capture the actual time that team members spend working on tasks.
Add categories of work to capture different types of time, like research or development, or to capture
bigger-picture efforts where your organization may be investing across multiple projects.
Add non-project categories for time spent on other aspects of work, like training or travel.
Change other settings that affect how time and task progress is captured and handled in your organization.
Set up vacation, sick leave, and other non-project
work categories
Timesheets can be used to capture all of a team member's hours during the week. In some cases, you may only
be interested in capturing the hours spent on specific project tasks. In other cases, you may also want to include
hours spent on other, non-project activities, like training, sick leave, or vacation.
Project Web App already has categories set up for sick leave, vacation, and general administrative time, but you
may also want to create categories for things like training or travel.
To set up Project Web App to capture different categories of non-project hours, you can create administrative
time categories.
TIP
Did you know that you can also set up categories for task-related work?
Create an administrative time category to capture non-project work

2. Under Time and Task Management, choose Administrative Time.
3. Choose New Category.
4. Fill out the new blank row.
Categories Type a name for the new category.

Status Choose whether the category is currently Open for use on timesheets, or Closed.
Work Type Choose whether the category captures Working time, like training or travel, or Non Work
time, like vacation or sick leave.
Approve Choose whether you want time reported in this category to require approval from a manager.
Always Display Choose whether you want this category to be included as a row on every timesheet for
every user, by default. This can help team members remember to report work on things that might be easy
to forget, like sick leave or recurring non-project meetings.
Allow Multiple Lines Choose whether you want team members to be able to include more than one row
on a single timesheet for this category. For example you may want team members to be able to add a
"Travel" category multiple times on a single timesheet, so that each "Travel" line can have a different
description of where the team member went.
Department If your organization has departments set up in Project Web App, you can choose which
departments this category applies to. If you aren't using departments, don't worry about filling out this
column.
5. Choose Save.
What if I don't want a category anymore?

If you want to make it so that an administrative time category is not longer available for team members to add to
a timesheet, change the Status column for that category to Closed, and clear the check box in the Always
Display column.
Set up how time and task progress are captured
There are a couple of different ways you can set up Project Web App to capture task progress. Step 3: Update
progress
Should team members enter time Timesheet Settings and Defaults Select the Single Entry Mode check
and task progress as hours in one box if you want timesheet hours to also
view? be used as task progress.
Is task progress a percentage or a Task Settings and Display If you are NOT using single entry
number of hours? mode, under Tracking Method,
choose the default way that you want
task progress reported: as a
percentage, or as hours. If you choose
hours, you have a couple of different
options - one that includes remaining
work, and one that is simply total hours
worked.
You can also select the check box in this

section to make it so that project
managers are required to collect task
progress using the method you choose.
This helps maintain consistency across
your organization, if that's important
for tracking purposes.
Before you can use Project Online reports in Excel Online, the tenant administrator needs to activate this feature
for the Project Online site collection.
1. Where to sign in to Office 365 for business with your admin account.
2. At the top of the page, select Projects. Or, select the app launcher , and then select Projects.
3. Select Settings > Site Settings.
4. Under Site Collection Administration, select Site collection features.
5. Scroll down in the list to Project Web App Permission for Excel Web App Refresh, and then select
Activate.
TIP
If you have more than one Project Online site collection, make a note about which one has Project Web App
Permission for Excel Web App Refresh activated. When you activate it on one site collection, it is activated for all
site collections in your Office 365 tenant. However, if you ever want to deactivate it, you can only turn it off from the
site collection where you activated it initially.
You should now be able to refresh your Project Online reports in Excel Online.
IMPORTANT
Before using the default Project Online reports ( Project Overview, Resource Overview, and Project Overview
Dashboard), you may need to open each report in Excel 2013, refresh the data, and then save the report back to Project
Online. This will update the report so that it is supported by Excel.
IMPORTANT
For Excel Online to be able to refresh the Excel reports, the Excel reports will need to use the legacy data import wizards. For
details on enabling the legacy data import wizards in Excel, see Data import and analysis options.
What reporting tools can I use with project data?
If you're using Project Web App, you might be wondering what tools you can use to create reports. Whether you're
using Project Web App for Project Server 2013 or Project Web App for Project Online, you have several options
available for viewing and creating reports. You can:
Sample reports in Project Web App that come automatically with Project Web App to get ideas about basic
reports
Excel business intelligence features that include charts, tables, and views
Reports in Project 2013
SQL Server Reporting Services (provided your organization has Reporting Services set up)
Power BI for data visualizations and insights
Use other tools, such as PerformancePoint Services or Visio Services (if your organization has these service
applications set up and you have access to your project data in these tools)
The sections below provide more information about reporting options for project data. To download a poster that
summarizes all of these tools, see Business intelligence for Project in Office and SharePoint.
Sample reports in Project Web App

Project Web App for Project Online comes with several sample reports that you can use a starting point. These
include:
Project Overview Dashboard, which provides high-level information about projects, including start and
finish dates, risks, issues, and tasks. This dashboard was created by using Power View in Microsoft Excel
2013. You must have Silverlight installed on your computer in order to view the workbook.
Project Overview, which provides high-level information about projects, such as percent complete,
number of assignments, and number of tasks. This report was created by using Power Pivot.
Resource Overview, which provides high-level information about projects, including number of hours
worked and number of tasks by resource. This report was created by using Power Pivot.
If you're using Project Web App for Project Server 2013 (on premises), even more sample reports are available.
To learn more about the sample reports, see Sample reports in Project Online.
Excel business intelligence features
Excel 2013 has lots of great business intelligence (BI) features. These include:
Use AutoFill and Flash Fill, which enables you to format a column of data a particular way without having to
use a complex formula. For example, if you have a column that contains a list of dates and times, and you
want a column that contains just dates, you can use Flash Fill to make that change.
Analyze your data instantly, which enables you to select a range of data and instantly see possible ways to
display that data
Create a PivotTable timeline to filter dates and slicers that enable people to view more specific information
in PivotTable reports or PivotChart reports
See Creating charts from start to finish .
Many other BI features are available, including Power Query, Power Pivot, Power View, and Power Map. See the
following resources for more details:
If you're using Project Online (in the cloud), see BI capabilities in Excel and Office 365.
If you're using Project Server (on premises), see Business intelligence in Excel and Excel Services
(SharePoint Server 2013).
Reports in Project 2013

If you're using Project 2013, you have a wide variety of reports available on the Report tab.
See Pick the right report in Project 2013 for an overview of the different reports that are available.
See Create a project report to learn how to create reports in Project 2013.
SQL Server Reporting Services

Reporting Services is a powerful reporting platform that is available with SQL Server. Some customers prefer to
use Reporting Services to create and share reports. Typically, IT administrators and developers create Reporting
Services reports, and then share those reports using SharePoint or a Reporting Services report server. See SQL
Server Reporting Services tools.
Power BI
Power BI offers a great experience for data visualization and insights. See What is Power BI
PerformancePoint Services in SharePoint Server 2013

PerformancePoint Services in SharePoint Server 2013 is a great tool for creating power key performance
indicators (KPIs), scorecards, reports, and dashboards. Ideal for (on premises) data stored in SQL Server Analysis
Services, PerformancePoint Services enables you to create interactive, reusable dashboard items. See TechNet
Article: Create dashboards (PerformancePoint Services in SharePoint Server 2013).
Visio Services
You can use Visio to create a data-connected diagram, and then share it with others by using Visio Services in
SharePoint. See A beginner's guide to Visio and TechNet Article: Overview of Visio Services in SharePoint Server
2013.
Configure rollup of timephased reporting data in
Project Online
Project admins can configure Project Online to roll up timephased reporting data to different levels of granularity.
They can choose to roll up their data daily, weekly, monthly, or by fiscal period and retrieve the data through the
timephased OData endpoints:
AssignmentBaselineTimephasedDataSet
AssignmentTimephasedDataSet
TaskBaselineTimephasedDataSet
TaskTimephasedDataSet
Benefits
A key benefit this provides is that it can help to improve report generation performance, especially in organization
that have a lot of Project Online reporting data. While retrieving task and assignment timephased reporting data
by day was the only option available previously, many organizations do not need this level of granularity. Being
able to retrieve their data on a broader scope (such as weekly or month) can greatly improve report generation
performance by reducing the amount of records that need to be downloaded. For example, instead of needing to
retrieve 300,000 records when set to daily , setting to monthly could reduce this to a much lower number, such as
10,000 records.
With broader levels of granularity, publish times will be a lot faster since project data won't need to be broken
down in daily levels for publishing. In some cases, it can also improve the performance of interacting with Project
Detail Pages. Organizations that have complex workflows that depend on publish to complete to move to the next
PDP will see performance improvements.
NOTE
If your organization has deployed workflows that require a publish job to complete within a step, setting the option to report
timephased data to daily can result in a poor experience for users filling out Project Detail Pages as the workflow will need to
wait on the reporting jobs to complete before moving to the next step. It is recommend not to use daily if you have
workflows that wait on publish to complete. > If you require resource demand data for resource capacity planning, then do
not choose never - as that setting will not show resource demand.
How do I configure this setting?

1. In Project Online home page, select Server Settings.
2. On the Server Settings page, in the Enterprise Data section, select Reporting.
3. On the Reporting page, in the Timephased Data section, select the option that you need:
Never
Daily
Weekly
Monthly
By fiscal period
Tip: If you don't use any of the timephased Odata feeds, we highly recommend setting the Timephased Data option
to "Never" which provides the added benefit of much faster Reporting Publish queue jobs.
Planning considerations I need to make

Republish existing projects - After changing the Timephased data setting, it will only take affect in an
existing project if it is republished.
NOTE
If you have many projects to republish, you can use the Office 365 Project Online CSOM Tool(ProjToolV2) to
programmatically publish your Project Online projects. You should plan to do this at a time that will be least likely to
impact your organization.
New instances - In new Project Online instances, note that the Timephased data default setting is Never.
Make sure to select the appropriate Timephased data setting after creating your new instance to prevent the
need to republish all your projects at a later time. Also consider the tradeoffs associated with a more
granular setting (for example, Daily vs Monthly) with regards to the time it takes to publish as well as pull
down the timephased OData feed.
This table summarizing the considerations and recommended options:
Setting Considerations
Never For customers who do not use the Timephased Odata feeds
and Portfolio Analyses feature, and do not need resource
demand data for capacity planning.
This is the default setting for new Project Online instances.
Much faster Reporting Publish queue jobs.
No additional quota consumed (timephased data consumes
the most space).
> [!NOTE]> For more information about the interaction of this
setting with the Portfolio Analyses feature is available in the
blog post Project Online: Reporting and Portfolio Analysis.
Daily Largest performance impact for publishing/reporting.
Generates largest dataset which results in slower downloads of
timephased Odata feeds and largest DB quota usage.
Recommended only if you need your current/historical reports
on a by day basis.
Weekly Timephased dataset is about one seventh smaller than the

Daily option.
Recommended only if you need your current/historical reports
on a weekly basis.
Monthly Timephased dataset is about one thirtieth smaller than the

Daily option.
Recommended option.
By Fiscal Period Timephased dataset is about one thirtieth smaller than the
Daily option.
Allows administrators control over the time range where
timephased data is published based on the defined fiscal
periods.
Recommended option.
See Also
Brian Smith Blog post: Project Online-Changes to Granularity of Time phased OData
Use Excel 2013 to create a new Project Online report
ProjectData-Project OData service reference
Configure the Resource Center
If your organization uses Active Directory synchronization, the first time you access the Resource Center in Project
Web App, you need to choose which Active Directory group contains the users that you want to make resources in
Project Web App.
To choose which group to use for your Project Web App resources:
1. On the Quick Launch, click Resources.
2. On the Resource Center page, click the click here link to synchronize with an existing Active Directory
group.
3. On the Active Directory Enterprise Resource Pool Synchronization page, in the Active Directory
Group section, enter the name of the Active Directory group that contains your Project Web App resources.
You can enter multiple Active Directory groups, if appropriate.
4. Select the Automatically reactivate currently inactive users if found in Active Directory during sync
check box, unless there is a good reason not to do this in your organization.
5. Click Save and Synchronize Now to add the users that are in the Active Directory group to Project Web
App as resources.
You can also add resources that aren't part of the selected Active Directory group(s). See Add a resource to Project
Web App for more information.
Activate resource engagements in Project Online
If you're using Project Online, you need to activate the resource engagements features before you can start using
them. The engagement features need to be turned on for each Project Online site in your organization.
Overview: Resource engagements
NOTE
Resource engagements are only available if you're using Project Professional 2016 or Project Online Desktop Client,
connected to Project Online or Project Server 2016. Project Standard 2016 does not include resource engagements.
To turn on engagements for a Project Online site:

1. Sign into your Project Online site and choose Settings > PWA Settings.
TIP
If you're in the Resource Center, you can click Additional Server Settings in the yellow note at the top of the view,
and then skip to Step 3.
2. Under Operational Policies, choose Additional Server Settings.
3. Under New Resource Management Features Available, select the Activate check box, click OK after
reading the message about data migration, and then click Save.
What happens to my existing resource plans?

If you've been using resource plans in your Project Online site, those plans will be converted into resource
engagements. Learn more.
FAQ: Resource engagements are replacing the old
resource plans
Resource engagements are new for Project Online, but what happens to the old resource plans? Read on about
this new feature and how old resource plans are converted into resource engagements.
I've heard about this new resource engagements feature. How do I get
it?
Starting on September 22, 2015, we will begin rolling out the new feature, and Project Online administrators will
have the option to turn on the new feature at their convenience once it becomes available. This process is phased,
and it might take some time before everyone is able to see it. This is a site-level activation. Once an administrator
has activated the feature, anyone on that site will be able to see the new Resource Requests page and be able to
start creating and managing requests.
For any new Project Online sites created after the feature is available for the tenant, the administrator will still need
to activate the feature for the new instance.
We recommend that the Project Online administrator turn on the feature in a spare Project Web App (PWA)
instance first to become familiar with it before turning it on in the main PWA instance.
Please note, once the feature has been activated for a site it cannot be de-activated. This is a one-way operation.
How long can a Project Online administrator wait to turn on the

feature?
For any new PWA site created on April 4, 2016 or later, the resource engagements feature will already be on—no
need to activate them.
For PWA sites created before April 4, 2016, the Project Online administrator can choose to turn on engagements
at any point. The feature will no longer be automatically activated on September 22, 2016.
I'm excited about the new resource engagements, but what happens to
my old resource plans?
The good news is, once the new feature has been turned on, your old published resource plans will be converted
into resource engagements. When the feature is activated we will start migrating the old published resource plans.
Before you activate this feature, we recommend that you:
Make sure your existing resource plans have timephased data.
Republish any existing resource plans.
Since engagements are time-based, if your resource plan does not contain any timephased information (resources
only), no engagements will be created. We will do our best to convert resource plans into engagements, provided
all of the necessary data is available. Once the activation is complete, you will no longer be able to access the old
resource plans, but can start creating new engagements to replace them.
For every published resource plan, we will use some of the data to create new engagements. The status will match
that from the resource plan and all of the timephased data will be transferred.
After the feature has been activated, you will no longer be able to access the old resource plan UI, and that page
will be deprecated.
How do I know if my resource plans were successfully migrated into

engagements?
Once the Project Online administrator has activated the feature, there will be a section in Additional Server
Settings that shows the progress.
After migration is complete, the New Resource Management Features Available section will disappear. You
should now be able to visit the Resource Requests page and view the newly created engagements that were
based on your old resource plans.
What about my existing reports involving resource plans?

Your existing reports will no longer return any data since the old resource plans will be deleted from the reporting
database. You will be able to create any new reports you like using engagement data. We have added support
through OData to create new reports on engagements.
What about portfolio analysis? Our organization used to use resource

plans to do resource modeling.
Portfolio analysis will now include engagement data instead of resource plan data. Similar to how the old resource
plans were handled, you will have the option to include both proposed and committed engagements, or just
committed ones, when doing your analysis.
What about extensibility? Can I access the APIs for engagements?

There are resource engagement APIs available, the Project Server CSOM class details are here:
Microsoft.ProjectServer.Client Namespace
When will this be available to Project Server customers?

In the next release of Project Server, customers will be able to access all of these features.
Using workflow for demand management in Project
Online
This article describes how demand management is implemented in Project Web App.
You can use the demand management tools in Project Web App to capture all project ideas in one place, and then
guide them through a decision-making process catered to your business's needs. Using these tools can help your
users make decisions about which proposals to approve, and track progress on a project until the work is
completed.
Demand management in Project Online uses:
Project detail pages - Project Web App pages where users can view and update project information.
Stages - sets of project detail pages specific to one area of the project lifecycle.
Phases - a way to organize multiple stages.
Workflows - a way to enforce your business processes as projects move through the various phases and
stages.
Enterprise project types - a way to bring phases, stages, and project detail pages together with a workflow
into a standardized way of doing a project.
We'll go over each of these in the sections that follow.
Project detail pages

Project Web App users view or update project data on project detail pages. You can customize a project detail page
by choosing web parts that use the fields you want displayed. In demand management, project detail pages are
displayed to the user at various stages of a project whenever you need to gather information from or display
information to a user.
Stages
A stage includes one or more project detail pages, grouped to gather information about a project. This information
can be used or updated by a workflow.
In Project Web App, you can define which project detail pages are displayed in a given stage, which fields are
required and which are read/write or read-only, and which phase (we'll talk about phases in the next section) the
stage is part of.
For each stage of a project, we recommend that you define what actions need to take place and what information
needs to be gathered based on your business requirements for the project. This information will help you define
the list of fields that you need to display in the project detail pages and what actions you need the workflow to
take. The following steps list the general procedure:
1. Define what needs to happen with the project in each stage
2. Define the required information that you want to capture using project detail pages
3. Define the state of the fields in each stage (Required, read/write, or read-only)
Phases
A demand management phase is used to organize multiple stages that make up a common set of activities in the
project life cycle. Examples of phases are project creation, project selection, and project management (represented
in the default Project Web App phases as Create, Select, and Manage). The phases themselves are just a way of
organizing your stages and do not determine the order in which the stages are executed. (The order of the stages is
determined by the associated workflow.)
See Best practices for creating phases and stages for more information.
Workflows
Workflows enforce your business processes and provide a structured way for projects to move through phases
and stages. You can set up a workflow to do a variety of actions based on the user input for each stage, including
sending emails, assigning tasks, and waiting for specific project actions.
For example, you might have an "Initial Proposal" stage where you include a project detail page with a custom field
for project cost. You could configure the workflow to automatically accept or reject the project based on whether
the project cost exceeds a certain limit.
The image below shows the five phases of demand management that are included in Project Web App and how
they fit together. Within each phase are example stages such as "Propose idea" and "Initial review." Each stage can
have one or more associated project detail pages. The entire collection of stages represents a single workflow that
can be associated with an enterprise project type.
There are four general steps to perform to create your workflow in Project Web App:
1. Design the workflow based on your business requirements.
2. Create the needed custom fields, project detail pages, phases, and stages in Project Web App.
3. Create the workflow in SharePoint Designer 2013 and deploy it to Project Web App.
4. Create an enterprise project type that uses the workflow.
Enterprise project types

An enterprise project type brings together all the elements of demand management by combining a single
workflow with its phases and stages with department and project site template definitions. Normally, enterprise
project types are aligned with individual departments, for example, marketing projects, IT projects, or HR projects.
Using enterprise project types helps to categorize projects within the same organization that have a similar project
life cycle. For a user, the enterprise project types appear in a drop-down list when the user clicks New Project in
the Project Center.
Troubleshoot Project Online workflows
It is common as a Project Web App admin to have to troubleshoot Project workflows. Depending on how the
workflow process has been defined for the organization, there may be instances where an admin needs to act for
the workflow instance to progress. There are fields that a user can add to the Project Center, query OData or the
Project Online Rest endpoint to better understand the state of each Project workflow. With the information
provided in these fields, a Project Web App admin can take the appropriate corrective action to unblock the
progression of the Project workflow.
There are three steps on troubleshooting Project Online workflows:
1. Setting up views and reports to see the errors
2. Reviewing the errors
3. Acting on the errors and taking additional steps
Setting up views and reports to see the errors

An admin can see Project workflow errors in two ways:
Create a Project Center View to see workflow state
Query Project OData Service or the Project REST API
Create a Project Center View to see workflow state
We recommend creating a new Project Center view to troubleshoot Project workflows. To create the view or edit a
Project Center view, the user will need to have the Global permission to Manage Project Web App Views
NOTE
For more information on how to manage security, please see Video series: How security permissions work in Project Server
To create the view

1. From Project Web App, click on the gear icon then ** PWA Settings **.
2. On the settings page, click Manage Views. A list of views will appear.
3. Click ** New View **.
4. In the Name and Type section, in the ** View Type ** list, select Project Center.
5. In the Name box, type the name of the new view. For example, " Project Workflows ".
6. In the Description box, type a description of the new view.
7. In the Table and Fields section, from the Displayed Fields list, remove the default Start and Finish fields.
Add the following fields from the Available fields list:
Workflow Error Code
Workflow Error
Workflow Created
Workflow ID
Workflow Last Run
Workflow Owner
Workflow Phase Name
Workflow Stage Name
Workflow State
Checked Out
Checked Out By
8. Scroll to the bottom of the page and click Filter.
9. Add the filter using the field " Workflow Error Codeis greater than 1" and click OK .
10. Click Save.
NOTE
After clicking Save, you will receive the following message: " You have not assigned a security category to this view.
Failure to do so will prevent anyone from seeing the view in the dropdown or from using the view. Do you want to
save anyway? " Click OK, because only members of the PWA Administrators group will be able to view the Project
Workflows Project Center view.
Query Project OData Service or the Project REST API

Optionally users can query for this information from the Project OData Service or programmatically through the
Project REST API.
Project OData Service
PROJECT CENTER FIELD ENTITY PROPERTY
Workflow Error Code Projects WorkflowErrorResponseCode
Workflow Error Projects WorkflowError
Workflow Created Projects WorkflowCreatedDate
Workflow ID Projects WorkflowInstanceId
Workflow Last Run ProjectWorkflowStageData StageLastSubmittedDate
Workflow Owner Projects WorkflowOwnerName
Workflow Phase Name ProjectWorkflowStageData PhaseName
Workflow Stage Name ProjectWorkflowStageData StageName
Workflow State ProjectWorkflowStageData StageStatus

NOTE
For more information about the Project OData service, see ProjectData-Project OData service reference.
Project REST API
PROJECT CENTER FIELD ENTITY PROPERTY
Workflow Error Code ProjectWorkflowInstance WorkflowErrorResponseCode
Workflow Error ProjectWorkflowInstance WorkflowError
Workflow Created ProjectWorkflowInstance WorkflowCreatedDate
Workflow ID ProjectWorkflowInstance Id
Workflow Last Run ProjectWorkflowInstance LastSubmittedDate
Workflow Owner Projects ProjectOwnerName
Workflow Phase Name ProjectWorkflowStageData PhaseName
Workflow Stage Name ProjectWorkflowStageData StageName
Workflow State ProjectWorkflowInstance WorkflowState
Code Examples
Read a filtered set of projects and retrieve the project workflow instances. If the request includes more then 20
projects, you will need to add additional filtering otherwise the request will fail:
GET https://CONTOSO.sharepoint.com/teams/project/PWA/_api/projectserver/projects?
$Filter=startswith(Name,'Budget')&$Expand=ProjectWorkflowInstance,ProjectWorkflowInstance/WorkflowInstance
Read all workflows with error response codes greater than or equal to 400, including the owner and minimal
details about the project:
GET https://CONTOSO.sharepoint.com/teams/project/PWA/_api/projectserver/projectworkflowinstances?
$FILTER=WorkflowErrorResponseCode ge
400&$SELECT=Id,WorkflowError,WorkflowErrorResponseCode,WorkflowState,Project/Id,Project/Name&$EXPAND=Wo
rkflowInstanceOwner,Project
NOTE
For more information about developing against Project Online, please visit the Project Dev Center.
Reviewing the errors

If the admin created a Project Center view as described above, the view can be accessed following these steps:
1. From Project Web App, navigate to Project center by clicking Projects from the Quick Launch.
2. Click on Projects in the ribbon.
3. Select the view that was created following the steps above from the View: dropdown.
This will provide the user with a list of all the projects and the current status of each project's workflow,
including errors.
Optionally the user can review the errors through a custom report or programmatically as described above.
NOTE
The Workflow Created and Workflow Last Run display date and time in UTC.
NOTE
After acting on the errors it will take up to 24 hours for the status to be updated in Project Center, Project Service OData and
through the Project REST AP.
Acting on the errors and taking additional steps

The following errors may happen with a Project workflow:
ERROR ACTION
We were not able to update the status for project Typically this error will be resolved if no action is taken for a
PROJECT_GUID period of time. If you need the error to be resolved
immediately, try How to Resume a SharePoint Workflow.
We were not able to update the status for stage STAGE_GUID Typically this error will be resolved if no action is taken for a
on project PROJECT_GUID period of time. If you need the error to be resolved
immediately, try How to Resume a SharePoint Workflow.
Stage STAGE_GUID is not the current stage for project This error happens when attempting to set workflow stage
PROJECT_GUID status for a workflow stage that is not in valid. In this
situation, you need to How to Restart a Project Workflow.
Custom field CUSTOM_FIELD_GUID does not have a value set A custom field is not correctly set and the workflow is unable
for project PROJECT_GUID to progress until the custom field value is updated. To
determine the name of the custom field that needs to be
updated, see the section titled How to get a Custom Field
from a Custom Field GUID. After updating the custom field,
try How to Resume a SharePoint Workflow.
> [!NOTE]> As a best practice, it is recommended for
true/false custom fields involved in a workflow to use a lookup
table opposed to a flag custom field to prevent this issue for
custom fields of this type.
The custom field CUSTOM_FIELD_GUID does not exist. This happens when the workflow attempts to read or write the
value for a custom field which has been removed from PWA.
You will need to edit the workflow and ensure proper custom
field is associated with the workflow.
Failure submitting Check-in job for project PROJECT_GUID Typically this error will be resolved if no action is taken for a
period of time. If you need the error to be resolved
immediately, try How to Resume a SharePoint Workflow. If the
issue continues to persist, you will need to How to Restart a
Project Workflow.
ERROR ACTION
Failure submitting Publish job for project PROJECT_GUID Typically this error will be resolved if no action is taken for a
period of time. If you need the error to be resolved
Project Workflow.
Failure submitting Publish Summary job for project Typically this error will be resolved if no action is taken for a
PROJECT_GUID period of time. If you need the error to be resolved
Project Workflow.
Failed to create a project from list item This is an error that is impacting the
CreateProjectFromListItem activity. First, try How to Resume a
SharePoint Workflow. If the issue persists, review the PWA
queue to see if there is a failed queue job for the project
creation.
Could not find list item to create a project for web WEB_ID list The list item does not exist anymore. You can check the
LIST_ID item LIST_ITEM_ID Recycle Bin to see if you can restore the list item.
Could not find an idea associated with project PROJECT_GUID This happens when the idea that was initially used for project
while trying to update status creation is deleted. You can check the Recycle Bin to see if you
can restore the list item.
Job id JOB_GUID is invalid Contact Microsoft Support if you get this error message.
Workflow owner does not have permission to check-in project Admin needs to grant check-in permissions to the workflow
PROJECT_GUID owner. After granting permissions, try How to Resume a
SharePoint Workflow. If the issue continues to persist, you will
need to How to Restart a Project Workflow.
Workflow owner does not have Edit Project Summary Fields or Admin needs to grant appropriate permission to the workflow
Save Project to Project Server or Publish Project category owner. After granting permissions, try How to Resume a
permission on project PROJECT_GUID SharePoint Workflow. If the issue continues to persist, you will
Workflow owner does not have New Project global permission This happens when attempting to create a project from a
SharePoint list item and the user that starts the workflow
instance cannot create new projects in PWA.
Admin needs grant appropriate permission to the user. After
granting permissions, try How to Resume a SharePoint
Workflow. If the issue continues to persist, you will need to
How to Restart a Project Workflow.
Workflow owner does not have Open and Save Project To Admin needs to either grant appropriate permission to the
Project Server category permissions on project PROJECT_GUID user. After granting permissions, try How to Resume a
Workflow owner does not have Open Project category Admin needs to either grant appropriate permission to the
permission on project PROJECT_GUID user. After granting permissions, try How to Resume a
ERROR ACTION
Workflow owner does not have Publish Project category Admin needs to either grant appropriate permission to the
permission on project PROJECT_GUID user. After granting permissions, try How to Resume a
The project workflow cannot have multiple stages in progress This error shows up if the workflow instance attempts to enter
a stage without closing previous stage. Contact Microsoft
Support for more help with this error.
The project workflow must have one stage in progress This error shows up if the workflow instance attempts to leave
a stage without setting the next stage in progress. Contact
Microsoft Support for more help with this error.
Project PROJECT_GUID cannot have a workflow This error occurs when trying to start a workflow instance on
an unsupported project type. Contact Microsoft Support for
more help with this error.
Project PROJECT_GUID has failed to check-in A PWA queue job has failed preventing the workflow from
progressing. Review the failed queue job from the Manage
Queue job page within PWA.
Project {0} has failed to check-in after the custom field {1} A PWA queue job has failed preventing the workflow from
value was updated progressing. Review the failed queue job from the Manage
Project PROJECT_GUID has failed to check-in after the A PWA queue job has failed preventing the workflow from
property PROPERTY value was updated progressing. Review the failed queue job from the Manage
Project PROJECT_GUID is checked out in another session Admin needs to either force check-in the project or ask the
user to check the project in. After the project is checked-in, try
How to Resume a SharePoint Workflow. If the issue continues
to persist, you will need to How to Restart a Project Workflow.
Project PROJECT_GUID is checked out to another user Admin needs to either force check-in the project or ask the
user to check the project in. After the project is checked-in, try
How to Resume a SharePoint Workflow. If the issue continues
to persist, you will need to How to Restart a Project Workflow.
Project PROJECT_GUID does not have a workflow Contact Microsoft Support if you get this error message.
Project PROJECT_GUID is not checked out The admin will need to review the workflow definition and
verify no project updates are attempted before the project is
checked-out.
Project PROJECT_GUID does not exist Contact Microsoft Support if you get this error message.
Project PROJECT_GUID cannot be published because the Typically this error will be resolved if no action is taken for a
PROJ_PWA_SHORT_NAME is in Read Only mode period of time. If you need the error to be resolved
immediately, verify that the PWA site is not in read only mode
by navigating to the site and seeing if there is a notification
across the top of the page. If there is no notification, then try
How to Resume a SharePoint Workflow.
ERROR ACTION
Failed to update project PROJECT_GUID A PWA queue job has failed preventing the workflow from
progressing. Review the failed queue job from the Manage
Property PROPERTY does not have a value set for project The admin will need to review the workflow definition and
PROJECT_GUID verify properties are being set correctly.
Property PROPRERTY does not exist Contact Microsoft Support if you get this error message.
Failed performing a Publish operation on project A PWA queue job has failed preventing the workflow from
PROJECT_GUID progressing. Review the failed queue job from the Manage
Failed performing a Publish Summary operation on project A PWA queue job has failed preventing the workflow from
PROJECT_GUID progressing. Review the failed queue job from the Manage
401 User not found/user is inactive You will need to How to Restart a Project Workflow.
System.InvalidOperationException: Incomplete closure You will need to How to Restart a Project Workflow.
detected while loading subroutines for workflow
WORKFLOW_GUID in scope.
If your error is not listed or you want further details about the error you are getting, see the section How to get the
detailed error message for a SharePoint Workflow.
If you find any other errors that are not listed above, please let us know. There are two ways to contact us, either
through our User Voice forum or by contacting Microsoft support. Please provide us with the following details.
Project Name
Workflow Error Code
Workflow Error
Workflow Created
Workflow ID
Workflow Last Run
Workflow Owner
Failed queue message and timestamp if applicable
How to Resume a SharePoint Workflow

In some cases a workflow may need to be resumed to retry the current step of the workflow.
To resume a SharePoint workflow
2. Click on the project name.
3. Click on the project name from the Quick Launch.
4. Expand the All Workflow Stages section.
5. Click the Additional Workflow Data link.
6. Click the "i" icon beside the Internal Status.
7. Click the Resume this workflow link.
How to Restart a Project Workflow

Restarting a Project workflow will put it back to the start of the workflow. Users will need to advance the workflow
back to it's current stage. Before restarting the Project workflow, you may want to first try resuming the workflow
to retry the current steps. See How to Resume a SharePoint Workflow for steps on how to resume a workflow.
To restart a project workflow
3. From the Project tab, click on Options, then Restart Workflow.
NOTE
The project needs to be checked-in before the workflow can be restarted. For more information about checking in a
project, please see Manually check in projects and resources that are checked out by another user.
4. Click OK
To restart project workflows for a set of projects
1. From Project Web App, click on the gear icon then PWA Settings.
2. Click on Change or Restart Workflows.
3. Choose the Enterprise Project Type from the list for the projects.
4. Select the set of projects that need to have their workflows restarted.
NOTE
Projects need to be checked-in for them to show up in the list. For more information about checking in a project,
please see Manually check in projects and resources that are checked out by another user.
5. Select Restart current workflow for the selected projects.

6. Click OK.
Optionally Project workflows can be programmatically restarted. ProjectWorkflowInstance has two methods to
restart Project Workflows:
RestartWorkflow ()
POST
https://CONTOSO.sharepoint.com/teams/project/PWA/_api/projectserver/projects('PROJECT_GUID')/ProjectWor
kflowInstance/RestartWorkflow ()
RestartWorkflowSkipToStage(stageId)
POST
https://CONTOSO.sharepoint.com/teams/project/PWA/_api/projectserver/projectworkflowinstances('WORKFLO
W_INSTANCE_GUID')/RestartWorkflowSkipToStage('STAGE_GUID')
NOTE
Restarting Project workflows in bulk may cause throttling to occur. To learn more, please see SharePoint 2013 workflow
throttling and performance in SharePoint Online and Project Online.
How to get the detailed error message for a SharePoint Workflow

If the error message provided in the Project Center does not provide enough details for you to troubleshoot the
issue, you may want to review the detailed SharePoint Workflow error message.
To get the detailed error message for a SharePoint Workflow
3. Click on the project name from the Quick Launch.
4. Expand the All Workflow Stages section.
5. Click the Additional Workflow Data link.
6. Click the "i" icon beside the Internal Status to see the detailed error message.
How to get a Custom Field from a Custom Field GUID

2. Click Enterprise Custom Fields and Lookup Tables.
3. Click on a custom field.
4. Scroll to the bottom of the page.
5. Expand the System Identification Data section to review the Custom Field GUID.
How to Review PWA Queue Jobs

In some cases an error will be a result of a failed PWA queue job. PWA provides detailed error messages for failed
queue jobs.
To review PWA queue Jobs
2. Click Manage Queue Jobs.
3. Find the failed queue job related to the workflow error and click on the error for more details.
NOTE
You will need to change the Job History if the workflow error is older then a week for it to show up in the list.
Additional Steps
Workflow Last Run Date is far in the past for an active project
The project may be checked out in another session and the workflow is unable to progress until the project is
checked in. The admin may want to consider force checking in the project to allow the workflow to progress. For
more information about checking in a project, please see Manually check in projects and resources that are checked
out by another user.
NOTE
Workflow Last Run Date is referred to Last Submitted Date in the Project Service OData and Project Service REST API.
Best practices for creating phases and stages
Phases and stages are an important part of using workflow in Project Web App. This article presents some best
practices for creating phases and stages. If you're just starting out with Project Web App workflow, chick out Using
workflow for demand management in Project Online first.
You can name your demand management phases and stages any way you'd like, but using the following guidelines
can save you time as an administrator and make things easier to find.
For each phase or stage that you create in Project Web App, we recommend using specific naming conventions.
We also recommend that you create unique phases and stages for each enterprise project type. These conventions
can provide easier maintenance as you expand your usage of demand management features.
For phases:
Create unique phases for each workflow and prefix the phase with an acronym that categorizes the
workflow (for example, IT).
Add a number after the acronym so that phases appear in chronological order.
The following table shows an example of how you might name the phases of IT projects.
PHASE NAME DESCRIPTION
IT-1 Create Create phase for IT projects.
IT-2 Select Select phase for IT projects.
IT-3 Plan Plan phase for IT projects.
IT-4 Manage Manage phase for IT projects.
IT-5 Finish Finish phase for IT projects.
For stages:
Add the appropriate acronym and a number before the title of the stage to cause the stages to appear
chronologically.
Create unique stages for each workflow. This allows you to make changes to a stage in one workflow
without affecting other workflows.
The following table shows an example of how you might name the stages of IT projects.
STAGE NAME DESCRIPTION
IT-1 Propose idea Propose idea stage for IT projects.
IT-2 Initial review Initial review stage for IT projects.
IT-3 Complete request Complete request stage for IT projects.

STAGE NAME DESCRIPTION
IT-4 Request review Request review stage for IT projects.
IT-5 Portfolio selection Portfolio selection stage for IT projects.

Project Online offers two security management options for controlling the kind of access that users have to sites
and projects:
SharePointPermission Mode With this option selected, a special set of SharePoint security groups are
created in sites associated with Project Online. These groups are used to grant users varying levels of access
to projects and Project Online functionality.
TIP
To learn more about the permissions included in the security groups used with SharePoint Permission Mode, see
SharePoint Permissions Mode default permissions for Project Server 2013 SharePoint groups. While this article is
written with Project Server 2013 in mind, the information also applies to Project Online.
Project Permission Mode With this option selected, Project Online provides a set of customizable security
groups and other functionality that is distinct from SharePoint groups.
Project Online uses SharePoint Permission Mode, by default. This mode is more streamlined, enabling you to
implement security quickly and consistently across SharePoint Online and Project Online. However, there may be
situations where it makes more sense to use Project Permission Mode. For example, if you think your organization
needs to manage access based on the RBS structure, you'll need to use Project Permission Mode. This mode offers
greater control, because you can customize and change individual permissions for each security group and
typically intended for larger PMO organizations with a requirement to have more granular access control and has
in-house expertise (or has engaged with a partner) to help with the implementation.
Site collection administrators have administrative permissions to the Project Online site. These
permissions allow the site collection administrator to bypass any Project Online security permissions set in
SharePointPermission Mode or Project Permission Mode. This way, someone always has access to Project Online.
What should I do if my Project Online administrator gets locked out?
Cau t i on
Switching between SharePoint Permission Mode and Project Permission Mode deletes all security-related settings.
If you switch from SharePoint Permission Mode to Project Permission Mode, you have to manually configure your
security permissions structure in Project Online. Switching from Project Permission Mode back to SharePoint
Permission Mode deletes your security permissions information from Project Online.
To change between permission modes:
1. Go to the the Project Web App site collection as the Project Web App Administrator
2. On the Project Web App site, click the Settings icon in the top right corner then click PWA Settings
3. Under the Operational Policies heading, click Additonal Server Settings
4. In the Permission Management section choose the permission mode that you want and then click Save
Plan SharePoint groups in Project Online
In Project Online, SharePoint Permission Mode creates SharePoint groups that directly correspond to the default
security groups found in Project Permission Mode.
TIP
Need to switch between security modes? Take a look at Change permission management in Project Online.
What groups are available?

The following list describes the SharePoint groups and what they'll allow users to do in Project Online.
Administrators Users have all global permissions as well as category permissions through the My
Organization category. This allows them complete access to everything in Project Online.
Portfolio Viewers Users have permissions to view Project Online data. This group is intended for high-
level users who need visibility into projects but are not themselves assigned project tasks.
Project Managers Users have permissions to create and manage projects. This group is intended for
project owners who assign tasks to resources.
Portfolio Managers Users have assorted project-creation and team-building permissions. This group is
intended for high-level managers of groups of projects.
Resource Managers Users have most global and category-level resource permissions. This group is
intended for users who manage and assign resources and edit resource data.
Team Leads Users have limited permissions around task creation and status reports. This group is
intended for persons in a lead capacity that do not have regular assignments on a project.
Team Members Users have general permissions for using Project Online, but limited project-level
permissions. This group is intended to give everyone basic access to Project Online.
These SharePoint groups have the same global and category permissions that are assigned to them in Project
Permission Mode. In SharePoint Permission Mode, you cannot create additional custom groups, categories,
Resource Breakdown Structure (RBS ) nodes, or edit the default permissions assigned to any of these objects.
There are two methods of adding users to the SharePoint groups: adding individual users, or using Active
Directory groups to add users. You can use one or both of these methods for each group.
Adding individual users to SharePoint groups

When you add individual users to one of the SharePoint groups, that user is synchronized to Project Online
automatically. User synchronization runs every ten minutes.
Using Active Directory groups to add users to SharePoint groups

When you add Active Directory groups to one of the SharePoint security groups, the users are not automatically
added to the list of users in Project Online. Each user is individually added the first time she or he accesses Project
Online.
Because users in Active Directory groups do not appear on the list of resources until they have accessed Project
Online, we recommend that you configure Active Directory synchronization in Project Online to prepopulate your
resource list. This allows you to have a complete resource list and to assign work to resources before they have
accessed Project Online.
Using Project Online with external users
In Project Online, a Project Web App site is a site collection within SharePoint Online and sharing a Project Web
App site with external users works the same as sharing any other SharePoint Online site. In this article, we cover
the options for external sharing that are relevant to Project Web App in Project Online, along with licensing
implications for giving your external users access to Project Web App features in Project Online. We also
encourage you to read about how to manage external sharing for your SharePoint Online environment.
Once a Project Web App site has been shared with an external user, the user can collaborate through documents
and lists in that site, including risks and issues. Any interaction on a Project Site requires a Project Online license.
NOTE
For more information about Project Online license considerations for external users, see the Project Online Service
Description.
Managing licenses and permissions for external users is the same as for internal users. (To find the external users in
your user list, look for users with #EXT# in the user name.)
Plan sharing Project Web App with external users

There are two options for sharing your Project Web App site in Project Online. You can pre-populate your Office
365 directory with the users with whom you want to share the site, or you can send sharing invitations to users
directly from your Project Web App site.
Pre-populating your directory
You can pre-populate your Office 365 directory with external users, such as by using Azure Active Directory B2B
collaboration or by adding users manually and changing the user type to Guest. There are several advantages to
doing this:
When you configure sharing for your Project Web App site, you can choose the Allow sharing only with
the external users that already exist in your organizations's directory option. This gives you a greater
level of control over sharing the site by limiting the scope of who can be invited to the site.
If you import a list of users into your directory all at once, you can automatically add them to security
groups and use these security groups to control site permissions for the various Project Web App roles, such
as project manager, team member, and so on.
You can assign licenses to the imported users before sending them the link to the Project Web App site so
they have the proper access when they log into Project Web App.
Adding users as you go
If you choose not to pre-populate your directory, you can choose the Allow external users who accept sharing
invitations and sign in as authenticated users option when you configure sharing for the site.
The advantage of this method is that the site can be easily shared with anyone who has an Office 365 or Microsoft
account. You can invite new users whenever you need to by clicking Share on the Project Web App site. Users who
accept invitations are added to your Office 365 directory and you can manage them there.
One thing to note in using this method is that invited users aren't added to your Office 365 directory until they
accept the sharing invitation, and they must be in your directory before you can assign them a Project Online
license. Because of this, they will not have full access to the Project Web App site when they first receive the
invitation. They can still work with documents, issues, and risks, but won't be able to manage projects or work with
time sheets until they have a Project Online license.
Choosing a sharing method
You can use either of the above sharing methods, or you can use a combination of the two. You can pre-populate
your directory with an initial list of users, then invite more later. The important thing is to choose the sharing option
that's best for you.
The Allow sharing only with the external users that already exist in your organizations's directory option
is more restrictive and allows you greater control over who can be invited to the site. To use this option, you must
pre-populate your directory with the users who you want to invite to the site.
The Allow external users who accept sharing invitations and sign Office 365in as authenticated users
option is the most versatile and allows you to send invitations to anyone with an or Microsoft account. You can still
pre-populate users in your directory with this option, but it's not required.
Configure sharing for Project Web App

Use the following procedure to configure sharing for your Project Web App site in Project Online. Be sure that
sharing is enabled at the tenant level before you proceed.
To configure sharing for Project Web App
1. In the SharePoint Online admin center, in the site collections area, select the check box for the Project Web
App site that you want to share.
2. In the ribbon, click Sharing.
3. Select the option that you want to use for sharing:
Allow sharing only with the external users that already exist in your organizations's directory if
you want to share only with users that you've imported from another directory or tenant.
Allow external users who accept sharing invitations and sign in as authenticated users if you want
to be able to send invitations to users with a Microsoft or Office 365 account.
4. Click Save.
Once you've configured the sharing options for your Project Web App site and added users to your Office 365
directory if needed, you can invite external users to the site by using the Share button on the site in the same way
that you would invite internal users.
Understanding identity management in Project
Online
Before you start using Project Online, one of the most important decisions that you have to make is how you want
to manage your Project Online user accounts.
Options for user accounts in Project Online

Project Online uses the user accounts that you set up for Office 365.
There are two ways to set up user accounts in Office 365:
You can add accounts for each user yourself or import users from a list, such as an Excel workbook.
You can synchronize the accounts that you already have in Active Directory Domain Services (AD DS ) with
Office 365.
While synchronizing your Active Directory accounts requires some additional configuration, the advantage
of doing so is that users only have one username and one password that works with both your local network
and Office 365. This makes account maintenance much easier and gives your users a more seamless and
friendly experience.
If you choose to synchronize your accounts with Active Directory, it's very important that you do that before
you give your users access to Office 365 or Project Online. If you add accounts to Office 365 manually, and
then later decide to synchronize your accounts with Active Directory, then you can end up with two accounts
for each user in Office 365. In Project Online, where you're assigning resources to tasks and managing your
projects, you'll end up with duplicate resources. You won't be able to delete the old accounts in favor of the
new accounts, because the old accounts will be associated with project and time reporting data.
Here's an example:
You subscribe to Office 365 with Project Online and use your company name, Contoso, when you sign up.
Your Office 365 domain is then contoso.onmicrosoft.com. You then add an account for Robyn Buckley, one
of your users. Her account in Office 365 is robynb@contoso.onmicrosoft.com; while her Active Directory
account on the Contoso network is robyn@contoso.com.
If you later synchronize your Active Directory accounts to Office 365, both
robynb@contoso.onmicrosoft.com and robyn@contoso.com will exist in Office 365. Robyn can log into
either account, and each appears as a separate resource in Project Online.
Synchronize your users first
If you use Active Directory Domain Services as part of your company's network, we highly recommend
synchronizing your Active Directory accounts with Office 365. This will be much easier to manage in the
long run and will help reduce your help desk costs and improve user satisfaction.
To learn how to synchronize your users, see Office 365 integration with on-premises environments.
What should I do if my Project Online administrator
gets locked out?
Locked out? Don't panic. The site collection administrator for your Project Online site automatically has
administrative permissions, and can get the Project Online administrator back in.
Step 1: Try to figure out what happened

You might know exactly what happened to get the Project Online administrator account locked out. If so, you've
tackled the first hurdle. If you're not sure, think through your last several actions in Project Online prior to the
lockout.
While logged on as the Project Online administrator, you may have:
Removed everyone from the Administrators group in Project Online, including the default
administrator Active Directory group, and then saved changes.
Set up Active Directory sync to control who has access to Project Online, without being a member of
the selected Active Directory group.
Synchronized an Active Directory group in the Resource Center while your account was already listed
as a resource. When the synchronization occurred, your Project Online administrator account was made
inactive as it was not part of the Active Directory group.
These are just a few examples of things that may have happened. Your situation may be different, and your site
collection administrator will have an easier time getting you back in if you can narrow down what may have caused
the lockout.
Step 2: Find your site collection administrator

Your organization may have a global (tenant) administrator for all of Office 365, a SharePoint Online administrator,
a site collection administrator, and a Project Online administrator. One person may be filling all of those roles, or
you may have multiple people filling each one. To figure out who your Project Online site collection administrator
is, you'll need to try to identify someone in either the global administrator or SharePoint Online administrator
roles. Then, that person can look into who is managing the specific site collection for Project Online.
If you're having trouble reaching your site collection administrator, or if that person isn't sure how to
help you regain access to Project Online, the global administrator or SharePoint Online administrator can also
Manage site collection administrators for your Project Online site. As a site collection administrator, you will have
all administrative permissions in Project Online, and you can try to resolve the lockout yourself.
Step 3: Help the site collection administrator get you back in

Once you've found the right person to help you, explain what you think happened that caused the lockout. Some
issues that result in lockout can be resolved by adding the Project Online administrator account to an Active
Directory group. When synchronization happens, you should regain access to Project Online.
If Active Directory changes will resolve the lockout, the site collection administrator won't need a Project Online
license. However, in some cases, logging onto Project Online is required for fixing the issue, and the site collection
administrator will need to be assigned a Project Online license. It's possible that he or she already has one. If not,
have the site collection administrator select his or her account on the Active Users page in the Microsoft 365
admin center, and then choose Edit under Assigned license on the right side of the window to select a Project
Online license.
Don't have enough licenses? If your organization already has all licenses assigned, the site collection
administrator can remove the license from the locked-out Project Online administrator account, and then assign
that license to themselves temporarily. You'll need to pass the license back and forth to test access, so be sure it
gets assigned back to the Project Online administrator once access has been successfully restored.
Tune Project Web App (PWA) performance in Project
Online
The online version of Project Web App is used in several large organizations. The rich set of Project Portfolio
Management (PPM ) capabilities have been used at scale in these large organizations successfully when the
following best practices in this document are followed. This document is updated as new best practices are
discovered.
Although one of the obvious benefits of using a cloud-based service is avoiding having to deal with deployment,
setup, and hardware and software tuning, there are still some steps you can take to ensure your organization gets
the best performance out of Project Web App.
Project Web App offers many configuration and customization settings. Project Web App has been optimized to
work within a set of configurations and customizations. Excessive customization will have a negative performance
impact. This article highlights the performance impact and tradeoffs of some of the most common Project Web
App settings, so you can make informed decisions when it comes to customizing and configuring Project Web App.
This article is part of the Network planning and performance

tuning for Office 365 project.
Office 365 and SharePoint best practices

There is a wealth of information around network planning and performance tuning for SharePoint and Office 365.
All this information is relevant to Project Web App customers and should be consulted in addition to the following
best practices specific to Project Web App.
Project Web App configuration and customization

Many elements of a Project Web App site can be configured and customized, from administrative settings to
permissions, and from collaboration settings to look-and-feel. Let's look at the settings that can potentially have an
impact on the overall performance of your Project Web App site.
We will cover:
Security permissions modes
Enterprise Project Types
Project site configuration
Synchronization mechanisms between Project Online and SharePoint Online
Active Directory Resource Pool sync
Custom Fields and Lookup Tables
UI customization and look-and-feel
Project Detail Pages (PDP ) and workflows
Event Handling
OData and reporting
Project Online quota
(Some of this information applies to Project Server 2013 and Project Server 2016 as well.)
Permission modes: SharePoint or Project

Project Web App has two permission modes. SharePoint permission mode and the classic Project permission
mode. The comparison between both modes can be found on Technet.
By default, PWA sites are provisioned in SharePoint permission mode. By using this mode, you can manage user
authorization via regular SharePoint groups and permissions.
Project permission mode offers a high degree of customizability, but it can come at a price in terms of
performance. If you create hundreds of categories and rely heavily on dynamic permissions via your Resource
Breakdown Structure (RBS ), it might slow down the end-user experience for users who have access to a lot of
content, such as admins and portfolio managers.
NOTE
Switching between SharePoint permission mode and Project permission mode deletes all security-related settings. If you
switch from SharePoint permission mode to Project permission mode, you have to manually configure your security
permissions structure.
Recommendation:
Use the default SharePoint permission mode for better overall performance. If you need to use Project permission
mode, limit your customizations as much as possible.
Enterprise Project Types

An Enterprise Project Types (EPT) represents a wrapper that encapsulates phases, stages, a single workflow, and
Project Detail Pages (PDPs).
EPTs also allow you to define:
Synchronization mechanisms between Project Online and SharePoint Online
Project sites are built on core SharePoint functionality. Creating project sites is not a lightweight process, and
deciding if and when your organization might need project sites can go a long way in improving the overall end-
user experience.
A lot of organizations use Project Web App to collect and rate project proposals before deciding which projects to
fund. If project sites are set to be automatically created the first time a project is published, then all project
proposals, even the ones that don't make the cut, get a project site. These unnecessary sites would have to be
manually cleaned up afterwards.
A better approach, if you decide to use project sites, is either letting the user choose when to create their
collaboration site, or, even better, having it created by a workflow as soon as the project proposal reaches a certain
stage gate.
SharePoint Online currently limits the number of sites that can be created. See SharePoint Online limits for the
number of subsites that can be created for each site collection. Each EPT allows you to specify which site collection
to create new project sites in. This will allow you to create a project site for each project as you can span them
across multiple site collections.
For example, if you have a site collection dedicated to your IT department, you can configure your IT Projects EPT
to create Project sites off of https://contoso.sharepoint.com/sites/IT .
Recommendation:
If your organization uses project sites, select the option to create them on demand rather than automatically. This
speeds up the first publishing experience and avoids creating unnecessary sites and content.
For each EPT, you can configure this option by:
1. In Project Web App Settings, click Enterprise Project Types.
2. Select the EPT to which you need to change the setting.
3. In the EPT settings page, in the Project Site section, select Allow users to choose.
Create project sites in their own site collection by the EPT. Keep the number of project sites in a site collection
below the SharePoint limits.
What do you sync?
Project Web App runs on top of SharePoint. Some features require synchronization between Project Web App and
SharePoint. These synchronizations can be time consuming especially for large and complex organizations and,
depending on your business needs, can sometimes be unnecessary. This article explores all these various
synchronization systems to help you decide which ones you need and which ones you can safely turn off. Some of
these settings are already off by default.
In the following sections, we discuss:
Sync user permissions for your project site
Sync SharePoint Tasks Lists for Enterprise projects
Sync User Permissions
Project Sites provides project teams a space to collaborate, upload documents, and raise issues. When sync user
permissions is turned on, whenever a person is granted or denied a permission to a project, the corresponding
Project site permissions are updated.
This synchronization happens every time the project is published and when there is an impacting change to a
Project User in Active Directory. The tradeoff for the sync convenience is performance. The more users and sites
that need to be synced, the slower the operation, especially if you're:
An organization with many users and complex security permissions
Bulk publishing
Importing or creating multiple projects (with Projects sites)
Updating group memberships that will require a resync of project site permissions
For each EPT, you can define if sync user permissions is turned on.
NOTE
If project sites are created in a different site collection than where the Project Web App site is located (for example,
https://contoso.sharepoint.com/sites/pwa is where Project Web App is located and the EPT is creating project sites in
https://contoso.sharepoint.com/sites/IT), syncing user permissions is not supported.
Recommendation:
We always recommend to disable the Project site permission sync option and strongly recommend that you
disable the Project site permission sync option if the following is true for your deployment:
You have a large number of resources (>1000)
You have a large number of projects which require a Project site (>1000)
You have a large number of resources that need to be granted access to the majority of Project sites
Project sites are created outside of the default site collection (sync is disabled)
Here are some options to consider for managing your Project site permissions:
If your project teams have low turnover, consider turning off Project site permission sync to improve Project
Publish and Project Detail Pages performance. You would then have to manually grant or remove
permission to your Project sites whenever someone joins or leaves a project team.
If access needs to be granted for all users in PWA and it maps to your existing group permissions, consider
configuring your Project sites to inherit from the parent PWA site.
If site access aligns with specific roles, create one or more groups that map to those roles (possibly if you
have Group sync enabled, you can use the same groups) and grant those groups access to the Project site.
For each EPT, you can turn off Sync User Permissions:
3. In the EPT settings page, in the Synchronize section, ensure that the User Permission Sync option is
unchecked.
Sync SharePoint Tasks Lists for Enterprise projects
Sync SharePoint Tasks Lists is turned off by default to improve the speed of project publishing. This also helps
speed the transition between Project Detail Pages. If your users rely on the task list and its timeline visualization in
the Project site, you can turn this feature on and check if its impact on the performance of project publishing is
reasonable.
NOTE
If project sites are created in a different site collection than where the Project Web App site is located (for example,
https://contoso.sharepoint.com/sites/pwa is where Project Web App is located and the EPT is creating project sites in
https://contoso.sharepoint.com/sites/IT), syncing SharePoint Tasks Lists is not supported.
Recommendation
The Sync SharePoint Task Lists option was intended for use with small project plans. If the project has a large
number of tasks, syncing them on publish will take some time as each task needs to be updated one at a time. For
example, it takes several minutes to sync a 500 task project plan to the SharePoint task list. Even though the queue
job is on a separate correlation and does not block saving and editing of the project plan, we recommend not
enabling the Sync SharePoint Task Lists option. We recommend only syncing projects with less than 250 tasks.
This option is turned off by default. Only turn SharePoint Tasks Lists sync on if your users need the feature for each
EPT. To configure this option:
3. In the EPT settings page, in the Synchronize section, select Sync SharePoint Tasks Lists.
Active Directory Resource Pool sync

Active Directory Resource Pool sync by itself does not have particular performance issues and can import
thousands of resources into your Project Web App instance in minutes. However, its downstream effect on other
parts of the system can impact performance. The primary process to keep an eye on is the resource permission
sync previously mentioned. If there is large turnover in your Active Directory groups membership, and that
requires you to sync your Resource Pool often, monitor any potential downstream effects on related permission
sync jobs.
Recommendation:
Limit Active Directory sync to groups of resources that actually need to use the system, and monitor any potential
permission issues after the synchronization of large groups. (To configure Active Directory Enterprise Resource
Pool Synchronization, in Project Web App Settings, click Active Directory Resource Pool Synchronization.
Custom Fields and Lookup Tables

Project Online limits and boundaries document lists a high threshold in the number of custom fields and lookup
tables allowed in a PWA instance, careful consideration needs to be given during the planning and customization
of the site in regards to the number of custom fields, associated lookup tables and entries. Excessive customization
in this area will have performance implications.
Performance tradeoff
The following operations can be impacted if a PWA site has many custom fields and lookup tables and the lookup
tables are large: Saving Projects
Publishing projects
Rendering PDP pages with custom fields
Querying OData to generate reports
Recommendation:
Limit the number of custom fields and lookup tables
Pay attention to the design of your custom field formulas – avoid formulas that have dependencies on fields
that change regularly, which leads to larger changes, resulting in longer save and publish actions.
Keep lookup tables small – most custom lookup tables have less than 20 values and that’s a good range to
stay in. Lookup tables with hundreds or thousands of values adds extra overhead especially in the retrieval
of OData reports.
PWA pages and views customizations

Page customizations
The SharePoint platform offers great customization capabilities with its modular webpart infrastructure and
support for custom pages. When you add logos, custom webparts, and new themes, it might not have a significant
impact on performance on an on-premises infrastructure due to the benefits of server proximity, low latency, and
high bandwidth networks. However, on an online service, the story is different.
When you upload a logo or graphic with a large file size, it might slow down pages a bit on an on-premises
deployment, but online, the performance hit on page loads is substantial.
The same principle applies when you add multiple webparts to a page. It might be tempting to have a custom page
with multiple webparts, but unless users actually need to see the data side by side, it is better to have separate
specialized pages than having it all in one place. If users only need the content of one webpart on the page, they
still have to wait longer for the page to load and display the data for all the other webparts.
Recommendation:
When you customize pages, treat your Project Online site as any regular Internet website, and create lightweight
pages as much as possible.
Views customizations
Here again, simplicity goes a long way to improving page load performance. Organizations can create custom
views by using multiple Project Web App pages, including Project Center, Resource Center, Tasks, and Timesheets.
The more content is displayed, the slower page rendering will be. You can reduce each page load time by a few
seconds if you provide users with a greater number of simple and targeted views rather than a few "all-in-one"
views.
In the examples below, the second view takes an average of 2 to 3 seconds less to load than the first one.
Recommendation:
When you configure views, offer users simple specialized views for faster navigation rather than a complex all-in-
one view that would load unnecessary data most of the time.
User View Settings
Project Center: Group by with Rollups
Users can configure different ways to have the view rendered to them including having data grouped by different
fields. When using group by, data can be rolled up for supported aggregation fields (for example, summing costs
or a custom field). Computing these aggregate values requests the service to load up all the values in order to
display the total.
Recommendation:
Unless the user needs to see the rolled up values, disable the Rollup option in the ribbon.
Project Center: Gantt Chart

The chart portion of the Gantt Chart view displays each project as a summary Gantt bar.
Recommendation:
Unless the user needs to see the Gantt, disable the Gantt Chart option in the ribbon.
Custom Project Detail Pages and Workflows

In addition to the recommendation provided above for page design, Project Detail Pages (PDPs) are particular in
that they can trigger a recalculation of the entire project and kick off workflow actions, both of which can be
expensive operations in terms of performance, depending on your customizations.
Project Online and Project Server have two main update processes for project information:
Updates requiring a scheduling recalculation (see list below )
Nonschedule-related fields, such as project name, description, and owner.
We recommend that you avoid updating both types of data on the same PDP to avoid triggering both update
processes at the same time.
Here is a list of the most common actions that require a schedule recalculation.
Project calendar changes
Changes to the following date fields:
Start date
Finish date
Status date
Current date
Changes in project custom fields
If the project has any dependencies on deliverables
A second way to improve PDP performance is to reduce the number of webparts and custom fields displayed on
each PDP. If your business processes require frequent updates to the same set of fields, create a dedicated PDP
with only these fields to improve load and save time. Displaying all custom fields at all times results in a lot of
unnecessary overhead.
Recommendation:
Create lightweight specialized PDPs, and avoid mixing schedule-related and nonschedule-related updates.
Bulk custom fields updates in workflows with new REST API
Updating project custom fields values in a workflow one at a time requires a separate server request using the Set
Project Field action. This results in reduced performance when updating a lot of custom fields at the same time on
a high-latency, low -bandwidth network.
To solve this issue, there is a CSOM method to update custom fields in bulk. This method requires you to pass in a
dictionary containing the name and values of all the custom fields you want to update.
API for provisioning project sites on-demand
Each project can have its own dedicated SharePoint site where team members can collaborate, share documents,
and raise issues. These sites can be automatically created on first publish or manually created by the project
manager via Project Pro or the administrator via Project Web App settings, or they can simply be disabled.
You can use the CreateProjectSite('') method to decide when to create their project sites. This is particularly useful
for organizations who want to create their sites only after a project proposal reaches a specific stage in a
predefined workflow, rather than on first publish. This significantly improves the performance of project creation
by postponing the creation of Project sites.
Event Handling
Add-ins can respond to events being raised in Project Online. For example, an add-in can perform some additional
activity after a project has been created. Users may have to wait for these add-ins to complete handling the events
before they can continue working with Project Online.
Recommendation:
Project Online should be configured to handle certain events asynchronously to minimize the amount of time
users will need to wait. To do this, ask the developer of any add-ins you use to make sure their code is able to
handle After events asynchronously. They can go to this article to learn more about practices they can follow for
handling these events.
If the developer confirms the add-in is ready for the change, you then need to enable the Turn on asynchronous
After event processing setting on your PWA Settings page.
1. On your PWA Settings page, in the Operational Policies section, select Additional Server Settings.
2. In the Asynchronous event handling for After events section, make sure that Turn on asynchronous
After event processing is selected.
3. Select Save.
You'll then need to test your instances to verify that everything works correctly.
NOTE
This feature is being introduced gradually to Office 365. This means that you may not currently have this setting available.
OData and Reporting

Reporting
In Project Online you can choose the granularity of time phased reporting data - or you can choose Never if you
do not need time phased reporting data. This feature is fully documented in Configure rollup of timephased
reporting data in Project Online. Choosing an option that uses the least amount of data that satisfies your
reporting needs means that reports will generate quicker, you may be able to use different reporting options as
you will have a smaller dataset and you will also benefit from faster publishing of projects. The list of options in
order of most benefit to performance are:
Never
Fiscal Periods
Monthly
Weekly
Daily
Fiscal Periods has the big advantage over Monthly in that reporting data is only held for defined Fiscal Periods,
whereas Monthly will hold data for the full duration across all of your projects.
By using the Project OData service, you can extract information from your Project Online instance for reporting.
Recommendation:
Store the least amount of timephased data that is consistent with your business needs. Do not use Daily if you
have workflows that wait on publish to complete.
PowerBI
If the amount of data is small, then Power BI can regularly read data from the Project OData service and help
provide a variety of dynamics reports. A sample content pack can be found here.
If the amount of data in Project Online is large, you can still bring in a subset of the data as long as it meets the
PowerBI data size limits outlined here. Another option is to create your reports in a moving window, i.e. filtering
projects who were active in the last 30 days or viewing resource capacity for the next 6 months.
SQL Server Integration Services (SSIS)
Using SSIS, data can be extracted from the Project OData service and can download your reporting data into a
SQL server database locally or in Microsoft Azure. A sample SSIS package for the Project OData service can be
found here.
Recommendation:
If your reporting needs still require you to extract a large amount of data, consider using the SQL Server
Integration Services (SSIS ) package to copy your reporting data into a SQL server database locally or in Microsoft
Azure.
When using SSIS, please consider the following steps:
Full Sync
Get a current snapshot of the reporting data you are interested in.
1. Record current date/time as sync time
2. Download data from each endpoint.
NOTE
Project Online is optimized to only retrieve the data you are requesting so include the fields you require. Avoid downloading
all the columns if they are not needed.
Delta Sync
Check periodically to keep your copy up to date.
1. Record current date time.
2. Query ProjectId From Projects endpoint.
3. Delete local Projects where the ProjectId no longer exists.
4. Query each endpoint by Project:
5. Query the entity Ids.
6. Delete local entities where the Ids no longer exists.
7. Query for mod_dates that has changed since you last synced.
NOTE
As mentioned earlier Project Online is optimized to only retrieve the data you are requesting so include the fields you require.
Avoid downloading all the columns if they are not needed.
Custom Fields
When retrieving data from the OData endpoint, extra computation is required when using custom fields which are
multi-value lookups. The extra computation does not allow the OData endpoint to take advantage of a number of
optimizations.
Recommendation
Do not use multi-value lookup custom fields.
Querying OData
There are limits to the number of entities that can be returned in one query of the ProjectData service. As a result,
querying a large amount of data requires multiple web requests to be sent to the service, adding network
overhead and latency for each request.
Avoid performing full “refresh everything” data loads. These refreshes can impact performance of the PWA site
especially during peak use times leading to overall performance degradation of user operations in PWA or
throttling.
Recommendation
Perform Odata refresh actions after hours. Decisions to maintain real time or close to real reports should also take
into consideration the performance tradeoffs to the user experience in the PWA site.
For a Project Web App instance that contains a large number of entities, such as projects, assignments, or tasks,
you should limit the data returned in at least one of the following ways. If you don't limit the data returned, the
query can exceed the default limits and affect server performance.
Use a $filter URL option, or use $select to limit the data. For example, the following query filters by
project start date and returns only four fields, in order of the project name:
http://ServerName/ProjectServerName/_api/ProjectData/Projects?$filter=ProjectStartDate gt datetime'2012-
01-
01T00:00:00'&$orderby=ProjectName&$select=ProjectName,ProjectStartDate,ProjectFinishDate,Project
Cost
Get an entity collection by using an association. For example, the following query internally uses the
Project_Assignments_Assignment_Project association to get all of the assignments in a specific project:
http://ServerName/ProjectServerName/_api/ProjectData/Projects(guid'263fc8d7-427c-e111-92fc-
00155d3ba208')/Assignments
Do multiple queries to return data one page at a time, by using the $top operator and the $skip
operator in a loop. For example, the following query gets issues 11 through 20 for all projects, in order of
the resource who is assigned to the issue:
http://ServerName/ProjectServerName/_api/ProjectData/Issues?
$skip=10&$top=10&$orderby=AssignedToResource
Recommendation:
Limit the amount of data you query at runtime by using server-side filtering to retrieve only the columns
that you need. The impact of this is most noticeable with custom fields. Add it only if you really need it.
Ensure that you are filtering on the entity key. The entity key is indexed and will offer a much more
performant data retrieval experience. You can find the key(s) for each entity by reviewing the Service
Metadata Document in your PWA instance: http://ServerName/sites/PWA/_api/ProjectData/$metadata
Project Web App Quota

By default, the Project Web App Site comes with a 25GB limit and is separate from the limit on all data stored in
the SharePoint site collection where Project Web App is enabled. Using the reporting granularity options to reduce
your data volume can help in staying within the quota.
Note: For large customers, quota can be increased, but we would also expect customers to have considered the
reporting granularity options to limit data volume. To increase your quota, please contact Microsoft.
Conclusion
Project Online, like any cloud service running on the Internet, requires specific tuning to deliver the best
performance compared with an on-premises deployment.
Although we are constantly improving the system to speed up performance, there are some steps you can take in
the meantime to provide a good experience to your end users.
Summary recommendation:
Use SharePoint permission mode when possible.
Only turn on the features you will actually use.
Keep pages and customization as simple and lightweight as possible for faster page load times.
Use server-side filtering or export Odata feeds data to a SQL Server database for more reporting flexibility.
Choose a reporting granularity option that uses the least amount of data that satisfies your reporting needs.
Related Topics
There are some important limitations that you should know if you are using Project Online. These limitations
apply regardless of whether you are using Project Online by itself, or with other Office 365 plans.
TIP
Want more info about Project Online and Office 365 plans? Take a look at the service descriptions for Project Online
and Office 365.
Limits in Project Online

To keep Project Online performing at its best, there are some limits to how much data you can realistically store:
30,000 projects per Project Web App site.
The project sites for these projects must not exceed 2000 sites in any one site collection - and for best
performance with large numbers of projects aim to have none of the project sites in the PWA site
collection itself.
Initial quota of 25GB per Project Web App site. Please see Tune Project Online performance for more
information.
NOTE
The 25GB limit for each Project Online database is separate from the SharePoint Online limits where Project Web App
is enabled.
For reporting, there are also limits to how many single-value custom fields, of each type, get stored in the
reporting schema.
TASK AND RESOURCE CUSTOM FIELDS,

PROJECT CUSTOM FIELDS TIMESHEET CUSTOM FIELDS COMBINED
450 text fields 450 text fields 450 text fields
450 lookup tables 450 lookup tables 450 lookup tables
450 of all other custom field types 450 of all other custom field types (cost, 450 of all other custom field types (cost,
(cost, date, duration, number, flag) date, duration, number, flag) date, duration, number, flag)
NOTE
While you can create more custom fields than these limits, only this many custom fields will be included in the OData feed.
You are not able to choose which of the fields are included.
Also for reporting, if an individual report's source Excel file is larger than 10MB, it cannot be refreshed in Excel.
Instead, you can:
Refresh the report using Excel 2013.
Consider getting Power BI to extend that 10MB limit and refresh the report in Excel.
File size limits for workbooks in SharePoint Online.
Determining your PWA site usage
An admin can check how much of your 25GB quota your PWA site is currently using through your PWA Settings.
1. Where to sign in to Office 365 for business with your admin account and go to Project Online.
2. In Project Online, click the Settings icon, and select PWA Settings.
3. On the PWA Settings page, in the Operational Policies section, select Additional Server Settings.
4. In the Project Web App usage section, it will show your current Project Web App size in relation to your
quota.
For example: Project Web App size - Using 11MB of 25600MB available.
NOTE
You need to be a Site Collection Admin for the PWA site in order to view the PWA site usage settings on the Additional
Server Settings page.
Other considerations
Beyond the data and custom field limits, there are a couple of other variables to consider.
Changing domains is not supported
If you want to use your own domain, like contoso.com, instead of the default domain, like
contoso.onmicrosoft.com, you need to set up your domain before adding users to Project Online. Changing
domains after you've added users is not supported.
Master page customizations
Modifying or changing out the default master page template can result in unexpected rendering or display issues
and is not supported.
Using period symbols in your PWA site collection site address
Period symbols in the site name portion of a PWA site collection site address is not supported. This is configured
when your admin creates a PWA site in the SharePoint admin center.
NOTE
Periods are allowed in PWA site names, but not in the site name portion of the site address.
It takes more time to load more projects

Because it takes more time to load more projects, someone who has access to a lot of projects may find it takes
longer to do some things, like opening the Project Center or changing views in the Resource Center. Consider
setting up filters to cut down on the load time for those users who have access to a large amount of information.
It takes more time to calculate multiple calendars
When a project, task, or resource has its own custom calendar, Project Online takes a little longer to calculate the
dates for the work going on in your organization. Consider whether it makes sense to make some of the calendar
changes on a broader scale, across your entire organization.
Your connection speed matters
If your connection to Project Online is running slowly, it can take a little longer to do things like load reports with a
lot of data, or open, save, and publish a project through the Project Online Desktop Client.
Related Topics
Tune Project Online performance
Best practices to improve Resource Engagements
performance
In Project Online, resource managers and project managers can negotiate an agreement, called a Overview:
Resource engagements, to make sure that resources are being used appropriately and effectively throughout your
organization. This article describes ways that resource managers can improve performance, such as reduced page
load times and less timeout errors, when using Resource Engagements.
Why is my Resource Requests page taking so long to display?

When you click Resource Request in the ribbon of the Resource Center, it will bring up resource requests for all
selected resources in the Resource Center. If all resources are selected in the Resource Center, resource requests for
all resources in your Project Online tenant will attempt to load to the Resource Request page. Depending on the
number of resources and their requests, this may cause delays and timeouts in loading data to the page.
** So what should I do? ** To improve performance, you should try to display resource requests for resources you
are interested in as opposed to all resources in your organization. In most cases, resource managers only want to
view resource requests for a small subset of resources, such as the resources that are assigned to them. In this case,
a resource manager could simply select these individual resources on the Resource Center before going to the
Resource Request page.
Can I create a view to show only the resources that I own?

While you can manually select your resources as noted above, resource managers can also easily create a Resource
Center view that displays only resources that they manage. This would eliminate the need to find and select your
resources each time you go to the Resource Center. For example, you could create a Resource Center custom view
(" Resources I own ") that displays all of the resources that you manage.
To create a view that displays resource you own
1. In Project Online, in the Quick Start, click Server Settings.
2. On the Server Settings page, in the Look and Feel section, click Manage Views.
3. On the Manage Views page, click New View.
4. On the New View page, in the Name and Type section:
In the View Type drop-down, select Resource Center.
In the Name field, enter a name for the view (for example, Resources I own ).
In the Description field, enter a short description of this view.
5. In the Table and Fields section, select the fields you want to display in the view and Add them to the
Displayed fields list.
6. In the Format View section, use the Grouping controls to choose how the items will display the view.
7. In the Filter section, click Filter to display the Custom Filter control.
In the Field Name drop-down, select Resource Name.
In the Test drop-down, select equals.
In the Value box, type the exact name of the resource that is assigned to you.
Click OR.
Repeat this process to add the remaining resources that are assigned to you.
Click OK.
8. On the New View page, click Save.

After creating the custom view, you can select it from the View menu in the Resource ribbon in the Resource
Center. After selecting it, the Resource Center should display the resources you entered in the custom filter when
you created the view.
Clicking the Resource Request button in the Resource ribbon will then find the resource requests for only these
specific resources.
Project Online will by default use your custom view when you navigate away and return to the page - you will not
have to re-select it the next time you return to the Resource Center.
How can I show only proposed resource requests for my resources?
Now that you know that you can improve performance by filtering for only the resources you are concerned with,
you can improve it even more by filtering for resource requests that you need to address.
The Resource Request page will by default display resource requests in all states , including those that have already
been committed and accepted. As a resource manager, you may mostly want to view resource requests that are in a
proposed state. If this is the case, you can create a Resource Requests view that filters for only proposed resource
requests. This can help with performance as it eliminates the need to load the Resource Requests page with
resource requests you've already addressed in the past, which could amount to a lot of data.
To create a view that only displays proposed resource requests:
1. In Project Online, in the Quick Start, click Server Settings.
2. On the Server Settings page, in the Look and Feel section, click Manage Views.
3. On the Manage Views page, click New View.
4. On the New View page, in the Name and Type section:
In the View Type drop-down, select Resource Requests.
In the Name field, enter a name for the view (for example, Proposed ).
In the Description field, enter a short description of this view.
5. In the Table and Fields section, select the fields you want to display in the view and Add them to the
Displayed fields list.
6. In the Format View section, use the Grouping controls to choose how the items will display the view.
7. In the Filter section, click Filter to display the Custom Filter control.
In the Field Name drop-down, select State.
In the Test drop-down, select equals.
In the Value box, enter Proposed.
Click OK.
8. On the New View page, click Save.

After creating the custom view, you can select it from the View menu in the Engagements ribbon in the Resource
Requests page. After selecting it, the Resource Requests page should only display resource requests in a proposed
state for your resources.
Do you really need the Time-Phased data view?

If you don't really need to view your resource requests in Time-Phased view, make sure that Timephased Data is
not selected in the Display section of the Engagements ribbon of the Resource Requests page.
Loading your resource engagements in the Sheet view reduces the amount of data that needs to load to the page,
reducing the amount of time it takes to display your data.
Why aren't some of my resource engagements displaying?

If some of your resource engagements aren't displaying on the Resource Assignments or Resource Requests
pages, it might be because they fall outside of the pages' hard-coded date range filter that removes resource
engagements that either:
Ends at least three months in the past.
Begins at least a year in the future.
Resource engagements will only display for resource requests that fall within these time periods. The only
exception to that will be for resource requests that are in a Proposed state.
Portfolio analysis in the Microsoft Project Web
Application
Summary: Learn what a project portfolio analysis is and how to get started doing portfolio analyses in Project
Web App.
Applies to: Project Online, Project Server 2016, Project Server 2013
One of the most commonly asked questions in project management is, "Are we delivering the right projects?" The
portfolio analysis module in PWA is designed to help organizations answer that question. The portfolio analysis
module answers that question by performing the following functions:
Centralizing a list of requested projects or proposals.
Developing a list of the estimated costs required to deliver those projects.
Developing a list of the estimated resources required to deliver those projects.
Providing several methods to prioritize the list of requested projects or proposals.
Providing the organization with the ability to explore the various dimensions of the project portfolio.
These features may be combined to create specific scenarios. For example, one scenario may assume annual
funding levels of $20,000,000. Other scenarios may assume funding levels of $10,000,000. Some scenarios may
prioritize growth. Other scenarios may prioritize risk mitigation.
The process of assessing these scenarios and defining an optimal selection of projects is known as portfolio
analysis. Portfolio analysis is a core feature in the Project Web Application, and is available in Project Online and
supported versions of Project Server.
The portfolio of projects and ideas

The project portfolio is defined as a centralized list of projects and proposals. This portfolio is managed to deliver
specific organizational goals. Within PWA, a project portfolio should be defined as a set of projects that share the
same cost or resource constraints.
Cost and resource estimates may be attached to the project portfolio. These become the demand profile that is
input into the portfolio analysis exercise.
The portfolio of resources
Resources are collected into a portfolio of resources. Within PWA, this resource portfolio is referred to as the
resource pool. The resource pool represents the available resources that can be called upon to deliver the portfolio
of projects and ideas.
Members of the resource pool may be assigned specific values to support the portfolio analysis exercise. For
example, resources may be assigned to specific departments, skill sets, languages, etc. These attributes generally
map to the different portfolios of work defined in the project portfolio.
Project prioritization
PWA provides two methods of prioritizing the project portfolio:
Business drivers
Enterprise custom fields
Business drivers are a definition of the goals of the organization. Each project or idea within the project portfolio
may be assessed against each of the business drivers. This will yield a prioritization of each project. For more
information on defining business drivers, please click here.
Some organizations choose to use custom fields to perform prioritization. Custom fields support the use of existing
prioritization processes. Custom fields may also be used to support the use of third party decision support tools.
The output of those processes and tools may be entered in custom fields within PWA to support a prioritization
logic aligned with the needs of the organization.
Portfolio analyses
You may use PWA to combine portfolio data to create specific scenarios. These scenarios represent an analysis of
the project portfolio, a portfolio analysis. The scenario will describe the optimal list of projects based on external
constraints such as available funds, resources, and organizational priorities.
The scenario calculations do not impact the project record itself. These are hypothetical scenarios that exist outside
of the main project management environment. When the scenario is committed, specific fields are populated and
the project is moved into the execution stage.
In Project Web App, you can create multiple analyses for a given set of projects and compare them to each other to
help determine the best value for the budget that you have available.
Preparing for portfolio analysis

The following steps are best performed before starting a portfolio analysis.
1. Define your projects and project proposals.
2. Define the key cost elements of these projects (i.e., total cost, capital expense, operational expense, etc.).
3. (Optional) Define the work required to support these projects and project proposals.
4. (Optional) Define the available pool of resources that will be delivering the project portfolio.
5. Define your portfolio prioritization mechanism(s). PWA supports the use of business drivers as well as
manual prioritization methods.
Getting started with portfolio analysis

Here's what you need to do to get started with portfolio analysis in Project Web App:
1. Create a new portfolio analysis within PWA.
2. Prioritize your project portfolio.
3. Review the output of the cost analysis. Identify specific scenarios to explore further. Save those scenarios for
comparison.
4. (Optional) Review the forecast resource commitments.
5. (Optional) Review the output of the resource analysis. Identify specific scenarios to explore further. Save
those scenarios for comparison.
6. Select one portfolio analysis scenario for execution.
7. Commit that portfolio analysis scenario to advance the projects in the execution workflow.
Related Articles
Defining portfolio analysis business drivers
Summary: Learn how to define and configure the portfolio analysis business drivers that support project
prioritization in the Project Web Application.
PWA provides two main features to support the prioritization of the project portfolio:
Business driver-based prioritization
Prioritization based on manually calculated fields
This article will discuss how to define and configure business drivers within PWA. Other articles will discuss how
to prioritize the project portfolio manually using custom fields.
Business drivers are one function in the portfolio analysis feature within the Project Web Application. The portfolio
analysis feature is available in Project Online and supported versions of Project Server.
Business drivers
A business driver is a fundamental goal that your organization is working towards. Some examples of business
drivers may include:
Improve customer satisfaction
Expand market share
Reduce IT costs
Your organization will benefit from business drivers. The process of defining business drivers creates clear
agreement on the organization’s critical business objectives. This enhances the chance that you will have shared
priorities across all of the project portfolio’s stakeholders.
PWA will support the mapping of each project and proposed project to a set of business drivers. This will allow
PWA to calculate the optimal mix of projects based on organizational priorities and constraints.
To get started creating business drivers:

1. Navigate to the Driver Library.
2. Select the New Button on the Driver Tab.
3. Type a name and description for the driver.
4. If this driver is for a specific department, select the department in the Departments box. If you do not
select a department, then the driver will be available to all departments.
5. Fill in descriptions for each project impact statement.
6. On the ribbon, click Save & Close.
Driver description
Enter a description that clearly describes the driver. The description should also provide a suggested measure for
how to assess performance against the driver.
For example, a driver called "Enhance Customer Satisfaction" may be tied to a specific survey that is performed
over time to assess customer satisfaction.
Project impact statements

Impact statements should be measurable. For example, a "Strong" impact on the Enhance Customer Satisfaction
driver may include an increase of 10 percentage points on an annual customer satisfaction survey.
Project impact statements should be written in a positive way that describes a desirable outcome. For example, if
the organization wishes to decrease its exposure to risk, a strong impact statement may be written as, "The project
will reduce our corporate exposure to IT risk by closing at least 2 high profile findings from our last audit."
Once you have created the business drivers that you want to use, the next step is to prioritize them.
Related Articles
Prioritizing portfolio analysis business drivers
Summary: Learn how to prioritize your portfolio analysis business drivers in the Project Web Application.
Applies to: Project Server 2016, Project Server 2013
This article will discuss how to create a set of prioritized business drivers to support portfolio analysis within PWA.
Portfolio analysis
Portfolio analysis is a structured technique to define the optimal collection of projects to be executed. Portfolio
analysis is a core feature in the Project Web Application, and is available in Project Online and supported versions
of Project Server.
Prioritization based on manual prioritization
This article will discuss how to create a set of prioritized business drivers within PWA. Other articles will discuss
how to prioritize the project portfolio manually using custom fields.
This article assumes you have already created business drivers.
Business driver prioritization sets

A set of business drivers is a collection of business drivers that have been prioritized against each other. Your
organization can create multiple sets of prioritized business drivers. This allows you to calculate priorities for
different groups. For example, the Marketing Department may have different priorities than the Accounting
Department. A set of business drivers can be created for the Marketing Department. A different set of business
drivers can be created for the Accounting Department.
Each business driver can be in multiple prioritization sets simultaneously. In the above example, this allows the
Marketing Department to prioritize a business driver such as "Increase market share" differently than the
Accounting Department.
To get started creating a driver prioritization set:
1. Navigate to the Driver Prioritization Screen and click on the New Button on the Prioritization Tab to
create a new prioritization set.
2. Select the drivers to include in the prioritization set.
3. Navigate to the Prioritize Drivers Screen and assign priorities.
4. Navigate to the Review Priorities Screen and assess the calculated driver priorities.
Prioritize drivers
Now that you have created a set of drivers, you can assign relative priorities. You will now prioritize each driver
against each of the other drivers. For example, you may have two drivers:
Driver A: Enhance customer satisfaction.
Driver B: Enhance employee satisfaction.
You must choose as an organization which driver is most important. You may select from the following options:
Driver A is extremely more important than Driver B.
Driver A is much more important than Driver B.
Driver A is more important than Driver B.
Driver A is equally as important as Driver B.
Driver A is less important than Driver B.
Driver A is much less important than Driver B.
Driver A is extremely less important than Driver B.
You will need to prioritize each driver and click on the Next Driver button.
Review priorities
Upon completion of the driver prioritization activity, PWA will calculate a driver priority score.
Note that it is common for organizations to introduce logical errors into the driver prioritization exercise. PWA will
calculate a consistency ratio for all driver prioritizations. The consistency ratio measures how many logical conflicts
may exist in the driver prioritization. For example, the system allows you to perform the following calculations:
Driver A is as important as Driver B.
Driver C is significantly more important than Driver B.
Driver A is more important than Driver C.
In this example, we are saying Driver A is both as important as Driver B and more important than Driver B. The
consistency ratio assesses how many of these logical flaws exist in our prioritization.
A consistency ratio of 80% or higher is generally considered acceptable for most organizations.
You are now ready to create a new portfolio analysis with the business driver prioritization set.
Creating a new portfolio analysis
Summary: Learn how to combine the project portfolio, resource pool, and prioritization mechanism into a single
analysis of the project portfolio using the Project Web Application.
Portfolio analysis is a structured technique to balance identified work requests and available resources. The Project
Web App (PWA) enables portfolio analysis with several features:
Project portfolio definition
Resource pool definition
Planning for a portfolio analysis

The following steps should be performed before starting a portfolio analysis.
1. Define your projects and project proposals.
2. Define the key cost elements of these projects (i.e., total cost, capital expense, operational expense, etc.).
3. (Optional) Define the work required to support these projects and project proposals.
4. (Optional) Define the available pool of resources that will be delivering the project portfolio.
5. Define your portfolio prioritization mechanism(s). PWA supports the use of business drivers as well as
manual prioritization methods.
Create a portfolio analysis
To get started creating a portfolio analysis:

1. In the Project Web App, click on Portfolio Analyses Link in the left navigation menu.
2. Click on the New Button to create a new analysis.
3. Populate the fields per the options in the table below.
4. Configure the project Force-in and Force-out options.
5. Move to the next screen to assign project priorities.
Complete the New Portfolio Analysis Form as follows:
ITEM NOTES
Name Type a descriptive name for this portfolio analysis. For

example, you can call this analysis 2019 Marketing Budgeting
Planning.
Description Type a description for this portfolio analysis.
Department Optional. If you select a department, only custom fields and

resources for that department will be available for the
analysis. If you don't select a department, all fields and
resources will be available.
Prioritization Type Choose whether to use business drivers (recommended) or

custom fields to prioritize your projects. If you choose
business drivers, then choose the prioritization set that you
want to use from the drop-down list.
Prioritize these projects Click Select Projects to choose the projects that you want to
include in this portfolio analysis.
ITEM NOTES
Analysis Primary Cost Constraint Choose the custom field that you want to use for the project's
overall budget.
Resource Planning (optional) Select this check box if you want to include resource planning
in this portfolio analysis. Your projects must include resource
assignments for this to work.
Alias project Force-in and Force-out options Use the options in this section to customize force in/out
options.
If the Resource Planning option is checked, the form will expand with the following fields:
ITEM NOTES
Planning Horizon and Granularity Choose the date range for which resource scheduling
information will be available for the portfolio analysis.
Resource role custom field Choose the custom field that defines the resource's role.
Resource filtering Specify if you want to filter the resources that are available to
this portfolio analysis by department or RBS value.
Resource capacity impact for projects outside the analysis Choose if you want proposed assignments to affect resource
availability in this portfolio.
Project start and finish dates Choose if you want to use the project schedule for project
start and finish dates, or custom fields.
Defining force-in and force-out aliases

Later in this process, you will be able to force projects into and out of the portfolio analysis. For example, an
organization may decide that a project is required to meet newly defined regulatory requirements. That
organization may "force in" the project into the portfolio. Regardless of scenario constraints that project will be
selected.
Similarly, the organization may also "force out" projects from the portfolio. For example, an executive has declared
that we will not do this project as part of the current annual planning. We would then force out the project.
Organizations may define friendly names for these force in/force out options. For example, an organization may
rename "force in" as "regulatory compliance, executive selection, etc."
To rename force in/force out options, the user will need to create a look up table with the new values. That lookup
table may be assigned to the Force In and Force Out options upon creation of the portfolio analysis.
Prioritize projects
If business driver prioritization was selected when the portfolio analysis was created, this screen will display all of
the selected projects against each of the selected business drivers. Some projects may have already been mapped
to business drivers. You can use this screen to confirm that each project has been mapped appropriately.
Visually scan each row to confirm that each project is aligned with at least one business driver. Scan each column
to confirm visually that each business driver is represented appropriately:
No driver is not aligned to a project.
All projects are only aligned to a single driver (i.e., the driver is overrepresented).
Each project may be mapped to a driver according to the following options:
No rating (no mapping)
None
Low
Moderate
Strong
Extreme
This step will calculate the relative priority of each of the projects within the analysis.
Review priorities
The projects are now displayed in the order of the calculated priority. The overall value of the portfolio is
calculated as 100%. Each of the projects represent a fraction of the 100% portfolio value.
The portfolio analysis process will help you determine the maximum value that can be delivered for the available
financial and resource investments.
You are now ready to analyze the portfolio cost.
Navigating within the portfolio analysis

Use the controls in the Navigate section of the Analysis ribbon to move between the pages of the portfolio
analysis wizard and change the settings that you chose when you created the portfolio analysis.
CONTROL DESCRIPTION
Define Properties Clicking Define Properties takes you to the first page of the
new portfolio analysis wizard, where you can change settings
including the driver prioritization, the selected projects, and
the primary cost constraint.
Prioritize Projects Clicking Prioritize Projects takes you to the project

prioritization page of the new portfolio analysis wizard, where
you can change any of the business driver settings for the
projects in the portfolio.
Review Priorities Clicking Review Priorities takes you to the priority list for
the projects in this portfolio, where you can see how the
projects in the portfolio have been prioritized based on the
business driver settings.
CONTROL DESCRIPTION
Analyze Cost Clicking Analyze Cost takes you to the cost analysis page
and enables the Portfolio Selection and Projects sections of
the ribbon, where you can analyze project and cost options to
get the best return on your investment.
Analyze Resources Clicking Analyze Resources takes you to the resource

analysis page. This button is available if you chose the
Analyze time-phased project resource requirements
against organizational resource capacity option.
You are now ready to begin assessing portfolio scenarios.
Related articles
Resource analysis in the Microsoft Project Web
Application
Summary: Learn what a resource analysis is and how to get started doing resource analyses in the Project Web
Application (PWA).
PWA helps you analyze your resource capacity to determine which projects can be delivered. PWA will also help
you identify where you have resourcing gaps. The resource analysis may also provide a forecast of the additional
cost required to deliver your target portfolio.
There are several tasks required to perform resource analysis:
Define the project demand profile.
Define the resource capacity profile.
Perform portfolio analysis and save at least one cost analysis.
The resource analysis is performed within a specific cost analysis scenario. Once you have completed the cost
analysis, you can start performing a resource analysis. Resource analysis is a core feature in the Project Web
Application, and is available in Project Online and supported versions of Project Server.
Configuring the resource pool

The resource analysis process compares the project demand for resources with the available supply of resources.
The available supply is defined by the PWA resource administrators in the resource pool. Each resource in the
resource pool may be assigned one or more of the following attributes:
Availability
Skills
Cost
Organizational unit
Other customizable characteristics (as defined by the PWA administrator)
Creating a Resource Analysis

If you are using an existing cost analysis, confirm that the Resource Planning option was in the Define Properties
screen. If using a new analysis, ensure that the Resource Planning option has been selected. This will allow the user
to define specific variables that will impact the resource analysis function.
To get started creating a portfolio analysis:

1. In the Project Web App, click on Portfolio Analyses Link in the left navigation menu.
2. Click on the New Button to create a new analysis.
3. Populate the fields per the options in the table below.
4. Select the option to Analyze project resource requirements against resource capacity.
The following settings may be found in the Define Properties screen of the Portfolio Analyses menu.
These settings impact the resource analysis calculations.
FIELD DESCRIPTION
Planning Horizon Defines the start and end dates for the analysis.
Planning Granularity Controls the time periods used in assessing work allocations
for specific roles. Most organizations select monthly.
Resource Role Custom Field Specify the custom field representing the resource role here.
Resource Filtering Project requirement and organizational resource capacity data

will not include resources that have been filtered out.
Resource Capacity Impact for Projects Outside of the Analysis Determines whether to include projects with proposed
bookings in the analysis.
Project Start and Finish Dates Some organizations may rely on other tools to assess the
optimal start date, for instance an ERP system. For those
organizations, the proposed start date may be generated
outside of Project Server and then input as a custom project
level field.
Defining the project demand profile

After configuring the resource pool, the resource demand must also be defined. PWA allows users to implement
two separate methods for defining the resource demand profile:
RESOURCE DEMAND ESTIMATION METHOD DESCRIPTION
Bottom Up Project managers or schedulers assign resources to specific

tasks, and then publish the schedule to Project Server.
Top Down A project is created within Project Server. Instead of assigning

resources to specific tasks, the project manager or scheduler
creates a high level resourcing plan. The resourcing plan allows
the project manager to "reserve" the resource for a defined
period of time. This option is usually used early in the project
planning cycle before specific tasks have been defined within
the project schedule.
Once the resource pool and demand profiles have been defined, you will be ready to perform resource analysis.
Related articles
Establishing the resource pool
Summary: Learn how to create a resource pool that supports resource analysis activities within Project Web
Application (PWA).
you identify where you have resourcing gaps. The resource analysis will provide a forecast of the additional cost
required to deliver your target portfolio.
This article will discuss how to configure your resource pool to correctly define the capacity in the resource
analysis. Resource analysis is a core feature in the Project Web Application, and is available in Project Online and
Resource Center
The PWA Resource Center is where you populate the resources that will make up your available resource capacity.
Your administrator is usually responsible for keeping this up to date. Organizations generally define the resource
pool using a combination of approaches:
Importing resources from a spreadsheet or database.
Importing resources from your organization's Active Directory list of user accounts
Once the data has been imported, the administrator will need to add additional fields and values to correctly define
resource capacity.
Generic vs. named resources

Generic resources are placeholders with specific skills, such as Developer, Marketing Analyst, etc. These resources
are often used in the project proposal process. During this time, most organizations do not know which specific
named resources will be performing the work. Generic resources do not count towards your organization's capacity
to deliver work.
Named resources are specific resources that work within your organization. Named resources allow your
organization to assign tasks to specific individuals. Named resources also support the calculation of available
resource capacity in the resource analysis.
Consider the following example:
Assume your organization has a role of Marketing Analyst. That role is assigned to three projects, showing a
requirement for three Marketing Analysts.
Your organization has two people assigned to the role of Marketing Analyst, John Smith and Jane Doe. John
and Jane are named resources.
The resource analysis will determine a need for three Marketing Analysts, and compare this with the
available capacity of two named resources. The resource analysis will conclude that only two projects may
be performed.
Many organizations define a standard list of roles. This list is defined as a resource-level custom field linked to a
standard lookup table. Each role is then mapped to at least one generic resource and several named resources.
Make a note of the field you are using to assign standard roles. You will need this field name when you create the
resource analysis.
Configuring the resource pool
To create a new resource:

1. Navigate to the Resource Center.
2. Click on the New Button on the Resource Tab.
The resource pool represents the supply of available resources within the organization. The system administrator
must configure the resource pool to support the portfolio analysis process.
Following are key resource settings for consideration when configuring the enterprise resource pool:
CONFIGURATION ITEM NOTES
Maximum Units The total resource availability in the Resource Analysis

component is calculated as the total of the resource
availability.
Resource Calendars Total availability is reduced by any exceptions to the resource

calendars, i.e. holidays.
CONFIGURATION ITEM NOTES
Role Each resource should be assigned a specific role within Project

Server. The Portfolio Analysis module uses this field to
calculate the total role availability and the average cost for a
resource in that specific role. This field must be created as an
enterprise custom field and linked to a custom lookup table.
Standard Rates The system utilizes the Standard Rate field to approximate the
incremental costs of adding resources to a given portfolio.
Standard rate
The resource analysis will suggest the additional cost of hiring new resources to support the project portfolio. This
additional cost is calculated from the average standard rate of each resource assigned to the role.
For example, assume we have two resources assigned to the role of Marketing Analyst, John Smith and Jane Doe.
John has a rate of $125 per hour. Jane has a rate of $150 per hour. The resource analysis will assume new
Marketing Analysts can be hired for a cost of $137.50. This cost is calculated as the average of John and Jane's
hourly rates.
The resource pool has now been configured. You are ready to define the resource demand.
Related articles
Using task level assignments to define resource
demand
Summary: Learn how to define the resource demand through task assignments within the project schedule.
you identify where you have resourcing gaps.
You must perform two activities prior to starting the resource analysis.
Define the resource capacity profile.
Define the project demand profile.
This article will discuss how to configure your projects correctly to support the resource demand calculations.
Resource assignments are a core feature of the project management capabilities of the Project Web Application,
and are available in all versions of Project Online and Project Server.
Project tasks and resource engagements

PWA provides two ways for your organization to model resource demand:
METHOD DESCRIPTION
Bottom up estimating Project managers assign resources to project tasks. The

project is then published to PWA.
Top down estimating A project or proposal is created within PWA. The project
manager submits a summary request for a specific
resource type to support the project. The request is
routed to the appropriate resource manager for approval.
This resourcing plan allows the project manager to
"reserve" the resource for a specific duration.
(For more information on top down estimating, please review Using resource engagements to define resource
demand.)
This article will focus on bottom up estimating within PWA.
Booking type
Task assignments may be classified as either proposed or committed. Many organizations use these booking types
to drive logic within the resource analysis calculations. The resource administrator may assign a default booking
type to each of the resources listed in the PWA Resource Center.
The booking type also impacts some of the resource capacity calculations in the Resource Center. For example,
some organizations decide not to review the demand assigned to proposed bookings. It is assumed that these
assignments have not been confirmed, and thus should not count towards forecast resource demand.
When creating the resource analysis, you should pick the appropriate option that is aligned with how your
organization is forecasting work. The default setting is that only committed work is calculated.
Configuring the schedule

You will need to "tell" PWA how you are estimating your tasks for each of the projects in the project portfolio. You
can designate that the schedule should use the task assignments or associated resource engagements. (By default,
project task assignments are calculated within the resource analysis.)
To toggle the calculation method, open the schedule in Microsoft Project Professional. Navigate to the Project
Information screen and toggle the option marked "Calculate Resource Utilization From..." Save and republish the
project for the changes to take effect in any new resource analysis.
If you have an existing resource analysis, you will need to reload the resource data and trigger a recalculation.
You are now ready to run a resource portfolio analysis.
Related Articles
Using resource engagements to define resource
demand
Summary: Learn how to define the resource demand through resource engagements in PWA.
Applies to: Project Online, Project Server 2016
Resource engagements are a feature in the Project Web Application (PWA) to support high level resource demand
estimating. This feature supports the PWA portfolio analysis functionality that compares resource demand with
the available supply of resources.
This article will discuss how to configure your projects correctly to support the resource demand calculations.
Resource engagements are a core feature of the project management capabilities of the Project Web Application,
and are available in all versions of Project Online and Project Server.
Project tasks and resource engagements

PWA provides two ways for your organization to model resource demand:
METHOD DESCRIPTION
Bottom up estimating Project managers assign resources to project tasks. The

project is then published to PWA.
Top down estimating A project or proposal is created within PWA. The project
manager submits a summary request for a specific
resource type to support the project. The request is
routed to the appropriate resource manager for approval.
This resourcing plan allows the project manager to
"reserve" the resource for a specific duration.
This article will focus on top down resource estimating within PWA.
Resource Engagements
Resource engagements support high level resource estimating. Resource engagements can be created in Project
Professional or in the Resource Request screen on the Resource Center Navigation tab.
Please see this article for more information on resource engagements.
Committed and proposed bookings

Task assignments may be classified as either proposed or committed. By default, resource engagements are
created in a proposed state. Once the resource engagement has been approved by the resource manager, it is
changed to a committed state.
When creating the resource analysis, you should pick the appropriate option that is aligned with how your
organization is forecasting work. The default setting is that only committed work is calculated. Change the setting
to support the calculation of demand from proposed resource engagements.
Microsoft Project Professional calculations

You will need to "tell" PWA how you are estimating your tasks for each of the projects in the project portfolio. You
can designate that the schedule should use the task assignments or associated resource engagements.
To toggle the calculation method, open the schedule in Microsoft Project Professional. Navigate to the Project
Information screen and toggle the option marked "Calculate Resource Utilization From..." Save and republish the
project for the changes to take effect in any new resource analysis.
If you have an existing resource analysis, you will need to reload the resource data and trigger a recalculation.
You are now ready to run a resource portfolio analysis.
Related Articles
Defining project portfolio dependencies
Summary: Learn how to define project interdependencies that may impact the portfolio analysis calculations.
PWA helps your organization calculate the optimal portfolio of projects to be delivered. This calculation
incorporates many factors, including:
The estimated resources required to deliver the projects
The availability of resources within the enterprise resource pool
Financial constraints
Proposed start date for projects
Project dependencies
This article will explain how to incorporate project dependency logic into your portfolio analyses. Project
dependencies are a core feature of the portfolio management capabilities of the Project Web Application, and are
available in Project Online and in all support versions of Project Server.
Project dependencies
Project dependencies are relationships between specific projects within a portfolio. These dependencies will be
incorporated into the portfolio analysis calculations.
Dependency types
PWA supports the following dependency types.
TYPE DESCRIPTION
Dependency All dependent (required) projects must be selected before the

primary project is selected. If one of the dependent projects is
not selected, the primary project is not included in the
calculation.
Mutual Inclusion All mutually included projects must be selected within the
optimal portfolio. If one of those projects is not selected, none
of the designated projects are selected.
Mutual Exclusion Only one of the mutually excluded projects will be selected
within the optimal portfolio. Once one project has been
selected, all other mutually exclusive projects will be excluded
from the optimal scenario.
TYPE DESCRIPTION
Finish to Start Projects must be executed in order. You may define the
sequence in which projects must be completed.
Finish to Start dependencies are only relevant to the
resource analysis calculations. They are not applied to the
cost analysis.
Defining project dependencies

Navigate to the Portfolio Analyses screen and click on the Project Dependencies button in the Analyses tab.
This will open the screen to create project dependencies.
Including dependencies in the portfolio analysis calculations

By default, dependencies are not included in the portfolio analysis calculations. To recalculate the portfolio analysis
with dependencies, navigate to the screen where you review the results of the specific cost or resource analysis.
1. Click on the Options tab and select the dependencies to enforce.
a. Selecting the Project check box will apply the Dependency, Mutual Inclusion, and Mutual Exclusion
dependencies.
b. Selecting the Finish to Start check box will apply the Finish to Start dependency. Note that this check
box is only available from the Resource Analysis screen.
2. Click on the Recalculate button in the Analysis tab.
You are now ready to run a portfolio analysis.

Related Articles
Prioritizing the portfolio with custom fields
Summary: Learn how to define and configure custom fields that support the portfolio prioritization calculation in
the Project Web Application.
Prioritization based on manually calculated fields
This article will discuss how to manually prioritize the project portfolio. Manual prioritization is a core feature of
the portfolio management capabilities of the Project Web Application and is available in Project Online and all
versions of Project Server released after 2010.
Other articles will address how to prioritize the project portfolio using the native PWA business driver
functionality.
Manual prioritization
There are several reasons to manually prioritize the project portfolio:
Your organization already has a tool or process that performs project prioritization.
The native business driver prioritization process is not aligned with your needs.
Creating an enterprise custom field

Manual prioritization will be captured in an enterprise custom field that is created by your PWA administrator. This
field must satisfy the following characteristics:
The field should be defined as a project level field.
The field should be a number or cost field.
You will then need to assign field values for each of the projects under consideration.
Creating the portfolio analysis

New portfolio analyses will use the business driver prioritization mechanism by default. To use the manual
prioritization mechanism:
1. Select the option to prioritize using custom fields when creating a new portfolio analysis.
2. Click on Modify in the Analysis Tab to open the field selection screen.
Assigning prioritization parameters

You can assign prioritization parameters to each of the custom fields in the Manual Prioritization screen.
Assign specific weighting to each of the fields. Click Save and PWA will normalize the weight for each of the fields
to a value between 1% and 100%.
By default, PWA will display the minimum and maximum values assigned to projects for each of the custom fields.
The ranking for each project is calculated within this range. Adjust the range to model your prioritization logic
more accurately. Click on the Next button to review the calculated priorities.
Review priorities
The projects are now displayed in the order of the calculated priority.
The total sum of all projects will be 100%. This is the value of the entire portfolio.
You are now ready to analyze the portfolio cost to determine the maximum value that can be delivered within your
constraints.
Related articles
Modeling cost scenarios in portfolio analysis
Summary: Learn how to use the PWA portfolio analysis functionality to model the optimal combination of
projects within your planned budget.
Cost analysis is the process of matching work demand with available funding. It is one of the project portfolio
analysis methods enabled by the Project Web Application (PWA). Cost analysis is a core feature in PWA, and is
available in Project Online and supported versions of Project Server.
PWA also supports resource constraint analysis to match work demand with resource supply.
Three inputs are required to perform cost analysis in PWA:
Defined project portfolio, with costs estimated
Understanding of available funds
This article will teach you how to interpret and use the Analyze Cost screen in PWA to create these scenarios.
This screen is split into three components:

Metrics
Portfolio efficient frontier (or strategic alignment)
Project portfolio summary (depicted as a grid or scatter chart)
Metrics
The metrics grid in the top left of the screen displays high level scenario calculations. You may also use this grid to
add new constraints to the cost calculation.
1. To add constraints, click on the Modify link in the Cost Limits section of the Metrics grid.
2. Add additional fields from the Available Constraints list. These fields will now appear in the Cost Limits
section.
3. Click into the Cost Limits section to assign a constraint to the newly added field.
4. Click Recalculate in the Analysis Tab to recalculate the portfolio based on the new constraints.
Efficient frontier
The efficient frontier is a commonly used tool in scenario modeling.
Each project is classified by estimated benefits and cost. The optimal combination of projects is then displayed for
each cost point.
A portfolio that is on the efficient frontier represents the most value that can be achieved for that cost. A portfolio
below the efficient frontier communicates that more value can be achieved for the same cost.
You can use the efficient frontier to communicate the value trade offs that take place as part of your portfolio
prioritization discussions.
Strategic alignment
You can use the strategic alignment graphic to assess if your projects are aligned with your goals.
For example, you may have said that Expanding the Customer Base is your primary organizational goal. The
strategic alignment graphic shows that most of your spending is on Improving Customer Satisfaction. You may
wish to reconsider how your spending is allocated.
The project data grid

The project data grid is your primary interface on this screen.
Review the columns on this grid to understand the state of the portfolio. Your PWA administrator is responsible for
modifying which columns appear on the screen.
Within this grid, you can tell PWA to force a particular project in or out of the analysis. You might do this if a
project must be completed to keep your organization in regulatory compliance.
Forcing projects in or out of a scenario often results in a sub-optimal project portfolio. Refer to the efficient frontier
after recalculating your portfolio to assess the impacts of forcing in or out a project.
The scatter chart

You may also review the portfolio on a scatter chart.
The scatter chart shows all projects by their total cost and total delivered value.
The scatter chart is color coded to four different possible classifications for each project:
STATUS DEFINITION
Selected The project has been selected in the scenario currently under
analysis.
Unselected The project has not been selected in the scenario currently
under analysis.
Forced In The project was forced into the scenario under review.
Forced Out The project was forced out of the scenario under review.
The cost analysis view

Use the controls in the Projects section of the ribbon to change the view or to load new constraint values.
You would reload constraint values if you have changed the underlying cost of projects within the portfolio
analysis, and need to update the calculations with the new cost.
Other controls in the Projects section include:
CONTROL DESCRIPTION
Grid Click Grid to display a grid of projects, their priorities, costs,

and other project data.
Scatter Chart Click Scatter Chart to display a chart of project cost versus
value.
View Use the View menu to select a view. You can add new views
on the PWA Settings page.
Reload Constraint Values Click Reload Constraint Values to reload the constraint
values from the Project Web App database. Use this option if
the values have been updated since you started the analysis.
Hide Metrics Click Hide Metrics to hide the Metrics table and the Efficient
Frontier chart. Click Hide Metrics again to show these.
The initial calculation is automatically saved as the baseline scenario. The baseline scenario represents the
unconstrained selection of every project within the portfolio. Users may perform what-if analysis on the scenario
by changing the various options and recalculating the optimal solution within the new parameters.
Saving the scenario

You may save any created scenario for further review.
The scenario is now added to the list of scenarios available for review.
After creating a scenario model, save the scenario for further review. If you configured resource analysis during the
analysis creation, saving a scenario will activate the Analyze Resources button.
This will allow you to further examine your scenario for potential resource capacity issues.
You may also consider finalizing the scenario by committing your selected projects to execution.
Related articles
Modeling resource scenarios in portfolio analysis
Summary: Learn how to use the PWA portfolio analysis functionality to model resource scenarios.
Resource analysis is the process of matching work demand and resource supply. It is one of the project portfolio
analysis methods enabled by the Project Web Application (PWA). Resource constraint analysis is a core feature in
PWA, and is available in Project Online and supported versions of Project Server.
PWA also supports cost constraint analysis to match work demand with available funding.
Three inputs are required to perform resource analysis in PWA:
Defined project portfolio, with resources estimated
Defined resource pool
Prioritized project list
This article will teach you how to interpret and use the Analyze Resources screen in PWA. This screen will
become available after you have saved a scenario in the Analyze Cost screen.
This Analyze Resources screen is split into three components:

Metrics
Scenario chart
The Project Gantt Chart/Requirements Details
Additional features are available using the various reports available from the ribbon.
Metrics
The metrics grid in the top left of the screen displays high level scenario calculations.
You may add custom fields to the Totals section. These fields will provide calculated indicators of the variables
impacting your portfolio.
The various calculation options may be controlled through the Options tab. The primary control on this tab is the
Units field. Units may be set as either FTE or Cost.
If you set the Units option in the Options tab to "FTE," the Hire Resources cell in the Resource Constraints
section is editable. You can enter the number of additional resources you expect to hire to support the portfolio.
The system will calculate the cost of these additional resources.
If you set the Units option in the Options tab to "Cost," Additional Resources are displayed in the Resource
Constraints section. You can enter additional funding for resources in this field. The system will calculate the
number of additional resources that may be hired with these funds.
The Options tab controls several other calculation variables:
ITEM OPTIONS IMPACT
Units FTE "FTE" toggles the Resource

Constraint to display Hire
Cost Resources. You may then
enter the number of
resources you are willing to
hire to support the
portfolio. The system will
estimate a cost based on the
roles required and their
average rate.
"Cost" toggles the Resource
Constraint to display
Additional Resources. You
may then enter the
additional funds you are
willing to spend to support
the portfolio. The system will
estimate the roles to be
hired based on the project
demand and the average
rate of the required roles.
ITEM OPTIONS IMPACT
Type Internal Internal resources are hired

full time when there is first a
External gap for their skills. As
internal hires, these
resources remain on staff for
the remainder of the
portfolio planning period.
(Internal resources may be
significantly more expensive
than external resources.)
External resources may be
hired only for a short period
and then terminated.
External resources may also
be hired part time. The
minimum allocation for
external resources is set in
the Allocation Threshold
cell.
Cost Rate Table A-E Each resource may have up to five

standard cost rates. These rates are
stored in Cost Rate Table A, B, C, D
and/or E. The system will calculate the
standard rate for a role as the average
of the cost for all resources in that role.
You can toggle this field to select
different rates to be used for the
estimating of additional resource costs.
Allocation Threshold The allocation threshold controls the

minimum allocation that an external
resource may be hired for. For example,
you may set the allocation threshold to
25% to calculate external resources in
units of .25 FTE.
Modeling additional resources

PWA can assess the impact of adding resources on the overall portfolio. Simply type the number of resources that
you want to add in the Hire Resources box, and then click Recalculate on the ribbon. These calculations are
affected by the settings in the Options tab.
The resource analysis view will update to show you how many projects you can deliver, and the Hired Resources
Report (under Reports on the ribbon) will update to show which resource roles need to be hired.
Scenario chart
When you save a resource scenario, it will appear on the Scenario Chart.
The Scenario Chart is a scatter graph depicting each of the scenarios by cost and strategic value. Note that the
cost depicted on this chart is the additional cost required to hire more resources (i.e., the Additional Resource
cost).
The Gantt Chart view

The Resource Analysis functionality allows the user to perform what-if analysis on the projects within the scenario.
The following variables may be modified to assess the impact on the overall portfolio:
VARIABLE INTERFACE
Force projects in or out of the analysis Gantt Chart: Force In/Out Column
Change project start dates Gantt Chart: New Start column
Adding resources Metrics
Project dependencies Project dependency interface

Forcing Projects In/Out
Projects may be forced in or out of the calculation in the Gantt Chart view.
This feature works much like the similar function in the Cost Analysis module. You may force projects out of the
calculation. This will free the resources from those projects to support other projects. You may also force projects
into the calculation. Forcing a project in may divert resources from other projects.
Shifting the project start date
You can move projects forward or backward on the calendar to see how this affects your resource allocation.
Experimenting with various project schedules may help you fit more projects into the portfolio.
To move a project's start date, click Gantt Chart on the ribbon, then choose a New Start month for the project that
you want to move, then click Recalculate.
Changing the start date in the Resource Analysis Gantt chart does not affect the actual start date of your projects.
When you choose to Commit the scenario, the new date will be stored in a field called New Start Date Field.
Requirements Details
PWA provides several ways to analyze the impact of scenarios on your resource pool.
The Requirements Details view lets you examine the calculated scenario in more detail.
The Resource Availability section at the top of the page displays a summary of the resources defined in the
Enterprise Resource Pool.
Toggle the Highlight Deficits option on the top right of the page to highlight those roles that are overcommitted
to the project portfolio.
The Project Requirements grid displays a number of useful fields.
FIELD DESCRIPTION
Priority The priority that you set for the project.
Force In/Out Displays the status of the project as you set it.
Original Start The start date of the project as scheduled in the project plan.
New Start The new start date that you have defined in the resource
analysis.
Requirements The Requirements field represents the total number of person

months required for the project.
Deficit The Deficit field represents the total number of person months
that exceed the available resource supply.
The Deficit and Surplus Report

Click on the Reports button on the Analysis tab to access the two reports provided within PWA:
The Deficit Surplus Report
The Hired Resources Report.
The Deficit and Surplus Report displays a summary of the resource pool.
Positive numbers show where you have more resources than needed. Negative numbers indicate that you do not
have enough resources. These numbers are based on all the projects in your cost analysis scenario.
The Hired Resources Report

Run the Hired Resource Report to see the impact of the resource analysis recalculation.
This report displays key details about the resource the system is proposing to be hired to fill those the deficits.
The Hired Resource Report displays the following fields and calculations:
FIELD DESCRIPTION
Role The role identified by the system that needs additional

resources.
Project The project requiring the resource.
New Start The start date of the resource.
End Date The end date of the resource. This will be impacted by the
option you selected in the Options tab for Internal or External
resources.
Cost Calculated summary of the total resource cost, based on

duration X average rate per role.
Work The number of hours that the resource will work between the
New Start and the End Date. This will be impacted by the
option you selected in the Options tab for Internal or External
resources.
Rate The rate is the average standard rate of all resources in the
resource pool mapped to the specific required role.
You are now ready to save the scenario and compare it with other saved scenarios.
Related articles
Comparing multiple portfolio analysis scenarios
Summary: Learn how to compare multiple portfolio analysis scenarios in the Project Web Application
One of the most commonly asked questions in project management is, "Are we delivering the right projects?" The
portfolio analysis module in PWA is designed to help organizations answer that question. The portfolio analysis
module answers that question by performing the following functions:
Centralizing a list of requested projects or proposals.
Developing a list of the estimated costs required to deliver those projects.
Developing a list of the estimated resources required to deliver those projects.
Providing several methods to prioritize the list of requested projects or proposals.
Providing the organization with the ability to explore the various dimensions of the project portfolio.
This article will teach you how to review the results of the portfolio analysis process.
Requirements
It is assumed that you have created and saved several portfolio scenarios as part of your cost and resource
analysis activities.
Comparing Scenarios
Within the Analyze Costs or Analyze Resources interfaces, click on the Compare button in the Analysis tab.
This will take you to the Compare Scenarios interface.
The Compare Scenarios screen has three main components:

Compare metrics
Efficient frontier/Scenario chart
Compare project selection
Compare metrics
The Compare Metrics grid summarizes key metrics from all of your saved scenarios.
Specific metrics that are displayed include:
METRIC ANALYSIS TYPE DESCRIPTION
Projects selected Cost, Resource Number of projects you selected in

each scenario.
Additional Resources (Work) Resource Additional hours required from

resources to deliver the portfolio. (See
the article on resource analysis for
more information on how this is
calculated.)
Strategic value Cost, Resource Total value of the selected projects. This
will display as a percent of the total
value of the portfolio.
Additional Fields (as configured) Resource If you added additional fields to the
Metrics grid in the Analyze Cost or
Analyze Resources interfaces, those
fields will be displayed here.
Additional Resource Constraint Resource Displays additional parameters used in

the resource analyses (i.e., additional
resources added or additional cost of
added resources).
Efficient frontier/scenario chart

The efficient frontier will display if no resource analysis has been saved. Once a resource analysis has been saved,
the screen will display a scenario chart.
The efficient frontier is a commonly used calculation in scenario modeling.
Each project is classified by estimated benefits and cost. The optimal combination of projects is then displayed for
each cost point.
A portfolio that is on the efficient frontier represents the most value that can be achieved for that cost. A portfolio
below the efficient frontier communicates that more value can be achieved for the same cost.
When you save a resource scenario, it will appear on the Scenario Chart. The Scenario Chart is a scatter graph
depicting each of the scenarios by cost and strategic value.
Compare project selection
This grid will summarize each of the projects you have analyzed. The grid shows which projects were selected for
each scenario.
Organizations often use this information to calculate which projects are most likely to be selected – across all
calculated scenarios. Being selected in multiple scenarios implies the project will more likely provide value to the
organization.
After completing the scenario comparison, select the optimal scenario for your organization.
In the next step, we will commit these projects to execution.
Related articles
Committing the selected portfolio scenario
Summary: Learn how to progress your selected portfolio scenario into execution.
Project portfolio analysis is the process by which you select the optimal collection of projects for your organization
to perform. This process is enabled by the PWA portfolio analysis interface. This interface lets you model various
cost and resource constrained scenarios.
The last step in the planning process is to finalize the portfolio of selected projects. Finalizing the portfolio moves
the projects from the Planning stage to the Execution stage. The process of moving projects from one stage to
another is referred to within the PWA interface as “committing the portfolio.” Portfolio progression is a core
feature of the Project Web Application, and is available in Project Online and supported versions of Project Server.
You must have configured your planning workflow before committing the portfolio.
This article assumes you have selected one of your saved scenarios for progression.
To commit the scenario, navigate to the scenario selected by your organization.
Click on the Commit button on the Analysis tab in the Analyze Cost or Analyze Resources interface.
When you click on the Commit button, two actions are triggered:
Several project level fields are populated to capture the output of the portfolio analysis process.
If configured, workflow will progress the selected projects into the next workflow stage.
Populating the associated commit data

Clicking on the Commit button will populate six project level fields. Cost fields reflect the output of the cost
portfolio analysis. Schedule fields reflect the output of the resource analysis process.
1. Committed Planned End Date
2. Committed Planned Start Date
3. Committed Portfolio Selection Decision (Cost)
4. Committed Portfolio Selection Decision (Schedule)
5. Committed Portfolio Selection Decision Date (Cost)
6. Committed Portfolio Selection Decision Date (Schedule)
Those fields are available for use in Project Center views or custom reports and perform the following functions:
FIELD OPTIONS DESCRIPTION WORKFLOW AVAILABLE
Committed Planned End Date The finish date of the project No

Date you calculated during the
resource analysis.
Committed Planned Start Date The start date of the project No

Date you calculated during the
resource analysis.
Committed Portfolio Selected Shows the result of a cost Yes.1

Selection Decision (Cost) constraint analysis on a
Unselected project.
Forced In
Forced Out
Committed Portfolio Selected Shows the result of a Yes.2

Selection Decision (Schedule) resource constraint analysis
Unselected on a project.
Forced In
Forced Out
Committed Portfolio Date The committed date of the No

Selection Decision Date project.
(Cost)
Committed Portfolio Date The committed date of the No

Selection Decision Date project. (This field is only
(Schedule) calculated when committing
a resource scenario.)
1 Aliased as 'Optimizer Decision.'

2 Aliased as 'Planned Decision.'
Advancing to execution
You can configure workflow in PWA to automatically progress committed projects into execution.
Related articles
Configuring workflow to support portfolio analysis
Summary: Learn how to configure workflow to support portfolio analysis.

Workflow automates common tasks within your organization. Workflow may be combined with the PWA
portfolio analysis functionality to enable portfolio planning. This allows your organization to easily design and
sustain processes designed to achieve your strategic goals.
Workflow is a core feature of the Project Web Application, and is available in Project Online and supported
versions of Project Server. You must have SharePoint Designer installed to support the configuration of workflow
logic.
This article assumes you have selected one of your saved scenarios to be committed. When you click on the
Commit button, two actions are triggered:
Several project level fieldsare populated to capture the output of the portfolio analysis process.
If configured, workflow will progress the selected projects into the next workflow stage.
To commit the scenario, select the Commit button on the Analysis tab in the Analyze Cost or Analyze
Resources interface.
Workflow options
This article assumes you have configured a workflow to support moving projects from one stage to another.
Please see this article for more information on configuring basic workflow within PWA.
In SharePoint Designer, configure the workflow stage to Wait for a Project Event. In the action configuration
options, select When a Project is Committed.
After adding that step, you can insert logic based on the data captured in the fields that are populated by the
commit action:
FIELD OPTIONS (LOGICAL TEST) DESCRIPTION

FIELD OPTIONS (LOGICAL TEST) DESCRIPTION
Optimizer Decision Selected (3) Shows the result of a cost constraint

analysis on a project.
Unselected (2)
Forced In (0)
Forced Out (1)
Planner Decision Selected (3) Shows the result of a resource

constraint analysis on a project.
Unselected (2)
Forced In (0)
Forced Out (1)
Many organizations will add logic to move the Selected projects to the next stage of execution. If configured,
Unselected projects may be moved to a Parked stage.
For more information on developing custom demand management workflows, refer to the online site for
Microsoft Project Server Demand Management resources: http://technet.microsoft.com/en-
us/projectserver/ff899331.
Related articles
Supporting your Project Online adoption with a
Project Management Office (PMO)
What is a PMO?
So you're planning to adopt Project Online into your business. How are you are planning to use it, or a better way
of putting it, what's the business problem you are trying to solve? Some of the examples might be:
My executives want better visibility into project status.
I need a better way of managing my resources and assigning them to projects.
I want to easily track the time people are spending on their tasks.
I want more robust way to track project data than using Excel spreadsheets.
Organizations who have been most successful with using Project Online in addressing business problems such as
these are the ones that create a set of standards, processes, and best practices for the way that projects are
managed in their organization. The person or group that creates and manages these rules of project management
is sometimes referred to as the Project Management Office (PMO ).
What does a PMO do?

In larger companies, a PMO can consist of a department that deals with project management issues across the
organization, such as project management governance, implementation, training, researching project management
needs, or determining the best way to build useful reports. In small or medium businesses, a PMO can range from
a single person to a small group of people, but can also scale to try to address the same issues as in large
businesses. The common goals of all PMOs, however, would include:
Driving and evangelizing the project management system adoption.
Simplifying project management for the organization's users by automating processes into the tool.
Creating policies, procedures and best practices around project management functions.
Being the project management subject matter experts by serving as a 'Center of Excellence' for all things
project management, and providing training on project management best practices and tools.
Being empowered by executive sponsorship to make and enforce change through their recommendations.
Still confused? Let's take a step back and use an example that people can relate to - how a head of household might
take care of their own family:
Need PMO Family

The PMO helps to establish an efficient The heads of the household will need
way to deliver information to project information on how things are going:
stakeholders through project status and -Quarterly reports on children's studies.
health reports. This might involve -Monthly bank statements to show the
researching reporting needs, moving status of finances.
required data to the system, and -Yearly doctor visits to determine family
establishing workflows to ensure that member's health.
the data required for recurring reports
makes it to the system in time.
The PMO creates processes to get the People in the family will need to know
right data to the project management who's doing what. This can include:
system to provide status at a project -Who will pick up children from school
level to project managers. It also today, walk the dog in the evenings,
provides guidance and best practices for cook dinner, etc.
resource management. -If someone can't do their usual task,
you need to know who is available to
take their place.
It helps to show everyone's work and
school schedule, and availability, on a
central family calendar. This way it is
easy to know who can be scheduled for
what.
The PMO helps to create project Family members will need a forum in
collaboration sites and customize them which they can collaborate, such as:
to best suit the needs of the site users. -Posting important events on a wall
calendar in the kitchen
-Talking to each other daily at the
dinner table.
The PMO is responsible for setting up a Heads of the household might need to
system to handle risk management. plan to reduce risk:
-Determine insurance needs for health.
Purchase a health club membership.
- Increase the amount they are saving
for retirement.
The PMO looks at current processes Heads of household will establish rules
and workflows, and finds a method of and processes for the family, such as:
automating them through the project -Set children's curfew or sleep hours
management tool being implemented. -Look at factors to determine which
One of these might involve determining purchases to make (for example,
drivers for selecting which projects to "Should we buy a car, fix the roof, or go
move forward on given a set budget on vacation this year?").
(portfolio analysis). -Set up lawn sprinklers on an automatic
timer.
-Pick a time of week for the grocery
shopping and errands.
A PMO drives a company to more efficient project management by doing things such as:
Gathering information to help define what the project management requirements are for the organization.
For example, analyzing your organizations business needs, designing processes to address those needs, and
then mapping those processes to settings or workflows in Project Online.
Determining what data is important to review on an ongoing basis, and working with the Project
administrator to share that data with stakeholders. For example, determining the data required and the
process to get the data into the system to create a weekly project status report to provide stakeholders with
a roll-up of the health of in-progress projects.
Creating rules for processes and workflows. For example, establishing a workflow where project ideas go
through an approval process to become projects in Project Online.
Migrating existing data from your current project management system into a new one. For example, finding
the easiest way to migrate resource and project data from Microsoft Excel spreadsheets to Project Online, or
from Project Professional on each person's computer to a centralized Project Online environment.
Providing project portfolio management support to help with project prioritization and forecasting. Like
most companies, there are many projects you'd like to do, but have limited budget and resources to do all of
them. You need a way to determine which projects that you should move on. PMOs can drive the project
and program selection process to ensure that future investments are in alignment with the organization's
strategic goals and growth vision.
Managing the emotional changes users might face in moving from their current project management
system to which they are attached. For example, tactfully influencing project managers to move from their
old process of saving their project files to their hard drives and sharing them out by showing them the
advantages of publishing them to Project Online. The PMO might do this by devoting more time to
convincing the more senior project managers first, and hoping their influence on the other project managers
helps to drive the change.
Managing the technical challenges of change by offering great training options.
Why do I need a PMO?

In the family example, the consequences of not addressing some of the needs can be dire. For example, not
reviewing a child's report card when it first arrives might result in the assumption that things are fine, when
actually more study time or a tutor might be needed. In the same way, deploying Project Online without creating
an entity to help with standardization and adoption can also have dire circumstances. Establishing a PMO will help
to increase the chances of success for your Project Online deployment. Depending on your goals, this can translate
to better efficiency in project management (for example, more projects completed on time), which is usually
associated with lower costs to manage projects (for example, more project completed at or under budget).
What are the first steps in creating a PMO?
The first steps in creating a PMO probably have already happened if you made an effort to find this article. If you
are interested in moving to Project Online, you more than likely already have an idea of how it might improve
efficiency or solve a problem in your company. In creating a path to formalizing your PMO, you should consider
the following:
Define what do you want your PMO to do
Is the main goal of your PMO going to be to address a specific business problem? For example, you might want to
implement a timesheet system to get tighter control of costs analysis. Or you might have your project data spread
across two or even three different applications, and want to consolidate the data into a single system, which would
help to provide better insight into the execution of projects. Or it might be to provide ongoing project management
guidance, and address project manager training needs. Once you understand why your PMO is needed, it will be
much easier to scope what the requirements are in establishing and maintaining it.
Obtain executive sponsorship
Make sure someone up high supports you. It is important that your PMO has executive sponsorship, as lack of
executive support is one of the main reasons PMOs fail. If you already have an executive who know the benefits
and importance of what you are trying to do, great! If not, one of the best ways to get them on your side is to show
them the benefits of moving to a project management system like Project Online. You can do this by showing them
the business problem that will be solved. You may have already done this to a degree when you were first
evaluating Project Online, but you can really find allies in the executive ranks if you are able to show them how it
works with your own data in a pilot environment. Benefit capture is essential in obtaining executive sponsorship.
Strong executive sponsorship can be helpful in addressing resistance users might have in moving from what they
are familiar with, to a new project management system, such as Project Online. Evangelizing and promoting the
benefits to other influential stakeholders, such as senior project managers, can also help in breaking any emotional
attachments that other users might have to the system you are moving from.
Build your team
Whether you are trying to establish a PMO in a large or small company, the following are responsibilities that need
to be addressed by the roles in your PMO:
Role Description
Drive the Project Online adoption plan If you are in the process of implementing Project Online, the
overall plan needs someone to drive it. Just like any project,
the adoption plan needs an owner to ensure that the required
tasks are staffed and completed.
Research project management needs This person will assess the project management requirements
of your organization. This person will need to talk with users
throughout the company and across departments to find out
how they currently manage projects, what their requirements
will be, and how these might be improved through the
implementation of Project Online. These requirements will
need to be expressed to the Project administrator so that they
can be properly implemented into Project Online. This person
must have good project management skills, but should also be
someone who is a good communicator. It is quite possible that
people in the company may be emotionally attached to the
process you are trying to move them from, so this person will
need to be able to deal with this by showing how the new
system will make life easier for them.
Training, documentation, and support This person will need to assess the skill level of the users, and
will be responsible for providing the training resources needed
to use the product successfully. This might include creating
role-based training for Project administrators, project
managers, team leads, and team members. While most of your
effort might be in putting together training for project
managers or administrators, team leads and team members
might find quick reference cards, cheat sheets, checklists or
short tutorials to be the most effective. You will also need to
find a way to provide in-house support for your users, and a
method to escalate more complicated issues through the
proper routes.
Liaison to IT-department Collaboration with your IT department is essential in engaging

them to assist in the sign up, setup, and configuration of
Project Online. If you are only in the process of evaluating
Project Online, this can typically be done by someone from
your IT department without too much trouble by looking at
the Get started with Project Online documentation.
The PMO will need to work with your IT department to
address these two areas:
-Office 365 administration: The PMO will need to work with
the Office 365 administrator for assigning users and licenses.
-Project Online administration: The PMO will also need to
work with a Project Online administrator on things such as
custom fields, resources, and timesheet configuration. They
might also need to work with the PMO to implement
processes into Project Online through workflows.
Some PMOs in larger companies also have project managers that can be assigned to help provide direction to
specific projects requiring assistance. This can range from advising the project owner, to actually taking over
ownership, given the scope of the project.
Create a mission statement for your PMO
All PMOs should have a mission statement. If you have already assessed the need for your PMO, this will be much
easier to create. Look at your company's existing mission statement, and try to create one that aligns with it as well.
It does not need to be overly complex, but just enough to provide all a basic understanding of why the PMO exists
and what its role is in your company.
Create a plan to build your PMO
After scoping out the tasks you need to build your PMO, you might want to create a high-level project plan for it.
Consider the building of your PMO as one big project, with associated tasks, durations, and assignments. Your
project plan will become more defined as you step through some of the initial tasks, such as assessing your
environment. The project plan helps to give your PMO a build schedule to keep track of what you have done, what
you are working on, and what you have yet to do in creating your PMO. For example, here are how several PMO
build tasks in a Project Online project plan might look:
Learn more about PMOs
If you do not already have a PMO, you may be intimidated a bit at the thought of starting one. Although your
company's needs and requirements will drive your PMO, you need to learn how to create the framework to
establish and evolve your PMO. Depending on your goals, you might want to research the various PMO process
and industry methodologies, or see which PMO model you might closely align with. There are many books,
training, and online resources available about creating and managing PMOs that can help you in your efforts.
If you are trying to set up a PMO and need assistance, you may want to contact a Microsoft Certified Partner or
Microsoft Consulting Services. We also have in-house consultants at Microsoft with excellent experience at setting
up PMOs for small, medium, and large companies.
What now?
So, are you ready to start your PMO? Hopefully, you've realized after reading this article that starting a PMO is an
investment that will be well worth the time and effort. It will require a lot of collaboration with people in your
company, and having an executive "champion" is essential. It will also require an investment in researching more
about setting up a PMO through the many resources that are available. And if you need help, you can turn to
Microsoft Certified Partners as well as Microsoft Consulting Services.
If you are in a smaller company, the scope of all of this may seem overwhelming. You may not have the resources
to hire people for each PMO role noted in the "Build your team" table, and you don't need to. Just be aware that
these are responsibilities that will likely need to be addressed at some point in time, and to a degree that suits your
requirements. Also note that the effort needed can scale to your company size and goals. A PMO in a smaller
company might only need to meet with a few senior project managers in their company to assess their needs,
versus multiple departments with varied requirements in a larger company.
Establishing a PMO can help drive your Project Online success, and using Project Online can drive your PMO
success. Good luck in your implementation!
Enterprise system best practices
This article is part of our "From the Trenches" collection. It describes operational best practices for enterprise
systems in general (including Microsoft Project Server). It notes how, although enterprise systems strive to provide
an easy-to-use interface at the user level, the technology and infrastructure required to provide it is often very
complex. This white paper then describes how this complexity requires you to use some basic best practices that
give you the best chance of maintaining a high degree of reliability in your enterprise system.
To download the Word version of this article, see Enterprise Management Best Practices.
To see more articles, see "From the Trenches" white papers.
Enterprise Management Best Practices

I mostly write about enterprise timesheet or enterprise project management systems, and the most common phase
of deployment that I talk about with such systems would be either the selection or configuration phase: talking
about the strategic perspective. This article is much more about operational practices and isn't specific just to
enterprise timesheet or project systems like Microsoft Project Server. Rather, it is about enterprise systems in
general, though the subject matter can certainly relate to almost all Project Server deployments.
When we encounter already-deployed Project Server systems or we talk to existing clients, we often ask questions
about how the organization deployed and has supported the system and its environment. When we got started in
the industry, these were simple conversations because the project software we would install would always live on
the end-user's PC, and care of the system was always a local concept. These days that's rarely the case. Enterprise
systems are simple at the interface or display level where end users can typically access the functionality through a
web browser in what looks like any other web page. As simple as these systems might be in front is as complex as
they might be in the back. The technology required to display that interface likely has numerous layers, depends on
multiple sources for the technology and infrastructure, and (if that's not enough) is probably being updated all the
time.
But, there are some basic best practices that can give you the best chance of maintaining a high degree of reliability
in your enterprise system.
Find an owner
In fact, we have to divide this into two owners because any successful enterprise system has both a business owner
and a technical owner. Only when the business owner is an executive in the IT department and the enterprise
system is primarily for that department can the owners be the same. So, let's take this in two parts:
Find a business owner
This person should be an executive level or senior management level person who has a vested interest in the
results of the project management system. The benefits that the system must deliver or the business challenges
that the system must overcome will have to be benefits and challenges that affect this executive directly. And,
before someone even says it; no, typically it can't be a committee or multiple persons.
The responsibility has to lay somewhere and that almost always means one person. This person might also be the
executive sponsor for the implementation of the system but might not be. Often the executive sponsor is not the
ultimate business owner of an enterprise system.
Even after the deployment project is over, the business owner will still own the system and, should they no longer
require it, either another business owner needs to be identified and must commit to the system or the system
should be retired.
Find a technical owner
For enterprise level systems, just having a technician available is insufficient. Remember, enterprise systems
depend on many layers of technology. The technical owner must be a senior enough manager or executive in the IT
department that he or she will be able to immediately interact with the owners of those other layers of technology.
That may include senior people who own the SQL Server database, the database server that SQL Server is
installed on, the application server(s) that Project Server is installed on, the networking, the Web server or server
farm, the Internet connection, the firewall, Active Directory and Exchange servers, Security servers or systems, and
the client-level operating system image. Someone senior must be able to represent this enterprise system to those
managers who control other aspects of the environment.
Be purposeful
Make sure that Project Server a) has a purpose and b) is fulfilling its purpose. Sound obvious? It's not. All too often
enterprise systems are acquired for the wrong reason, and it falls to someone in IT to look for a purpose to apply
the system to. The person signing off on the business purpose for the enterprise system should be the business
owner, though others might be involved. I always ask such executives a question I've used for years, "What
business decision can you now not make or can you only make with great difficulty, the making of which will be
enabled by the deployment of this system?" Once the business requirement (note that I didn't say the desired
functionality) is settled, make sure that the enterprise system is actually fulfilling that requirement. I meet a lot of
people who have a shopping list of functions but little understanding of what they are trying to accomplish with
them.
As the organization evolves, make sure that the business owner comes back to this basic concept. Just the
deployment of an enterprise system like Project Server can fundamentally alter the business it is deployed into, so
it's not surprising to find that the organization's requirements for a system can change.
It is common to come into an organization several years after Project Server was adopted and deployed only to
find it impossible to locate someone who knows why it is important to the organization. The system is in use to be
sure. It is being carried forward on sheer inertia but the purpose has been lost and the executives who benefit from
it every day don't realize where that benefit is coming from.
Get it into your enterprise architecture
Several years ago I remember going with one of our technical staff to an upset client's location. The instance of
Project Server they had installed themselves was causing all kinds of trouble. While there in person, we asked to
interview a number of technical personnel, tracing the system back through its layers. When we got to the database
layer, we were stunned. Instead of being one of the organization's standard database servers, the SQL Server
version on which they'd installed the system was on an end-user's PC. Every time they rebooted, turned the PC off
or installed something, the database would become unavailable. This affected literally hundreds of end users.
The organization was a large one so there was no lack of enterprise servers or infrastructure to rely on. In this case,
the problem was easily fixed. It was a good lesson though. Is the system that you are deploying being woven into
the existing corporate infrastructure on which the organization may have spent an enormous effort getting stable,
being reliable, and being secure?
Back it up
I know. This is silly, right? Amazingly and unfortunately it's not. Enterprise systems can be notoriously complex to
back up as they may depend on multiple aspects of the system to be backed up at the same time. There is the basic
data of course, but also the metadata and configuration data of the implementation. And any related data from
ancillary systems that might have to match the system may have to be part of the same backup scheme. When we
think of Project Server, we have to think of backing up not just the project database(s) but also the SharePoint
Server database. In Project Server versions before 2010 we might need to back up the Global Template. Even now
there might be elements of templates that are on individual PCs.
And just backing up isn't enough. When the systems change or are upgraded, do a database restore at least once. I
remember years ago being with a client whom we had helped design a backup strategy for. He shut down the
server, pulled out the hard disk, put in another hard disk and then looked at us and said "There. The hard disk just
crashed. That's a newly formatted hard disk. Please restore my Project Server." I was taken aback, but more so
because I realized how good a request it was, and the more I thought of it, the more I realized how shocking it was
that no one had ever made the request before (or since). So, do a restore test at least once. We were able to restore
that system by the way, but it didn't go back in as cleanly as we'd suspected it would and we had to update our
backup procedures.
Staging/Production
"All the world's a stage, and all the men and women merely players," said Shakespeare a long time ago. In this case,
the stage is more about staging and that's key for any enterprise system. Once the system is in production, you will
want to try new configurations, add new customizations, try new reports, links, fields, and other changes. You will
have updates and upgrades and all of these should be tried first in a staging or development environment before
they are inflicted on the users in the production environment. Something as basic as a browser update or a
database update can throw enterprise systems for a loop, so make sure you keep and maintain a staging
environment that's separate from a production environment. In this day and age of virtual servers, this may be
easier than it might have been in the past. An entire environment can now often just be cloned from the production
system, but that may be easier said than done depending on how you have deployed. Remember lots of different
parts of the technology puzzle may be referenced even though you have copied an entire server.
Monitor, monitor, monitor
There are lots of points of oversight that can be used to monitor an enterprise system. First of all, making sure
Project Server is available to end users is critical, and ensuring that the appropriate technical staff are notified as
quickly as possible if it is ever not available is also essential. Thankfully, there are many tools on the market for
ensuring that the system is functional and available that can automatically notify technical staff even if end users
haven't noticed the problem yet. But there are other aspects of monitoring that are also important. It is good to
keep a watch and a log of the health of the application, including the amount of memory it is using, the amount of
the CPU (s) it is taking up, any errors that the system may have reported even if it recovered from them itself, any
restarts of the server required, and the relevant health of other elements of the technical infrastructure. Knowing,
for example, that IIS is having technical issues might be very important to maintaining the availability of your
enterprise application.
Even small changes are changes
The technology on which Project Server is based changes day by day. It's impossible to avoid all of these changes.
The Windows Server operating system often receive updates every few days, SQL Server can receive updates
every few weeks. Individual Windows client operating systems, their virus scanners, firewalls, and Internet Explorer
and its add-ins get updates on a regular basis. Any part of the chain between the data and the end user is a
potential point at which the application can break down, so create a structure to manage changes throughout the
entire stack of technology.
This can be a challenge, as many different enterprise applications may depend on similar aspects of the stack. We
had one client who innocently updated Project Server awhile back only to find that the entire SharePoint Server
environment was brought down. Clearly there had been an error in how the Project Server / SharePoint Server
update had been applied. While there were complete backups and no data was lost, the upgrade process did not
have an instant rollback provision and thus the effects were devastating, as they took days to reverse.
At another organization, we had a client who had updated another enterprise application to find that it absolutely
required all users to upgrade their browser version only to discover that other enterprise applications already in
use at the company did not support the more recent browser version. It was the proverbial rock and the hard place.
In the end, they had to roll back the upgrade of the enterprise system and wait until all the enterprise applications
could move forward with a new browser upgrade.
Sometimes it's better to look integrated than be integrated
Sales demonstrations always make the integration of multiple tools look so easy. Hey presto, the data starts here
and ends there! Establishing a link between highly flexible tools like Project Server and other enterprise systems
like Finance/ERP is tough enough, and we always recommend that both systems be in production and stable
before any links are established. Once they are underway, however, it's even more important to monitor any
changes of the two systems with a mind to making sure they will continue to link properly.
With any upgrade of either system, there may be data changes, structure changes or different technical
requirements. There may also be new features and benefits that are possible, but make sure the existing linking
functionality is tested in your staging environment before it's rolled out to production.
Document, document, document
The people who were there when Project Server was selected and deployed won't be in those roles forever. In fact,
if they did a great job, they'll be off managing the next enterprise deployment that the organization needs. So
documenting the configuration decisions, the projected benefits, the operating expectations, and parameters that
were used to make those decisions is essential. On the future, others will be looking at this system and scratching
their heads saying, "What were they thinking?" Make sure you tell them.
Enterprise system documents should be living documents that are updated with every upgrade, each change in
business or technical owner, or any major change in either the operating structure or the business requirements.
Look before you leap
It's the advice we give people diving into a murky lake for the first time. Is it shallow? Are there rocks just below the
surface? Enterprise project management systems like Project Server can indeed bring complex data elements into
one place where decisions based on that data can be more effective and the benefits of those decisions can make a
profound difference to an organization. But you need to do your homework to ensure that you are operating your
enterprise system in a way that you can get the benefits you need without exposing your organization to costs and
risks that can quickly wipe out the value of those benefits.
About the Author

Chris Vandersluis is the president and founder of Montreal, Canada-based HMS Software, a Microsoft Certified
Partner. He has an economics degree from McGill University and over 30 years experience in the automation of
project control systems. He is a long-standing member of the Project Management Institute (PMI) and helped
found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG ). Publications for
which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's
PMNetwork, and he is a regular columnist for Project Times. He teaches Advanced Project Management at McGill
University and often speaks at project management association functions across North America and around the
world. HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a
Microsoft Project Solution Partner since 1995.
Chris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca
If you would like to read more EPM -related articles by Chris Vandersluis, see HMS's EPM Guidance site
(http://www.epmguidance.com/?page_id=39).
The project management system maturity model
This article is part of our "From the Trenches" collection. It describes how as organizations mature, they can be
more effective in the use of their project management systems. It describes how it might be more effective for
companies to elect to use only certain aspects of a new project management system to a level with which they are
comfortable, even though they are tempted to use every feature that is available to them. As the company
continues to mature, it can become more advanced in its use of the features that it needs to use.
The Project Management System Maturity Model

The Project Management Maturity (PMM ) model is a pretty hot topic these days. There are waves of consultants
who are making a good living helping organizations assess their "project maturity level" which is pretty much
always displayed hierarchically with more mature always shown as being better than less mature. Proponents of
the concept say the PMM model shows the capabilities of an organization to manage projects. There's a whole
conversation to be had about how organizations become more effective and I'm not sure just climbing the Project
Management Maturity model necessarily gets you there. But that is a subject for another day. Whether or not
you're a fan of the PMM model, there is another kind of maturity model that I've seen with organizations who use
Project Management systems.
When we work with organizations who are deploying a project management system, it's very common to find that
the desire of organization is to reap the benefits of every single element of the new system they've just had
demonstrated by the vendor. The client sees reports and screens and workflows and functions that they've only
ever dreamed of and they imagine a world where all that functionality works as smoothly in their organization as it
does in the sales demonstration. It is usually unclear to the client that the demonstration data and demonstration
configuration that is being demonstrated was carefully developed in order to showcase as much of the product as
possible. In the case of Microsoft Project and Project Server, this may extend far beyond the single product to
include the entire stack of technology.
The client sees screens that initiate from Windows SharePoint Services or from Microsoft Office SharePoint Server
forms. They see functionality that touches Active Directory or SQL Server Reporting Services. They might see
workflow from BizTalk Server or Windows Workflow Foundation and displays that come from PerformancePoint.
The flow of data might follow a storyboard or a use-case scenario that makes understanding the potential benefits
easy but understanding the underlying technology more difficult.
When we arrive to actually deliver the functionality the client is interested in, we need to temper their desires to
deploy everything at once with a reality check. The client needs to decide how it wants to do business before we
can even consider configuring such functionality and whether it can be delivered out of the box, with configuration
or with customization effort. There are some clients who are insistent that they deploy every aspect of the
functionality they've envisaged and are prepared to dig in and do the design, training, learning and development of
that solution as well as find the funding both in time and money to deploy it, but these organizations are the
exception.
What is much more common is that the client elects to deploy the aspects of its new project management system
to the level that it is already comfortable with. As the organization becomes more knowledgeable about both the
system and the underlying business processes, it will demand more and more of the system; becoming more
'mature' as it progresses. It's a natural progression.
As the organization's understanding of a project management process that can be automated evolves, its demand
for that automation evolves also. This natural progression is just like the Project Management or Capability
Maturity models. Knowing that organizations will most likely evolve along these paths has made us very effective
at knowing where to put our efforts in making an organization effective. We tend to focus on those project system
areas that we know have a better chance of adoption and of giving a return on the investment given the project
system's maturity of the organization. Of course no two organizations are the same, so chiseling this knowledge
into a tablet isn't a good plan. It's just the most likely progression based on our experience with many companies.
In our experience, the natural evolution of use of a project management system comes in five basic areas, although
the sequencing of them has shifted in recent years thanks in large part to technology. Let's talk about the five basic
areas to start with, and I'll cover some of the new shifts that we've seen over the last few years nearer the end of
this article.
1 - Planning. We almost always see Planning as the first wave. Some organizations never get beyond this.
They make a basic schedule, bronze the GANTT chart, and then mount it on the wall of the project team's
office. People refer to the plaque from time to time nostalgically as they remember the fine state of their
schedule just before the project started.
While I'm being a bit cruel at those who are only using their expensive project management software to make a
bar chart, there is certainly value from doing so. Creating an organized schedule tends to make the project
participants think about how the work should be put together and is much more effective than doing nothing or
just making a spreadsheet list.
2 - Tracking. Next in line in our experience is typically tracking. An organization which is a little more "mature"
in the use of their project management system will not only plan, they'll track their schedules, advancing them
on a regular basis with the progress to date and even look forward with projected schedules as the plans
advance. For many organizations, stopping here is effective. They're planning in their project management
system, and then they're working the plan by updating it regularly and even giving useful reports to
management.
3 - Resource Management. Once planning and tracking are handled, organizations tend to look to the
resource management problem and how it might get resolved by using the project management system.
Resources can have many aspects, as I've discussed here before, but at the most basic level, resource allocation
(assigning the work to resources) is a big step, followed by resource analysis of some kind.
4 - Cost Management. Cost management is the fourth typical area and many organizations never get here. At
a basic level, having a cost estimate broken down by phase or better yet by task in the project is a good costing
start. Tracking the actual costs either by hours or by dollars is the next level.
5 - Advanced. I'll put a fifth area here for "Advanced" subjects for what might be a wide range of topics that I
haven't put in the other categories so far. It's not that they're not important but that when you get to the fifth
wave of evolution in an organization, it can go a lot of different ways. So, I'll put risk analysis, document
management, and automated workflows in here. There are also advanced areas in each of the other four areas
I've discussed so far.
Each of the elements I've discussed so far could be extended further and often is as the organization's project
maturity and the understanding of the automated aspect of its project management environment increases.
For Planning, the progression can go to multi-project integrated schedules with inter-project links or program
management with sub-projects.
For Tracking, the organization usually advances from simple percent complete progress, which is typically the
lowest quality of tracking data, to remaining duration. Tracking might also extend to timesheets to give an exact
value of hours worked against the original plan by person.
In the Resources area, we see going from just allocating the tasks to resources to tracking resource progress
usually with a timesheet and then moving to the most requested aspect of EPM, Resource Capacity Planning. For
some organizations, Critical Chain fits in here also, merging the resource and schedule information into one
advanced algorithm.
For Costs, we usually go from the basic budgeting to tracking actual costs along with hours and time to get budget
versus actual variance, and from there to Earned Value tracking, as is done in the Defense and Aerospace sectors.
Even the Advanced area has advanced topics. The most popular among these are Monte Carlo Risk Analysis and
integrating project management methodology (particularly in the IT sector).
Most organizations progress with all five of the basic elements from the left side of the graphic above in the order
that I've just described before turning to any of the advanced areas. Some find that their particular project
management challenge means focusing on one element ahead of others. What is extremely difficult and rarely
successful is trying to be more mature than you are.
It's very common, for example, for an organization to desire Resource Capacity Planning, yet when you look at the
skills and experience of the organization, you find that the building blocks of creating a resource capacity planning
system are missing. I often use capacity planning as an example of why knowing where you are on the Project
Management Systems Maturity model is so important. In my experience, this is the single most requested benefit
from EPM systems and yet it is almost the last benefit I can deliver. This is because resource capacity planning
requires so many other elements to work first. In order to deliver projected resource requirements versus
availability we first need:
Project plans we can count on
Projects tracked with accurate progress
All tasks to be allocated to resources
Complete and accurate resource availability
All non-project work to be quantified and tracked
Complete compliance by project managers and department managers on work completed, work projected,
and changes in resources.
Whew! It's no small list, and the corporate culture required to comply with such an environment often requires
change management on a big scale. So, we turn back to the Project Management Systems Maturity model and
clients can make a roadmap of what they need to accomplish.
This is not an exhaustive list of course. We can easily make a third column and then a fourth, but I've not done so
here because from this point the most common progression is less clear. Each organization's project management
requirements will dictate the interest in moving forward in a particular area.
I promised earlier in the article to discuss something that has changed in the last few years. The model I've
described above has stood up for quite some time, but in the last couple of years, movement in the IT industry has
made a significant shift in another direction, and that has everything to do with collaboration.
At one time in the project management software industry we were very algorithm-centric. Everything stemmed
from the critical path schedule, we thought. In the last few years, though, a few things have changed. First of all, the
availability of people through the ubiquitous Internet or telephone technology has made it even easier to assemble
and communicate with your project team. This has helped change who is on a project management team. While
once we would have thought of project team members being people deep within the organization, working in a
small windowless room with desks surrounding a massive plotter, now we think of project team members
throughout the organization.
Team members include those doing the work, of course, but might also include the executive sponsor, the
department resource managers, the users, the marketing department. It's now not at all uncommon to find that the
project team extends not just beyond the building's walls but well outside the organization itself to include sub-
contractors, prime-contractors and even the client. Sub-contractors may not be in the same time zone or even the
same country. All of this has made communication a key success factor for projects in many different types of
industries.
That has caused some organizations in industries like R&D and IT, for example, to look at a Project Management
Systems Maturity Model that progresses quite differently:
The first element in these organizations is to create a communications plan, and that's almost always based on
collaboration technology like SharePoint Server. These organizations find that from a centralized perspective they
can get more benefit from getting their extended project management team to collaborate and communicate than
from any centralized planning. The meteoric rise in popularity of SharePoint Server is a testament to how much
pent up desire there is for getting people to work together.
The progression from a basic communications plan then often goes to document management—one document of
which might well be a project schedule. It's turning the classic enterprise project management progress on its head,
but you can see for some organizations how attractive this might be. Get a handle on the contracts, documents,
emails, meetings and other communication, and efficiency increases very quickly. Don't get a handle on
communications, and the loss of efficiency might well be serious.
From document management, it's a short step to managing issues and doing change management—which for IT
and R&D means managing one of the most potentially damaging aspects of a project.
Surprisingly, timesheets come next. In fact, sometimes timesheets come even earlier. When our organization first
got started in the timesheet business with our TimeControl product, we were quite certain that organizations who
needed a timesheet like ours were those that were already mature enough in their planning and tracking process to
be able to take advantage of it. You can imagine our surprise to find that many organizations want to deploy an
enterprise timesheet before they deploy an enterprise project management system. When you look at the change
management challenge of each it becomes clear why. Most users will adopt a timesheet grudgingly but quickly.
Getting a 1000-person organization to accept a centralized timesheet system takes a matter of weeks. Getting the
same 1000 users to accept a centralized project management system can take from months to a couple of years.
So, even though the centralized planning isn't established, the organization can still get tremendous benefit from
centralized timesheet data.
Finally, these organizations turn their attention to the core project planning exercise. This is not to say they haven't
been doing project scheduling so far but it won't have been highly centralized.
Just like the first Project Management Systems Maturity Model, each of these elements can carry advanced topics,
too.
Communications plans often progress to more integrated communications systems, including instant messaging,
email integration and more.
Document management often progress to workflow management and forms integration.
Issue management usually evolves to management of lists of all kinds and an integrated change management
process.
Timesheets evolve from task timesheets to links with Finance, Payroll, HR and ultimately links back to the
enterprise project management system for auditable tracking data.
Planning and Resource Management tend to evolve just like my classic Project Management Systems Maturity
model.
There's no "right" way to advance in your use of your project management system, nor is there a "wrong" way. As
I've said in these columns before, what is most important is that you look first at what you need to accomplish in
order to be more effective as an organization and from there design the solution to that challenge. What is
important is knowing you have the building blocks from the basic elements before you start building something
more advanced. I'm often heard saying that we need Project Management 101 before we move to Project
Management PhDs.
Remember that the use of a project management system is only one aspect of a possible solution and it's up to you
to decide how "mature" you should be and in what areas in order to make the management of your projects more
effective.
About the Author

EPM: Centralized or decentralized?
This article is part of our "From the Trenches" collection. It describes how organizations need to understand the
problems they are trying to solve when deciding on implementing a project management system. Sometimes
deploying a centralized project management system may not be the best answer.
To download the Word version of this article, see EPM -Centralized or Decentralized?.
EPM - Centralized or Decentralized?

I've been a proponent of Enterprise Project Management since I first entered the project management industry in
the early 1980s. You'd think, then, that I would always vote on the side of centralized project management, but that
isn't always the case. Let's discuss for a moment just what we mean by Enterprise Project Management.
EPM can mean a lot of different things to different people. I've already discussed in other articles in this column
how the focus of an EPM deployment might be document management for one organization and integrated
schedules for the next. Enterprise Project Management has at its core, however, the notion that people must
interact with each other in the project management exercise. That means that the project manager and/or project
management team don't work completely independently. But does that mean that the only way to achieve this
"interaction" is to have a centralized project scheduling system? Not necessarily. For some organizations, the
project management challenge might be an inability to produce summary, enterprise-wide project management
reports due to projects being all managed on an ad-hoc basis. In this case, EPM might be achieved just by having
project standards that are shared between all project management personnel. That might best be achieved with a
central pool of templates, training materials, documents, and report standards that everyone can use. Perhaps a
simple SharePoint site would suffice.
For some organizations, the project management challenge might be ineffective personal schedules due to a lack of
communication between resources about what they're working on and what their next focus is. In this case, EPM
might be achieved by improving team and inter-team communication. The tools could be as simple as a shared
calendar, Instant Messaging, or a shared portal where people could list what their priorities are.
In some organizations, the project management challenge is just getting progress on the programming
development projects. If that's the case, then the tools already present in a product like Visual Studio Team Services
might suffice. It's quite common in programming projects to find that many tasks can be completed in almost any
order, so the rigors of Critical Path Scheduling might not even be appropriate depending on the type of
development being done.
I can remember a number of years ago working with the maintenance department of an airline. The staff were
allowed to choose their own schedules at the start of each month and if this wasn't coordinated (as was often the
case), it was possible to arrive to manage a shift only to find out that no one was working. Their project
management challenge wasn't "When will the work get complete?" it was "is anyone coming to work?" In this case,
EPM was achieved by implementing a shift scheduling tool.
Even when we focus the EPM challenge to project schedules, it's not immediately obvious that deploying a
centralized project management system is the only or the best answer. It's worthwhile to ask what interaction the
project management personnel need to have with each other. If they must collaborate on a regular basis to resolve
resource conflicts, to see what other priorities in the organization are coming up, or to see how the progress of one
project will affect another, then looking at a tool like Project Server makes perfect sense, but often I end up
interacting with organizations that have not even asked this question of themselves.
In some organizations we find a tiny number of schedulers and a large number of resources. Even in a good-sized
organization, this can be the structure depending on the industry and type of projects being accomplished. Not that
long ago I met with an organization that was sure they had picked the right solution for their EPM challenge. They
asked to me to articulate the solution but, as usual, I asked that they first articulate their project management
problem.
By the time they were done describing their environment on a white board it was apparent even to them that the
solution they'd chosen wasn't going to solve their problem.
In this case, the problem was a lack of project progress that was being reported by a large pool of subcontractors.
The client determined that what they'd really need to do would be to impose a time and billing type of timesheet
on their subcontractors. The Program Director was discouraged. "We'll never be able to get that into the
subcontractor contracts," they said. Fortunately, a member of the Finance Department was present. "You know,"
that person replied, "a clause that requires them to fill in the timesheet of our choice is already in the subcontractor
contract." Problem solved.
The idea of walking through the problem before coming to the solution is one I talk about often around here but
it's a tough one to adopt. Logical thinking would dictate that the order of determining an automated solution would
be:
1. Identify the problem
2. Define the solution
3. Determine whether to (and, if so, how to) automate the solution
Automated solution demonstrations on web sites, videos, and elsewhere make us forget that. We don't look for a
solution, of course, unless we have some kind of problem, but the automated solutions look and sound so
compelling that we end up doing this:
1. Choose the automated solution
2. Make the problem deploying the solution
3. Solve that problem by defining how the automated tool can be applied to the solution
4. Try to remember what the original problem was
The new problem becomes deploying the solution for quite some time and then weeks, months, or even a couple
of years down the road someone from upper management asks when the original problem will be solved and
everyone looks at each other rather surprised. It was easy to forget about.
Over the years I've recommended all kinds of possible automated solutions. Oh, Project Server has been one of the
options of course, but I've also recommended a combination of Microsoft Project Pro and SharePoint Server. I've
recommended using a combination of Excel and Outlook. I've recommended using third party timesheets with
Project.
I even once recommended using a big white board. Honest. The organization was one I'd done business with for
years. The person in question was in a real-estate role and had to renew long term leases in real estate. When I
asked what the problem was, it was clearly a scheduling issue. The person had missed a few deadlines that were
important and was sure that an enterprise project management tool would fix the problem. The organization had
already asked for reports to be distributed to several executives so that future deadlines wouldn't be missed. "How
many users would there be?" I asked. "Just me," he replied. "How many of these projects are there at a time?" I
asked "Seven or eight," he replied. "And how many of these deadline milestones do you manage for each project
"It's very complicated. There are about a half-dozen deadlines for each one," he told me.
It was already clear to me that we shouldn't be installing a big centralized EPM system for this poor fellow.
"Why not just put up a big white board in your cubicle and use some colored markers for the different milestones?"
I asked. "You could use blue for the first one, green for the second, red for the last, etc."
He took copious notes, fascinated by the concept. I left the firm knowing that I'd not sold any services or product
that day but that I'd left the person disappointed that he couldn't deploy the system he'd envisaged. On the way
home my phone rang in the car. It was him. "Could you explain the different colors for the white board?" he asked.
Figuring out what problems you're trying to solve before you design the solution and before you choose how to
automate it doesn't just save money. It can save an enormous amount of time spent working on elements of the
organization that didn't have a problem that needed solving in the first place.
When the problems you're trying to solve can be best solved with centralized enterprise project management
software, then nothing else will really do, but the focus you'll have gained by articulating the problem will help even
there. Your deployment team can create success metrics that allow the project to be declared a success when the
problems have been resolved. Centralize or decentralize? Enterprise Project Management can be achieved with
either.
About the Author

This article is part of our "From the Trenches" collection. It describes some of the common challenges you may face
when deciding to use dashboards in your EPM environment. It describes how the prettiness of a professional-
looking dashboard might sometimes hide the need for users to look into the quality of the data — "pedigree" and
updated data, for example. It mentions how data for dashboards should go through an approval process to ensure
high data quality and completeness. It includes a few techniques to prevent people from skewing data under their
control to misrepresent the data that is displayed in the dashboard. And finally, it states some basic rules you
should take into consideration when you create dashboards for EPM.
To download the Word version of this article, see Dashboard directions.
There's no doubt about it. Dashboards are all the rage. Whether it's a bar chart, a histogram, a pie chart or a traffic
light warning view, executives seem addicted to the instant response of a dashboard.
With more and more pressure in our business culture to deliver faster and faster results, the demand for
dashboards is not likely to abate anytime soon.
The project management software industry is a poster child for this kind of display because project management
data is perfect for dashboarding. When we look at what kind of data would be required for dashboards, we look at
several qualities:
Is it grouped together in ways that it can be displayed and understood?
Is it timely?
Is there some approval or vetting process for the data?
Is there numeric or time/date data that can help make variances?
That's exactly what we find in project management data from an Enterprise Project Management (EPM ) system
like Microsoft Project Server.
No surprise, then, that most EPM systems including Project Server have some dashboarding capabilities. In the
case of Microsoft, the capabilities come courtesy of SharePoint Server in the Business Intelligence Center. This type
of system can look into SQL -based data and generate an incredibly wide range of graphical displays. And, just like
a kitten, there's nothing an executive likes better than a shiny new toy. The desire by senior management for instant
feedback from projects can be so severe that many Project Management Offices are pressured to deliver the
display before the underlying data is even ready.
"Can you make us an EPM Dashboard?" I was once asked by a senior IT executive while I was in their offices
helping to design their EPM environment.
"Sure," I replied.
"Could we have it by Friday?" asked the exec to my surprise.
"Um, sure," I answered. "Well, not this Friday. But a Friday sometime in the future."
He wasn't at all amused by my humor.
It was not an unintelligent manager, but it underlies the pressure such people experience to enable rapid decision
making.
Dashboards are so visually stimulating, we often forget that they are supposed to represent something that
generates the display. So, before running out to find out how to make a dashboard and before you start spending
too much time picking out color palettes of what color your icons should be, let's go through a few common
challenges in the dashboard arena.
Wizard of Oz Syndrome
Remember the Wizard of Oz when they finally pulled back the curtain and found just a regular guy who was
pulling the levers and turning the dials to generate all the impressive "magic"?
Beautiful displays that are driven by human intervention are something we see all the time in dashboards. A great
deal of work goes into the design and presentation, including great graphics, great icons, great colors and even
animation and sound effects. The problem is that no one has traced a path between the data and the dashboard
and the result is that someone has to sit at a desk and decide manually what indicator to make which color.
When looking at an existing dashboard for the first time, it's always worthwhile to ask to see the raw data that
made up the display. "What does this mean and can you show me where this indicator is driven from?" is a key
question. Do a mini-audit of a few indicators, tracking them back to their component data.
The same principle holds if you're designing a dashboard. For every indicator, there has to be a trail back to some
source and it is best if it's documented. If the dashboard is driven by Bob filling in a spreadsheet with how he feels
about the projects, just have him tell you. It'll be faster.
Measure everything
"If we can measure it, we will put it on the dashboard," seems to be the mantra of some dashboard designers.
It's easy to get caught up in the technology of dashboarding and there's a certain visceral thrill when you locate
some data that seems measurable and understandable and you make an indicator out of it. Suddenly instead of a
boring old list of costs, you've got thermometers filling up with red or tachometers revving into the red-zone or
arrows in different colors. Don't think this is fun? Give it a try in Excel for a half-hour by using the new Conditional
Formatting functionality of Excel 2010 (or Excel 2013).
Problems happen when someone who's making an executive dashboard gets so caught up in their ability to make
an indicator that they don't stop to look and see if they should be making it at all. It's not always "how do you do
it?"; sometimes it's "should you do it?"
Once there's so many visually stimulating indicators on the page that it looks like the dashboard of the space
shuttle, you know you're either going to need years of training like an astronaut or you're going to need to make
life simpler.
Here's a basic rule that should make for fewer displays: Every indicator needs a potential action; every one. So, if
you have a traffic light indicator and it's red, then there needs to be an appropriate action that someone is
supposed to take when that happens. It might be a simple "When this light turns red, a project manager must show
a detailed report to the head of the PMO." Regardless of what the action is, there needs to be one.
Half-baked plans
You wouldn't eat a cake that only had half the ingredients, especially if you didn't know which half were missing. On
a dashboard, how do you know you have all the data?
Let's take an example of looking at resource capacity reporting. The resource traffic light has become red for IT
(isn't it always?) Now management wants to look at the problem and when they look at the detail, they see the
obvious answer. The indicator must be red because IT is so over-staffed!
This first histogram shows the problem. The red line shows the capacity of the organization. The stacked
histograms show the combined requirements projected by adding the requirements of all projects together. If this
is the dashboard that we present to management, the decision to either accept a lot more work or to reduce our
staffing levels immediately would be obvious.
Ah, but hold on a moment. Just before the reduction in staffing levels plan goes into effect, it occurs to someone to
check to see if all projects were represented in the dashboard view.
They were not.

There were some projects that appeared in the legend but no results for these projects were displayed in the
histogram. Where were the results? Perhaps these projects were not yet published. Perhaps the full project scope
was still being determined. Perhaps the resource requirements had not been defined at the appropriate level. When
the data is revised, we can see in the second histogram that in fact, there is now more work than people and we
should be considering hiring more staff, adding some contract capacity or delaying some projects into the future;
the exact opposite decision we would have made from looking at the same view with only part of the data.
The problem is not the design of the dashboard; nor is it the quality of the data. It is the completeness of the data
that is the problem. In this obvious example, we can see the problem with our own eye, but imagine a project
environment with hundreds or even thousands of projects or sub projects in the same dataset.
Making a decision with only part of the data is often going to result in an inappropriate decision. Making a decision
where the decision maker doesn't even know the data is incomplete is, at best, disempowering to them.
We can solve this with a review of the data in some kind of approval process or, perhaps, with the combination of a
validation process and a database-based indicator that tells us that we are only looking at a partial image of our
indicator.
Best before dates
If you're like me you reach into the refrigerator and grab the closest cheese to you, but shouldn't you be checking
the "best before" dates? While we're on the subject of the source data that made up that pretty picture on your
dashboard, do you have any notion of how old the data is that is generating that indicator?
It's not uncommon to do an audit of a dashboard indicator only to find that the data that originates the indicator
hasn't been updated in a long time. It's often a sharp executive who picks this up in a review meeting. This is the
kind of person who brings not only their notes from the last review meeting but also copies of all the handouts that
were given last time and their practiced eye looks over the last handouts and the new handouts and compares the
data.
Identical indicators mean either that things haven't changed (unlikely in most project environments) or that the
data hasn't been updated (much more likely in a lot of organizations). For those in Finance who often live and die
from the results of their spreadsheet, or a massive spreadsheet farm made up of many sub-ledgers, this is a
common error. Project managers and those who look at project data may be less likely to catch such errors without
stringent care.
The worst case scenario is one where some of the data has been updated and is current and some of the data has
not been updated at all. So, perhaps the forward plan was updated on half the projects, and the actuals for the last
period were posted to those projects but the other half of the projects did not have actuals posted or have their
plan updated. If decisions are going to be made on the dashboard view or the resulting data that it came from, how
current that data is should be displayed somewhere.
This kind of problem can also be resolved with some basic checks and balances in the data which can then be
displayed on the dashboard. For example, a simple test could ensure that:
1. All timesheets were collected for the displayed period; and
2. the total timesheet hours collected are roughly equivalent to the total hours displayed.
Data pedigree
The prettier the display, the less likely we are to ask, "Where did that data come from and how reliable is it?"
There's something about neatness that counts when we put the data into a professional looking graphical display.
For those who are creating data from a database, they can often be kept at a distance of where that data arrived
from. A graphical designer finds a couple of useful looking fields and ways to calculate indicators from them and
can easily neglect to ask if these fields are populated through a validated process, with any kind of oversight, by
calculation or if the data is not considered "corporate quality" by the people entering it.
Perhaps we're working on a software development project and a list of outstanding and newly added software
issues and there is a great SharePoint list of issues that are created by the QA department as a piece of software
nears a release date. This kind of list can be a key indicator of how ready the software is for release. If, however,
many different groups are using the same list for new functionality ideas and enhancement requests, just counting
the list of issues will give an inappropriate indicator because the list has become polluted with data used for a
different purpose.
Data that is going to show up on an indicator on a dashboard has to have some process and some validation of its
quality.
Are we looking at the whole picture?
Let's go back to that dashboard traffic light report and look at the IT line again.
Let's imagine that IT has red lights for both the schedule and cost indicators on a particular year-long project
because it's June and both indicators are off by more than 20%!
The Chief Financial officer has looked at the detailed results already and he's quite upset. The January - June
actuals show the tale:
($,000S) JAN FEB MAR APR MAY JUN
Budget 80 100 120 120 120 120
Actual 100 120 140 140 140 140
Variance 20 20 20 20 20 20
Cumulative 20 40 60 80 100 120

Variance
So far the project is already $120,000 over budget and it's only half-over! At this pace, says the CFO, the project
will cost 18% more than its original $1.3 million budget and perhaps they should cut their losses and cancel the
project.
If we look in more detail, however, the picture looks very different. The projected scheduled and costs until the end
of the project look like this:
(,000 TOTA
S) JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC L
Bud 80 100 120 120 120 120 120 120 120 120 100 80 1,32
get 0
(,000 TOTA
S) JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC L
Actu 100 120 140 140 140 140 120 100 80 40 0 0 1,12
al 0
Varia 20 20 20 20 20 20 0 (20) (40) (80) (100 (80) (200

nce ) )
Cum 20 40 60 80 100 120 120 100 60 (20) (120 (200

ulati ) )
ve
Varia
nce
Now we can see more of the story. The project is running faster than had been anticipated. In fact, it is going to
finish in mid-October instead of in December and is projected to finish $200,000 under budget.
This is the challenge with simple dashboards and how they're interpreted. The dashboard was completely accurate
but the reason it was red was good, not bad.
Dashboard indicators need to alert executives that action needs to be taken and where to look, but they should also
lead that same executive to the more detailed data that will show the whole picture.
Gamers galore
Ok, so now you have a few things you can do to make sure your dashboards do not mislead management to
inappropriate decisions, and that's a huge step. But, be advised, as soon as dashboard-type indicators are made
available, people will use them to their own advantage. It's completely understandable that people will game the
process if they can by skewing data under their control to have them not look bad.
There's no preventing people from trying to game the process, but there are a few techniques to avoid the events
of these gamers:
Change the process
You can make it tough to game the process by changing it all the time; trying to stay ahead of those who think they
have the process figured out. Everyone in the search engine business of Search Engine Optimization knows this
one but the challenge with this is the enormous amount of work it takes to keep changing the process and training
everyone in the changes.
No carrot, just stick
Another option is to discipline those caught gaming the process. This is a tough one. People who outright lie about
their data should get into trouble, but punishing those who are just finding loopholes in the process is typically bad
for morale.
Checks and balances
This is typically the most powerful tool against gamers. If you have data from different sources that has to balance
against other data, it becomes extremely difficult for someone to manipulate just the data under their control and
defeat the dashboard process in their favor. Of course it's not always possible to find such checks and balances
within the data, so vigilance is always a good thing.
Some basic rules
Ok, let's wrap up some of what we've said. Creating powerful-looking dashboards is technically not difficult but
there are some basic rules you can implement in your dashboard design and project management process that can
ensure the decisions that come out of such dashboards are appropriate and effective.
Here is a summary of some of the basic concepts we've discussed above:
Indicators must trace back to source data
Make sure that indicators aren't just the manually entered opinions or feelings of someone, but that they actually
represent something in the detailed data of your environment.
Every indicator needs an action
Every indicator needs an action; every one. Regardless of what the action is, there needs to be one. This will likely
also help with keeping the number of indicators to a reasonable level.
The data must be complete or show that it's not
Make sure that it's is clear from the display that the data is either complete or incomplete so that inappropriate
decisions aren't made while looking at only a partial picture.
The display must show its timeliness
If it is possible to have some data updated and other data not, then the refresh date of the data must show up on
the dashboard in a way that inappropriate decisions based either on old data or on a mix of old and new data are
avoided.
Check data quality in an ongoing fashion
A dashboard should have regular reviews of the data that drives the indicators and regular updates to avoid people
from gaming the decision-making process. Some organizations will implement a regular auditing process that
looks at key indicators and traces back from their results to the source data, checking the formulas and the quality
of data to make sure it has not changed. You can't do this all the time, of course, but a regular review of what makes
those pretty traffic lights turn green, red, or yellow is a healthy idea.
Happy dashboarding!
References
To learn more about how to do dashboards with Microsoft Project Server, I suggest reading a couple of great
articles on TechNet:
Microsoft Project Server 2010 Reporting with Excel Services written by Jean-Francois LeSaux and Steven
Haden from Microsoft Consulting Services (https://go.microsoft.com/fwlink/p/?LinkId=222672)
Creating Dashboards for Microsoft Project Server 2010 written by Blaise Novakovic, Jean-Francois LeSaux,
Steven Haden, Microsoft Consulting Services (https://go.microsoft.com/fwlink/p/?LinkId=222669)
About the Author

This article is part of our "From the Trenches" collection. It describes how to create an Enterprise Project
Management (EPM ) deployment plan. It identifies phases and major points in an EPM Deployment plan, and it
estimates times for each, based on a mid-sized organization with several hundred EPM system users. It also
identifies factors that can affect the estimated duration times for each phase.
To download the Word version of this article, see Creating an EPM Deployment Plan.

"Can you help us install the EPM system and get it up and running in a few days?" is one of the most common
requests EPM deployment firms get. And regardless of the size of the organization, the short answer, is
unfortunately, "No." The challenge isn't technology; it's a series of policy, process, procedure and practice questions
that have the potential to create far-reaching organizational change.
Let's take a look at what an EPM deployment plan must include and how you can create your own. I've identified
the major points and even put in estimated times for how long each phase might take in a mid-sized organization
with several hundred EPM system users. Before you dismiss each time estimate as too short or too long, think
about what you would need to do in your particular organization in order to accomplish that section. The durations
are not work estimates, they are calendar estimates, so keep in mind how long it takes to get certain kinds of
people assembled for the kind of work you will need.
1. Establish the EPM System deployment team
If we have no project team then our project won't go far. Several people will have to be assembled in order to bring
this project from the idea phase all the way to production. With an overview plan already in mind, you will need to
think about people who will be with the project as long as a couple of years.
Key steps in this first phase are:
Identify Key Stakeholders
There's often one key stakeholder before the project even starts. It's usually someone at the executive level who is
feeling the pain of not having this kind of system. That's a great start but it won't be nearly enough to bring such a
project to fruition. Identifying the business owner of the system is critical to a successful EPM deployment and
must be done almost immediately. The business owner will be the person who uses the benefits of the completed
system and sees the value in going through what it will take to complete it. There may also be one or several
executive sponsors. The executive sponsors might be management level staff who have some use for the ultimate
results but they might also be people who will work on the project until its completion and then move on with little
investment in the final operation of the EPM environment. You can live without an executive sponsor. You can't live
without a business owner.
Identify internal expertise resources
Having determined who the business owner and possibly the executive sponsors are, the project team should
determine what internal expertise is needed and available to move the project forward. Often we'll find a lack of
expertise in a particular technology such as the current version of EPM software but that's not the only kind of
expertise we require. Internal knowledge of the organization's processes, practices, procedures, roles and
responsibilities and where data can be located to drive the process will be essential.
Engage external expertise (if required)
It's common to determine that there is a knowledge or skill gap in the project team to move from non-enterprise
project management to enterprise project management. If that's the case, then there's no substitute for finding
someone with know -how. To whatever degree the internal resources are not available, they'll need to be engaged
from the outside. These people might be engaged as part of a consulting or outsourcing contract or hired for long
term use in the environment that they will help develop. Training for this kind of expertise from the inside is rarely
successful. The most common challenge we see in this area is finding out that the internal resources have been
given the responsibility but don't have the knowledge or have only a limited knowledge. "I used EPM software
once and now I'm being asked to deploy it," is a cry we hear all too often.
The size of your team will depend on how wide a scope the project ultimately becomes. It is not uncommon to find
some people with the project for several months who are then replaced with others as phases of the project
change. The authority of the team and the support of management are also critical to establish at this time.
Oh, and do I need to say it? Treat this project as a project! Amazing as it might sound, EPM deployments are the
most likely project in the organization to be deployed without any of the elements you'd put into any other
deployment plan (something about a shoemaker's children going barefoot). So, make a project schedule, a budget,
a charter, allocate sufficient resources etc.
Time to accomplish this: Four weeks.
2. Identify Business Objectives
Ok, we've got the team together. Time to get it to work! We've got to now identify the scope of the project, break
that scope into phases if it's big and then create a plan for the work.
Here's what we'll need to accomplish in this phase:
Executive and Stakeholder workshops
There's no way to get around this. The whole purpose of creating an EPM environment is to better enable
management and end users to make business decisions. So the relevant management personnel will need to invest
some time at the beginning of the process to help identify what decisions will be made using the system. I've
written about how to conduct such workshops in the past (See Being a solutions buyer: white paper ) but how
they're done is less important than that they're done.
This is the opportunity for the deployment team to get two other very, very important things while they have
management's attention. First, the commitment of management to the process, the effort and the ultimate benefits.
Second (and far more important), the managed expectations of management. The most common management
expectation is that this can be accomplished in a few days or a few short weeks. When they grasp the impact of
what's involved, management support may evaporate. Better to have that happen immediately than to get started
on something that can't possibly be delivered with insufficient time or resources.
The results from these workshops (yes, it may take more than one) will be the business objectives that will make up
the scope and ultimately determine the schedule.
Identify management role impact
Once the business objectives have been agreed to by management, there will have to be a session or two
identifying the impact on the roles and responsibilities of management. A common example often appears with
resource capacity planning. In high tech firms, resource capacity planning is almost always a management request
of the EPM system, yet who will have to get the authority in that process to allocate resources, manage conflicts,
and prioritize the work of people in different departments? You won't be able to solve these issues at this point as
you have no defined process, but identifying who in the executive suite will be affected is important here so that
you'll be able to circle back to include them in the process when the time comes.
Prioritize business objectives and create a Master Deployment Plan
It's almost certain that the plan should break into phases. With virtually every EPM deployment, the desires of
management on what benefits the EPM system should deliver are vast. The prioritization of which objectives to go
for first is an essential element of success at this point. Get the top two or perhaps three objectives put into a phase
and push everything else downstream. Each phase should deliver a working, production EPM environment that is
valuable in its own right.
Establish milestones and metrics
We're project managers, aren't we?! Let's get some milestones into our project and commit to some measurable
metrics. With any enterprise system deployment, making sure it's staying on track is an important part of the
process.
We should have enough information now to develop our overall schedule with detail for the first phase.
Time for this work: Four weeks
Phase 1
For each phase there will be some tasks that need to be repeated. Steps 3 to 9 are all part of one phase.
3. Inventory processes
Before we get anywhere close to the tools, we need to determine what processes will ultimately need to be
automated in this phase.
What processes exist and can be adopted?
We start with looking at what processes, practices, and procedures already exist in the organization for the business
objectives identified in this phase and determine which can be adopted within the new EPM environment. There's a
two-sided benefit to finding existing processes that can be adapted with little or no work. First of all, they're created
already and known to the users. Secondly, adopting them makes a friend of the person who created them. They can
now be named as a subject matter expert in that process and that eases deployment.
What processes must be designed
We never find all the processes, practices, and procedures we need, but we have to identify what's missing. That can
be harder than locating processes that exist already. You're looking for what's not there and that takes an
experienced eye.
Process whiteboard workshops
For those processes that require work to be adapted or for processes that need to be created from scratch, you'll
need to get some workshop sessions with a white board underway. Walking through the process and all its
implications is best done with the people who will live it once it's done. Document everything.
Resolve impacted management roles
Remember when we identified which executives or managers might be implicated in the changes that would occur?
Time to call them back. For any of the newly designed processes that affect roles, authority, hierarchy, or existing
responsibilities, you'll need to organize meetings to resolve them.
The final result of this is the draft of a process guide.
Time to accomplish the processes exercise: Four weeks.
4. Adopt, adapt, and design processes
Review, adapt, and accept designed processes
Not everyone will have been a part of every process exercise that happened in the last set of tasks. So, getting the
draft of the new process guide published to the stakeholders, managers, and affected parties is essential. It's quite
common for this guide to go through several reviews and even for additional workshops to be scheduled to resolve
conflicts in processes.
The output of this is a completed and accepted process document. Don't be fooled, the "accepted" aspect may take
several rounds and even require executive intervention from the highest level before it's complete but without an
accepted process, there's nothing to automate. The good news is, even if the deployment process stopped here, this
is already of great value. It is inevitable that those who work through these processes internally see things about
their organization that they had never considered. They will be more effective as a result starting almost
immediately.
Time to accomplish the completed process guide: Eight weeks
5. Evaluate and Select EPM Tools
Prepare "problem statement" documents for vendors
If you've read other articles I've done, you know that I believe strongly in giving potential vendors a description of
your EPM problems and letting them tell you how they would solve them. After all, they say they're in the solutions
business? Great, have them design your solution. This is a little harder than making a spreadsheet of all the
functions you would like, but it's important.
Solicit vendor responses
Never do just one. You may already know who your preferred vendor is, but even if you think it's the right one, get
something to compare against. No two vendors will try to solve your problem the same way so be prepared to be
surprised and keep an open mind.
Short list
Even if you're looking at one product but several implementers, get down to who you'd like to meet in person.
Vendor and implementer presentations
Ahhh, demo day. There's are many things of value to be had from looking at a demonstration but getting caught up
in the flash of it isn't one of them. Sales demonstrations are carefully orchestrated by all vendors. If you're
particularly excited over a view or a report or a dashboard, ask specifically, "How long would it take to develop that
exact view?"
Tool selection and acquisition
Ok, time to make the big purchase. I know, you thought that was the starting point, back at the beginning of this
article. Well, don't worry. We're finally here. Make your selection of the EPM system and get that purchase order on
its way!
The end result of this phase is a shiny new EPM product sitting on your desk.
Time to accomplish this phase: Eight weeks.
6. Automation Design and configure
Apply the process design document to the selected EPM tool
Now that we know what the tool is we can start creating system design documents that start with our process
document and end up in functional specifications. We'll probably want a Development instance of our new EPM
system installed so we can test or verify certain design criteria. For the first time, a system expert in the
configuration of the actual system is required on board.
Design and implement standards
There are numerous standards that will have to be established. Each and every one of those standards carries
implications in the system architecture and design. The calendar for example is often overlooked. Will we have one
calendar or many? Will we have resource calendars? Who will have the authority to change them? Do we know the
effects on the schedule and progress data of changing a resource calendar ? And so on … Here are some of the
elements of our EPM system that we will need standards for:
Calendars
Naming conventions
Resource hierarchy
Resource load standards for project and non-project work
Rates and costing standards
Roles and responsibilities
Approval structures
Project and task hierarchies
WBS and other coding structures
Document management
Communication templates
Project templates
We're also going to need some other design and even possible coding for elements that came out of our Phase
One business objectives. Some of the elements that might have to be considered are:
Design and implement custom coding
Design and implement dashboarding
Design and create links to external systems
Design and create workflow
Design and implement reporting
Design and create EPM tool training
Review design with all affected parties
The result is an EPM tool that is ready to be taken out for a ride. It should have all the configuration required to
move into a working environment.
Time required for this phase can vary greatly depending on how much custom work was required but we'll say
twelve weeks given we've restricted ourselves to the first phase.
7. Pilot EPM Tool
Now that we have our system ready to go, we must identify the pilot group and get them working on it.
Phase 1 install / configure / migrate data
We'll need to install the newly configured system in a pilot instance (not the development instance. We'll continue
to use that for future phases and as a support and training system). We'll also need to update the configuration to
match our development instance and migrate the pilot projects from whatever they're in now into our new system.
Training
Training is the poor stepchild of project deployments. It's often forgotten in a deployment plan. Make sure our pilot
personnel get the training they need to use the system properly.
Run active projects
Now, have those pilot projects be managed based on the processes, practices, procedures and automation that
you've spent so much time defining. The pilot needs to have a schedule itself that is often oriented around how
long these projects will last.
Lessons learned and document
Once the pilot project is complete, it's time to reassemble and see how what was created solved the challenges that
were set for it. If there are adjustments, corrections, or basic changes to make, now is the time.
Time for a complete pilot project and review: Twelve weeks.
8. Roll out Phase 1 into production
Go-live
It's time. Roll out the use of the new system to the appropriate users and migrate the appropriate data. Don't forget
training, support, and follow up as the system goes live.
Time to rollout is highly dependent on the number of total users: Four weeks.
9. Review and Adapt Master Deployment Plan
Review and adjust master plan in preparation for next phase The master plan probably hasn't been looked at in
months. Time to dust it off and see what was originally planned for Phase Two. It's inevitable that the eyes that look
at the next phase will see things differently. After all, they now have all the experience of the first phase.
Time to complete this phase: Two weeks.
10. Phase 2 - do steps 3 through 9 again
We've only completed phase one and as you look at future phases you'll need to rework steps 3 through 9 (with
the exception of step 5). Remember that each phase should result in a working EPM production that leaves the
organization more effective than it was before.
Have you been counting the durations for each of the steps for the first phase? It adds up to 58 weeks. Here's a
schedule of the summary steps defined above:
Now, every organization is different. There are many factors that affect the total duration of a project. The most
significant of these is the extent to which existing enterprise project management processes are mature. Next is the
size of the organization and its complexity. It is obviously simpler to deploy an EPM system into an organization
that is all located in one building than it is for an organization that is spread across numerous divisions, offices,
cities and even countries.
In each deployment the schedule will look different and not always shorter. There is virtually always pressure to
make a schedule that can be accomplished in days or even weeks, but it's vital that more than just the installation of
EPM software be considered in order to deliver a successful deployment.
About the Author

The challenges of selecting enterprise software
This article is part of our "From the Trenches" collection. It describes how enterprise system implementations need
to able to adapt and evolve to be successful.
To download the Word version of this article, see The Challenges of Selecting Enterprise Software.
The Challenges of Selecting Enterprise Software

It happens around here all the time. A client sends a "Request for Proposal" (RFP ) to the office with instructions to
complete a response in a few days or week and send it back to have our enterprise system considered for purchase.
RFPs pretty much all look the same. There's usually a brief overview, instructions on what you need to do to have
your response be considered, including how it needs to be formatted and when to send it back, etc. Then there's a
long grid of features that are required and a number of additional essay questions to write answers to.
The challenge with RFPs is that they weren't ideally suited for selecting enterprise software, and what ensues when
an RFP process is followed doesn't guarantee the best decisions for the organization. RFPs were designed by the
purchasing community as a way to get the best commodity at the best price and they still do a great job of that.
When the offerings are comparable, then the decision-making process can focus on the best price with only one or
two additional variables (such as shipping dates) to contend with. When the possible solutions are in the same
general category but not at all comparable (as is the case with enterprise software), then the number of variables
that must be considered by purchasers is huge and the RFP process doesn't add value to the selection. How most
companies select enterprise software Let's start by looking at the process that happens all the time in any vendor
or solutions provider of enterprise software. I'll be talking about enterprise project management software or
enterprise timesheet software as that's what my firm provides, but the paradigm is the same for virtually any
enterprise system selection.
How most companies select enterprise software
Let's start by looking at the process that happens all the time in any vendor or solutions provider of enterprise
software. I'll be talking about enterprise project management software or enterprise timesheet software as that's
what my firm provides, but the paradigm is the same for virtually any enterprise system selection.
In most organizations, the impetus to look for enterprise software comes from some problem. Perhaps the
problem is surfaced by the field personnel. Perhaps the problem is identified by someone in senior management.
However it happens, the initiative has to get support from someone in senior management. Grassroots selection of
a system that will affect the entire enterprise is a fantasy in even the most progressive organizations. So a senior
manager decides, "we need this kind of enterprise system."
The typical enterprise software selection process goes like this:
1. Management says we need a new enterprise system
2. Project manager is selected
3. Solicit requests from all departments involved
4. Merge all requests into one large spreadsheet
5. Send the requirements grid to lots of vendors
6. Get lots of responses
7. Short list
8. Watch demonstrations
9. Negotiate
10. Get management acceptance
11. Have management decide on something else
A project manager for the selection effort is volunteered. He or she does what we all do —go to the Internet, load
up a search engine and type in "EPM Software" (or whatever enterprise system is desired). Immediately a half-
million hits are returned. Perhaps the diligent project manager surfs the first dozen or so to learn what kind of
systems might be available before moving on. Clearly no one has the time to surf through a half-million or more
hits to see if perhaps the very last one is the ideal system for the organization.
Undaunted, the project manager now assembles a selection committee from among those who will be affected by
the implementation of this new enterprise system. Some of those on the committee may be from among field
personnel who identified the need in the organization in the first place. Others may not. There may be a mix of
people on this selection committee who have diverse interests in what kind of system will be selected.
The hapless project manager now solicits each member of the committee to poll their representative group for
what they require in the new enterprise system. How does each committee representative do this? Well, first of all,
not everyone puts in the same effort but for those who do their homework, they ask their staff to submit a list of
features that they would find important. Then they, too, hit the Internet and surf some vendor Web sites. They can
copy and paste from features they see in the brochures of these sites as each site gives them new ideas of what
kinds of requests they might be able to make of a new system.
Now the committee is reassembled and the long spreadsheet of each committee member is merged with the
others into one massive spreadsheet. The mega-spreadsheet of requirements is categorized, but there are
challenges. First of all the diverse needs of the committee now become more apparent as features are requested
from a wide range of perspectives. There may be committee members in different departments but also in different
countries or even different divisions. There is almost always a request which is at conflict with another request in
the same list (e.g., the system should be very easy and not have many prompts and the system should be very
flexible with a large number of options for each user).
Finally the combined spreadsheet that the vendors will see is complete. It has hundreds of feature requests and for
each one the vendor will be expected to say "Yes", "No" or "Yes with some effort". A weighting system may also be
attached to say whether this feature is a "Must-have", an "Important-to-have" or a "Nice-to-have".
The RFP is almost ready to go. There will be a few essay questions, usually about the technical architecture of the
selection and, depending on how many people were polled about these requirements, the architecture requests can
be equally conflicted (e.g. The system must have all data stored centrally in the SQL Server database ¬and¬ the
system must allow any data to be stored locally on the user's computer).
Actually, it's sounding pretty good so far, don't you think? After all, we're going to get back a bunch of vendor
responses that show who can deliver all the features that we'll need. Actually, it's sounding pretty good so far, don't
you think? After all, we're going to get back a bunch of vendor responses that show who can deliver all the features
that we'll need.
But there's actually a fundamental problem with what I've described thus far: A problem that doesn't occur when
we're using the RFP process for a commodity rather than an enterprise system. It's this: An enterprise system is a
solution to something. But we've said nothing so far about the problem. This is such a common occurrence that the
technology industry has come to accept it as normal and acceptable.
Why selecting enterprise software that way doesn't work
Purchasers have been using this method for decades and no one questions it, but people in the enterprise software
business know there is a fundamental problem with the classic RFP method of selecting enterprise software.
First of all, just because you have an enormously long list of features, it does not necessarily mean that you are any
closer to solving a business problem. In fact, if you haven't even articulated what specific business problems you
are trying to solve, then you are likely to make things more complex and ultimately worse, not better. The RFP
process was designed to purchase commodities. When we've got homogeneous products like shoes or potatoes or
sugar, then purchasing these items in this way can result in the lowest-cost bidder and the best selection from
among the possible suppliers. The responses to an RFP for a similar commodity makes comparing possible
suppliers very easy. When the variables for each product in the mix are infinite (as they are with enterprise
software) then the responses to the RFP have an infinite number of variables also and the process yields results
that have little value.
When we use the RFP method of selecting enterprise systems, the RFPs mostly all look the same. This is because
they are all created in response to the same stimulus. The project manager requests a list of 'what you will need in
this enterprise system' and the only vocabulary most middle managers have to respond to that request is a list of
features. Consequently, the responses to RFPs all look the same. They're a checklist of all the features available
either as part of the system or as part of the system with some effort.
What is most common for selection teams is that they will receive a number of responses to their RFPs, they'll
wade through the hundreds of pages and, when they're finished, they won't feel any closer to a solution than when
they started. This is terribly frustrating for purchasers who put in enormous effort in creating what should be a fair
request for proposal and in evaluating the answers only to find that the exercise was for naught.
Worse than all of this is that experienced enterprise salespeople know the process will yield frustrating results and
are at work from the moment they hear there will be an RFP created. They're not working on the RFP response.
That's not relevant. Instead, they are working two or three levels higher in the management structure, looking for
the original impetus that got the RFP started. They look for the senior executive who articulated some business
challenge and set the wheels in motion so that purchasers and other middle-management staff would ultimately
create the RFP and send it out to vendors.
When the RFP responses end up without a clear answer to the business problems that are almost never articulated
within the purchasing process, the enterprise salesperson is ready to leap into action, having a senior executive
bypass the process altogether and select a system based on their own personal relationship with the senior
enterprise salesperson.
If you think this sounds jaded, you're wrong. In fact, you can make a better case for having software selected
through personal relationships at the executive level than you can for buying through the RFP process.
But what about a Proof of Concept or Pilot?
So, we know the classic purchasing process is flawed when we apply it to the purchase of enterprise software. If
that's the case, how should we choose enterprise software such as an enterprise project management system? A
popular method is to use the Proof of Concept or Pilot Phase method.
These two terms are often used synonymously, so let's start off by talking about what is a Proof of Concept or a
Pilot deployment.
Proof of Concept. In a Proof of Concept, the prospective organization deploys the enterprise software in a
limited fashion in order to prove that it can accomplish a technical challenge where there is some question as to
the solution's ability to overcome that challenge. An example might be for data volume. "We're concerned that
the product might not be able to handle as many tasks as we have per project. We'd like you to come with the
software, take two or three example projects with 500 tasks each and show us how these can be loaded into to
the software and that the software can still perform its basic functions with this volume in it."
Pilot Phase. A Pilot Phase is an installation of the enterprise software but with a limited scope. A pilot
deployment might be for a subset of users; for example only 10 out of 1000 people will use the software fully
for a four-week period. Or, it might be for a subsection of the functionality or a subset of the volume of data;
for example only 10 out of 500 projects will be loaded.
How is the Proof of Concept or Pilot Phase used? The problem that is often encountered is how the Pilot
Phase or Proof of Concept is applied. It is quite rare when a prospective organization calls and asks us for a
Proof of Concept proposal and can also identify what technical concept needs to be proven. "What are you
hoping to prove and how will we be able to measure that we've proven it?" we ask.
What is most common is that someone in middle management has identified a piece of enterprise software that
they hope will make their lives easier in their organization. Senior management is not at all involved, and the
middle management staff have not even articulated what business challenges they are trying to overcome. It is
their hope that if the solution was just in the building, that the next time someone from management would
wander down the corridor, they would 'accidentally' see the solution in operation and would instantly give their
blessing to an enterprise deployment. To borrow a phrase from the movie Field of Dreams, "If we build it, they will
come."
It is rarely successful. The problem with enterprise software is that we need senior management's involvement to
make the deployment a success. It is senior management who will be the 'clients' of the reports and analysis from
this enterprise system. It is senior management who will need to invest personally to allow a range of staff the time
required to design, configure and be trained in the enterprise software. It is senior management who will have to
accept or even help redesign the business processes that are part of any enterprise system deployment. Without
senior management giving not just their blessing but also their implicit support and direct assistance, no proof of
concept will help.
This is true also for a pilot phase. If the company has not committed from the highest level to solving some
business problem through the use of enterprise software, then the introduction of a pilot phase is not productive.
This is not to say that pilot phases of a deployment have no place. They do carry a critical spot in a successful
deployment. That place is immediately after the purchase decision is complete and the design of the enterprise
system has been concluded. Now a pilot phase makes a great place to test out our enterprise system design and
fine tune it for general deployment.
When a pilot phase is done in the hope that seeing the software in action will result in management selecting it,
then we have an ineffective Pilot and will get no further ahead in the selection process.
How should organizations select enterprise software?
Enterprise systems are purchased by middle- to large-sized organizations every day and, while the RFP method
may not be the most effective, there are several methods of selecting enterprise software that are very effective.
Here are a few tips for creating your own effective enterprise selection process.
Articulate the Problem. First and foremost, articulate the problem. This means that senior management
must be involved and the problem to articulate is a business problem so it should be articulated in business
terms. One good question to ask is, "What business decision can we not make now or can we make only
with great difficulty, the making of which could be eased with the deployment of this enterprise system
solution?"
There may be a series of business challenges that you wish to solve with the use of this enterprise system.
Give vendors some latitude to create the solution. Once the business problem or problems have been
articulated, contact possible vendors and make sure the access to the senior management who assisted in
the process is transparent. "Secret" vendor meetings with senior management become impossible when
management is part of the process from the beginning. Let the vendors understand the problem and give
them some latitude in answering it. You may find out more about your organization in explaining how these
business challenges affect you than you realize and you will certainly see a much wider range of possible
solutions to your problem when you don't try to describe the solution to the potential vendors.
When you talk to possible solution providers, make sure they understand that they must speak to both the
technology and the business process challenge. There has never been an enterprise system solution that
didn't have some impact on the organization's process. If the solution provider can't help with how the
process will be affected, then you're only looking at part of the solution.
Go meet some people. When you get down to a couple of possible solution providers, ask to talk to some
of their existing clients. Even better, see if the vendor will let you go visit some of their existing clients. Good
solution providers often have clients who have had success in their own deployments and who are generous
enough to make time to meet prospective clients.
You'll learn more from a couple of hours with an experienced client of the possible solution than you would
have ever learned from reading RFP responses or looking at vendor sales demonstrations. When you ask
the vendor for possible client references and site visits, you might think the ideal company to meet would be
one exactly like yours. That's not always the case.
It's often extremely valuable to meet companies in other industries that are related or somewhat similar to yours.
You might also learn lots from organizations who are bigger or smaller than you are. Place more emphasis on how
much experience the organization has had with the solution rather than what version they're using or whether
they're of the exact size or in the exact industry you're in.
If you are lucky enough to visit an existing client, remember that it's not the vendor. Be respectful and courteous
and thankful. Bringing a small gift, perhaps of company logo promotional material is often well appreciated. While
you're with the organization or while talking to references on the phone, some possible questions might include:
1. What process did you use to select this solution over others?
2. What impact has this solution had on your business processes?
3. What was the most challenging aspect of the deployment?
4. What was the most valuable return on investment thus far?
5. How do you see the solution evolving from here?
Don't expect only happy answers.
A vendor who is completely unable to provide references has to be somewhat more suspect than one who has a
number of satisfied clients.
Finally, when you've made your selection, deploy in phases. You can find other articles in this column on how to
deploy in a phased vs. big-bang mode. This will mitigate the risks involved in any enterprise system deployment
and help fine-tune the deployment process as the system evolves.
Remember that any enterprise system deployment is a dynamic process. It's not a one-time decision with happy
results arriving month after month forevermore. The most successful enterprise deployments start with a selection
that involves the key personnel who will be a part of the deployment process from the most senior in management
to the most tactical in the field and continue through the evolution of the system in phase after phase.
An effective enterprise system selection is only the first phase of the process.
About the Author

This article is part of our "From the Trenches" collection.

This article discusses common mistakes that are made in project schedules and offers practical advice. It provides
practical advice and recommendations that are relevant to any version of Microsoft Project.

Scheduling is never a simple component of a project; yet in the last 20 years, I've repeatedly run into the same
basic problems in every organization I have worked for or consulted with regarding their schedules. Here I lay out
the seven deadly sins of project schedules and provide you with some antidotes. My hope is that you'll use this
advice to lay the right foundation for successful project management when using schedules.
Sin #1: The schedule is too complex!
When you have schedule that has more lines running north to south than left to right, you have a problem. If it
takes weeks or days for stakeholders to understand your schedule, then the model is too complex. If it's too difficult
to explain to executives or even to your team, then how can you expect anyone to benefit from it?
How do you know if your project is too complex? Ask yourself how easy it is to find the critical path in your
schedule.
Sin #2: Your schedule has too many tasks
This, more than anything, will contribute to why schedules fall by the wayside. Project managers somehow get the
impression that a schedule needs to be a checklist of everything that needs to get done. To-do items and
reminders-to-self don't belong in a work breakdown structure. This approach completely defeats the whole
purpose of a schedule representing a model of your project.
To illustrate the point, let me share an example. Suppose that you're the lumber supply person or the framer who
will be erecting a house being built. You need to know when to deliver your lumber package, or when to show up
with your crew to start work. This typically occurs when the foundation is complete.
You can build a schedule like this:
Or one like this:
If you were the builder and scheduler, which approach would you prefer to have to update and maintain your
actuals?
Now imagine that you have 30 houses under construction at the same time. Which would you prefer?
That is not to say that all the other tasks listed aren't important, or that other tasks don't need to be done. The real
question here is how to track and maintain it. You could also just list the detail tasks as a note to the one line task
shown above.
Here's my rule of thumb, which I take from Eric Uyttewaal's book, Forecast Scheduling with Microsoft Project
2010: The minimum duration is one percent of the project duration; the maximum is 10 percent of the duration.
Sin #3: Your network logic is incomplete or isn't dynamic
Incomplete network logic is the number one reason why schedules fail to forecast properly or evolve dynamically.
Too few dependencies account for this. Use of too many constraints will also greatly impair the dynamic nature of a
properly laid out network. If you see mostly constraints in the indicator column, this indicates you may not really
know what you're doing. Project managers often make it a point to hide this column in order to hide that they have
many constraints in their schedule.
Here's an easy test for you. Find the critical path in your schedule (if you can't, you already have a major problem),
then take one of the longest incomplete tasks early in your schedule and double the duration. Does your project
finish date change? If not, then you don't have a working schedule. You won't be able to benefit from the basic
tenants of having a dynamic schedule that you can use to forecast tasks and timeframes and for you as project
manager to control the results better.
Sin #4: Your schedule isn't baselined
Not baselining a schedule will make it difficult, if not impossible, to measure variance. Baselining helps to capture
your schedule before you begin work and allows you to learn from the variances when reality sets in. If you can't
measure it, then you can't control it.
Sin #5: Your schedule doesn't get updated
The vast majority of the schedules I have seen are out of date. Project managers will often abandon the schedule
once the project is underway and find themselves fighting fires while in execution. The likelihood of this happening
increases significantly if the schedule is too detailed and requires too much work to keep it up to date. The bottom
line: If you don't update your schedule, then you have lost your ability to forecast future dates.
Sin #6: Your schedule has no resource assignments, or they're over allocated
Often schedules are created without any resource assignments at all. This might make for a nice picture, but it also
might give the false impression that the timeline is attainable. If resources are added and then leveled, an entirely
different timeline may emerge.
When resources are assigned, more often than not when looking "under the hood" (using resource usage view ),
they're grossly over allocated. If you start with out-of-the-box fixed units, you'll be starting off on the wrong foot.
Take the time to evaluate whether you've made realistic assignments in terms of time and work allocated within a
person's capacity.
Also, show extreme caution when using the auto resource leveling feature. It's best used in manual mode. And
using an enterprise solution that gives you visibility into other project workloads should increase your confidence
that tasks can get done.
Sin #7: You don't know what task types are
If you don't understand how the project scheduling engine works and how task types work in the equation
Duration * Units = Work
you will be forever pulling out your hair and getting frustrated with the tool.
If you find yourself not getting the message, then I recommend you get yourself a good resource and study it.
Forecast Scheduling with Microsoft Project 2010 is a good place to start.
About the Author

With over 25 years of project management experience, Kevin Watson, PMP, MCT, MCTS, is a black belt in
Microsoft Project and Microsoft Project Server. Kevin brings a unique combination of project management and
project server to the field, where he is a Senior Consultant with Microsoft. Contact him at kevinw@microsoft.com.
7 Ways to Sustain Adoption of your PPM Solution,
Post-Implementation
Project and Portfolio Management (PPM ) tools almost always cause a drastic shift in how projects are managed,
tracked and reported across the organization. However, it is lost upon organizations that there needs to be as much
focus on continued adoption as there is on the implementation of the tools. In this white paper, we will look at
some of the key areas you can focus on to sustain adoption—post implementation—until usage of the new PPM
tools becomes part of organizational culture.
To download the Word version of this article, see 7 Ways to Sustain Adoption of your PPM Solution, Post-
Implementation: white paper.
7 Ways to Sustain Adoption of your PPM Solution, Post-

Implementation
Introduction
Have you ever been involved in a project where the new idea or innovation seemed to be the next best thing, gains
strong support all across, gets executed, and then within a few months of being implemented, nobody uses it
anymore? If you answered yes, you will also agree with me that in these projects, there was no dearth of change
management efforts, training efforts, and so on. Why do people just stop using certain tools, which were thought
be the greatest ideas at the time of implementation?
There could be many answers to the question above. It could be that the tool is outdated due to market conditions,
or maybe the organizational strategy has changed. However, if you look carefully, more often than not, the real
reason is that no efforts have been made to sustain the adoption that was achieved during the implementation of
the project. It is not just enough to manage change during the project lifecycle; change must be managed beyond
the project closure as well. This applies to any project, but more so in the context of the implementation of the PPM
Solution, because PPM tools almost always cause a drastic shift in how projects are managed, tracked and
reported across the organization.
In this white paper, we will look at some of the key areas you can focus on to sustain the adoption post-
implementation, and not let go of the throttle until usage of the new PPM tool becomes part of organizational
culture.
7 Ways to Sustain Adoption
Let's assume your organization is going to implement the PPM solution (or upgrade to a newer version) in the
near future. Let us also assume that there is full-force Training support and Change Management support available
during the project life-cycle. In that context, here are the key areas that need real attention once the implementation
is completed.
1) Establish 30-60-90 Day Goals
Before you roll out the PPM solution, the first thing you need to do is to determine the 30-60-90 day goals for your
implementation. You read that correctly. This needs to be done BEFORE the roll-out and not AFTER. Start with
things that are simple to measure, like % of timesheets submitted on time or number of projects created etc., and
measure them consistently and report on them. These 'goals' will help you as follows:
First of all, the goals and metrics will tell you how well the tool is being used. If the metrics look bad, then
you can immediately jump to action and provide the support needed to increase the usage of the tool.
The goals will give you specific things to work with, instead of being generic about the success or failure of
the project. They will help you show the value of the PPM solution to the management.
And finally, this will help celebrate the small victories. While the PPM solution could have been implemented
to bring about sweeping changes across the organization, it is important to gain quick wins and celebrate
them, to keep the interest and the positivity around the solution.
And by the way, do not stop at 30-60-90 day goals. Make sure you establish some long term goals as well and
monitor them.
2) Show Them the Value!
Before the PPM Solution was implemented, it is almost guaranteed that a benefits analysis was done, which listed
simpler project tracking and maintenance, enhanced collaboration, better visibility and control etc., However, the
big elephant in the room that nobody talks about is that, all these are only possible, if all users of the PPM solution
do the work necessary to generate and maintain the data. The consequence of this is that, the end user has no idea
as to the value he/she brings to the organization just by submitting his timesheets on time, or how a Resource
Manager can help by monitoring their resource allocations.
If you want real user adoption long term, the first focus should be to show each user the value they bring to the
tool and the organization. Show them the reports and dashboard that are generated. Using the data they submit
into the tool. Engage senior management to actually use those reports and dashboards and communicate to their
groups, as to the value it is bringing them. Just like a plant only grows when the Sun shines on it, end users feel the
importance of the tool, only when they know that organizational leaders have their focus on it.
3) Change your Learning Methodologies
Think about this. As you are driving along in your car, listening to the radio, suddenly there comes a song that you
really used to like as a child, but have not heard it in a long, long time. I can bet you on that, while you may not
remember the exact lyrics of the song, you can pretty much hum along the tune of the song. Why do you think, it is
so? Because of two reasons.:
1. You heard that song many, many times.
2. While the lyrics were 'information', the tune had a 'feeling' attached to it. As human beings, we tend to
remember feelings better than information alone.
So, how does that apply to our discussion here?
Traditional training for PPM solutions tend to focus on cramming a lot of data or information into lectures, training
sessions, manuals and so on. However, there is no feeling or emotion attached to that information, so people do
not retain it once these sessions are done. In fact, you have to assume that the users will not retain more than 20%
of what they learn for the first time. So, how do we solve this? Just like we handled the song we liked.
Provide more avenues for obtaining training. All users do not understand things the same way. Some
people are more tuned towards reading material, while others like to watch videos. So make sure people
have more than one way to obtain information and training.
Allow users to attach a feeling to the information. This can include things like pulling users into small group
lunch-and-learn sessions, allowing users to ask questions in a group setting, opening up discussion forums,
and so on. I am pretty sure you still remember what a particular speaker said in response to one of your
questions. The same applies to all your users as well.
Reward good ideas, questions and participation. The Project TechCenter and Forums are great examples of
this, where all the correct answers are rewarded by the community themselves, thereby propelling more
active sharing of knowledge and expertise.
4) Reassess and Reconfirm
At one time, when I was working with a client on a PPM Implementation, we decided that all the reporting from
the PPM Solution would be done using OLAP Cubes. If you are not familiar with the functionality of OLAP cubes,
for the purposes of this story, understand that the data is only refreshed on a predefined schedule. In our case, we
agreed it was going to be daily. However, once the solution was rolled out, we started getting complaints that the
reports were incorrect, and were not showing the data as the users were entering it, and so on. As we delved
deeper into the issue, we discovered that the executives were looking at the data almost hourly basis (expecting
real-time data), and users were updating data on as-needed-basis. And since the OLAP data was a nightly refresh,
the reports were obviously not updated. Therefore, after evaluating the options, we went back and rewrite those
reports to directly pull data from the database, making them real time.
The moral of the story? What the project team thought, found, assumed, and designed during the project design
phase may not always work in real world. So, be open to making changes. If you find that your initial solution
implementation does not align with what users actually are doing in their daily job, do not be rigid and force the
design upon the people. That is a sure-fire way to lose user interest.
5) Establish Governance
Establishing a governance model to maintain your PPM solution, including changes etc., is, in my opinion, crucial.
This topic has been covered in a great detail in the white paper Beat the Half-life (t ½): Governing Your PPM
Solution, Post-Implementation. While the governance strategy helps maintain your PPM solution itself, it also
shows the users that it is not required to like every single aspect of the implementation. It shows them that asking
for a change is OK. This itself will bring an openness to the table, which helps users become the drivers. Actively
talking about what can be improved about the solution is much better for adoption than just assuming everybody
is aligned with what has been implemented.
6) Provide Fanatical Support
These days it seems like you can get a free tool for any kind of work you want to do on your PC. Do not get me
wrong—I absolutely love the free stuff. However, the one thing I dislike about free tools is the lack of support. If I
run into issues, I am on my own to search and research a solution, try several solutions, and hope one works. Do
not put the users of your PPM solution in this situation.
In my opinion, we all should be fanatical about supporting our users, no matter which application or process we
are supporting. Always respond as fast as you can, even if it is not always with a solution. Once the user knows that
somebody is paying attention to his/her issue, in most cases that itself is enough to put them at ease. And make
sure you follow -up with a solution, or at least point them to the right direction. Always, remember that the PPM
tool you are supporting is one of the many tools the user uses every day to get their job done, and the faster you
can make their life easier by resolving their issue, the happier the users are.
Trust me; without strong support post-implementation, I can guarantee you that the PPM Implementation will fall
through very quickly. Also, be smart about the support and resolution process. As you provide solutions to users,
build a knowledge base, so that for future issues, you can just redirect users for a self-help solution.
7) Behavior That Is Rewarded Will Be Repeated!
If you have kids, you will understand this right away: You reward a kid with a happy face when they do something,
and they will keep doing it, until it starts getting on your nerves. Whatever behavior you reward will be repeated
until you do something to change it. For every reluctant adopter you are trying to entice, there are at least 3 other
early adopters who are actually trying to learn, understand, and use the tool.
Do not forget about these unsung supporters. They are the ones who actually embrace change, use the tool, and
eventually lead others by helping them. Provide them with as much support as you can. Recognize and reward the
things they are doing so that they continue doing them, and others can learn from them. Make them super users,
and allow them to draft help articles. The bottom line is, encourage desirable behaviors so that they eventually
override the undesirable ones.
Conclusion
The techniques listed above are not the only ones that can help in the end-user adoption, and the list can definitely
be added to. The key point that needs to be understood is, it is not enough to just focus on user adoption and
change management during the implementation, or a few months after the implementation. This is a standard,
ongoing process that never ends, and it needs a constant focus and attention.
About the Author

Prasanna Adavi (PMP, MCTS, MCITP, MCT) is a Senior Enterprise Project Management (EPM ) Consultant and
Trainer specializing in the Microsoft Project, Microsoft Project Server, and Microsoft SharePoint platforms. His
main focus is to build and enable business solutions to help organizations achieve the best return on their
investments.
He also has extensive experience in leading projects end-to-end in a wide spectrum of domains and verticals,
including IT, ERP (SAP ), Manufacturing, Application Development, Automotive and Creative Services. He is a
regular presenter at various Project Server, EPM and SharePoint events across the country, and a regular
contributor to the SharePoint and EPM Community.
Prasanna is a regular blogger (http://www.prasannaadavi.com) and also runs a bi-weekly podcast
(http://www.msprojectpodcast.com), mainly focusing on Microsoft Project and Project Server solutions. Prasanna is
a Senior Consultant with EPMA (http://www.epmainc.com).
Cancelling a project without cancelling your career
This article is part of our "From the Trenches" collection. It describes best practices for recognizing when a project
should be stopped, the benefits of doing so, and considerations you need to take into account when cancelling the
project.
To download the Word version of this article, see Cancelling a project (without cancelling your career): white paper
(Project Server 2010).
Cancelling a project (without cancelling your career)

As project managers, we're hard-wired not to quit. People who quit something easily don't find the role of project
manager to be at all attractive. Project managers are, by nature, optimistic. We are the results-oriented, challenge-
motivated, never-say-die, make-it-happen, see-the-glass-half-full sort of people. After all, when the project is in its
infancy, where there is nothing at all to show for it but a good idea, the project manager carries the vision of the
completed project with them. She is the evangelist for the project's completion.
Even now, aren't you reading this very article and thinking, "I hope he's going to tell me how to save that project
that I really don't want to cancel"?
You wouldn't be alone.
As a culture, project managers are natural cheerleaders. I don't know about you, but when I watched the movie The
Perfect Storm, when the ship was going straight up the wall of water, I was silently cheering, "C'mon. You're gonna
make it." Surprised? (Spoiler alert: The boat didn't make it, and I knew that before the movie started. It didn't stop
me from cheering).
Sometimes, it's just time to stop
The Dakota Indians have a saying, "If the horse dies, dismount." Project managers would prefer to do anything but.
Rather than getting off a dead horse… er, project, project managers are more likely to change riders (project
managers), put two dead horses (projects) together to see if they pull the cart faster as a team. We'd prefer to
rename the horse, send the rider for more training, add funding to the horse or just wait quietly on top of it hoping
that no one notices that it's not breathing and avoiding a declaration of what everyone already knows. The horse
isn't going any further forward.
Yet, in a modern project management world, our focus is likely to extend beyond a single project and into portfolio
management, and when projects must compete for the same resources, there may come a time when cancelling a
project is the best path forward for the entire organization.
Stopping a project begins with identifying the fact that it would be inappropriate to continue. That may not be
obvious. Some organizations have adopted stage-gating processes as part of their project portfolio management
environment. Stage gating sets up formal reviews between each phase of the project and ensures that the project is
ready and worthy of moving forward. Yet, even in this structure, there is resistance to stopping a project. It is not at
all unusual to find a stage-gating environment defined and implemented but also to find that there is no political
will to stop a project once it is started. There is stage-gating, but all the gates are open.
If you can't slow, pause, or cancel a project, then stage-gating has little value.
The reason the project shouldn't go forward may not be anyone's fault. There are a limitless number of possible
reasons. Perhaps the economics of the project have changed. The expected return on investment is now clearly not
going to happen because the price we thought we'd get for the finished product is no longer viable. Perhaps the
economy itself has changed. A project of luxury goods perhaps has no place in a region where luxury is no longer
sellable. Perhaps a competitor has changed the landscape by releasing a competing product before you expected
and before you're ready. Perhaps you've lost some key personnel with critical knowledge and expertise that are
required for the project's success; or perhaps the project has exceeded a budget, schedule, risk, quality, or
complexity threshold that makes continuing with it questionable.
The project has already started, so how do we stop it?
Whether you use a formal stage-gating process or an ad-hoc business review process, there are a number of
methods to determine that a project should not go forward.
The first and most obvious is to do a business case "refresh". Whatever business driver metrics you used when the
project started should get reviewed. Does the project still have the chance to deliver the expected return on
investment? Is the deliverable from the project still desirable? Using the same structure you used to evaluate the
project before it started allows you to compare what the current situation is.
Another possible method is to use the 10 knowledge areas of the Project Management Institutes PM Body of
Knowledge: Evaluate the status of the project from each of these areas and compare that evaluation against your
expectations at the beginning of the project:
1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management
10. Project Stakeholder Management
Let's take number 8, Risk Management, as an example. The project should have the most risk on its first day. That's
when you have the most "unknowns". On the last day, the risk should be zero because you've just delivered the
project. You now know how it turned out. You'd naturally expect, then, that as the project progresses, the amount of
risk would diminish. Is that so? If the risk is continuing to increase, that may be a sign that the scope of the project
needs to be revisited.
If you do a Return on Investment (ROI) analysis (always a good thing to think about when you pause a project for a
business review ), don't forget that the "I" in Investment is not zero. You've already spent some of that money, so
the investment you have to consider is the remaining resources and money it would cost to complete the project. If
you cancel the project, the "R", as in Return, may be zero but at least the "I" will not get any bigger.
As you are doing your business review, it's also a good thing to think of the opportunity cost. If you weren't
spending any more on this project and your resources weren't tied up on this project, could they be doing
something on another project that would be so valuable, that the lost investment here would be overcome?
End it right
If you do have to cancel a project, make sure you do so consciously. Just ending a project in an emotional tirade
can cause more damage than keeping it going.
Make sure you take care of the team members who are on the project that is about to be cancelled. Over-
communicate and make sure the staff have an opportunity to give feedback during the business review. Perhaps
they have a perspective that you haven't considered and all input at this time is probably welcome.
Adopt some key end-of-project best practices and make sure you apply them in this situation. They might include:
Meeting the staff to review what can be salvaged from the work in progress. There might be some big
benefits you don't even know you have.
Staying away from blame is a great idea here. Blame is generally useless anyway but focusing on who to
blame instead of what to do can rob you of any opportunity to get positive results out of this otherwise
unhappy result.
Do a wrap-up meeting to close off the project and thank all the team members for their participation. Make
sure that any lessons learned and other project documentation is recorded and archived along with any
work-product.
Make sure there is a final accounting of the project so the true cost vs. benefit can be calculated. Also make
sure not to forget your sub-contractors. Make sure all outstanding invoices are resolved and that there is
nothing outstanding with your vendors such as long-term subscriptions. After all, you may be working with
them again on the next project soon.
The benefits of stopping the project now
It isn't all bad news. As part of your business review, there may be some returns on the project's investment to date
that are worth pointing out.
The first and most obvious benefit is the newfound availability of the project-team members. If they aren't working
on this project, they will immediately become available for other projects.
Next is salvage. It is often surprising to people how much work-in-progress can be adapted to other purposes. In
some cases, this can be a complete (but more modest) product. In other situations there may be recoverable
modules that are immediately valuable on other projects. Throwing out everything that has been accomplished is
often a big mistake. Include in your salvage thinking things like hardware, software, subscriptions and services that
have been pre-paid for. Perhaps another part of the organization could use those licenses for something
productive.
A soft benefit is almost always improved morale. Almost everyone working on a project that needs to be stopped
knows it should be stopped before it happens. There is almost always a sense of relief that the issue is out in the
open rather than something feared, and the knowledge that the end of the project doesn't mean the end of their
employment is usually great news for those staff who can now work on something more productive.
What about my career? Am I now associated with a failure?
In 2005 KPMG did a Global IT Management Survey. In it they discussed projects that had to be stopped, and one
commentator said, "Cancelling a project unlikely to deliver expected benefits should not be seen as a failure —
failing to cancel such a project should be." It makes perfect sense. If you are a cheerleader for a project that should
not continue, then you've just become part of the problem, not the solution.
A side benefit of going through this unexpected end-of-project process is that you become an "honest broker".
You've been willing to stand up and share the bad news and your credibility with management as a result will
almost certainly increase. If you've done a good job of closing out the project you've also got a lot of data and
benefits to offer. There is the accounting of what was salvaged and a true accounting of both the investment and
the return. The benefits to the rest of the organization should also be pointed out as you'd like management to
know that cancelling a project isn't always a catastrophe. After all, freeing up the availability of your team members
has made the success of other projects more likely.
No project manager wants to quit on a project. It's not in our nature. But it's a natural part of being a project
manager and something every project manager needs to be ready to face.
About the Author
We're selling holes, not drills!
I came across an interesting expression recently. A software salesperson was talking about delivering the entire
solution to his client. "We don't sell drills. We sell holes," he said. It's a great analogy. Many people (me included)
have gone to the hardware store and window shopped in the power tools department while wondering what
project I could possibly think of which would justify buying this great power tool. But applying this logic makes as
much sense in the do-it-yourself world as it does in enterprise software systems.
If you don't have a problem, you don't need a solution.
Just as no one should go looking for a drill unless the problem they'd like to solve is to make a hole, no one should
go looking for enterprise software unless it solves some problem. Now if you've got a problem that deploying
enterprise software will fix, the next thing to ensure is that what you are buying will deliver the solution you need.
That's often a lot more than just buying the software.
Deploying an enterprise system is a complex challenge so the payoff has to be worth the effort. In today's world of
global project teams, one of the most common things to do is to divide the tremendous effort of an enterprise
system deployment. While this can give us economies of scale in using teams which are highly trained in their
aspect of the project, it also holds the risk of overlooking aspects of the project in highly risky ways. This risk is
compounded the more physically and organizationally disconnected the different teams are.
Let's take a look at the most common elements of an enterprise systems project.
What's an enterprise?
First of all, what do I mean by enterprise? I'll take a definition that should work for almost everyone. "Enterprise," in
this context, means any project which will impact how the entire organization functions. I'll say this is true for any
organization. Implementations that qualify as enterprise implementations aren't just about how many users but
how much impact they have. So, updating our virus scanning software from vendor A to vendor B probably
wouldn't qualify. The implementation of project scheduling software on the desktop for a handful of users likely
wouldn't qualify. Centralizing our project management and using a centralized enterprise project management
system probably would qualify.
Okay, so if that's an enterprise project, what are the most common elements of a deployment of an enterprise
system? In our offices the most common experience is deploying enterprise timesheet systems, such as our own
TimeControl, or enterprise project management systems, like Microsoft Project Server, but these elements will be
common to almost any enterprise system implementation.
Bits and bytes

First let's tackle the most fundamental building blocks of software: the technical architecture. These days we have to
divide our thinking based on our decision to go with an on-premises deployment or an in-the-cloud subscription.
I'll leave the wonders of choosing which of these is best under which conditions for another day, but here are some
of the basics of what we'll have to think of in each category.
If we're going with an on-premises installation, we have to think about what hardware we'll use. What are the
hardware requirements for memory and CPUs? Will we use physical servers or virtual servers? Will we use
dedicated servers or shared? What kinds of servers might be required? Will we need application servers, security
servers, web server servers? What about load balancing, disaster recovery, and backups? Will we need cold or
warm backup servers? Whew! But we're not done! What about the database? What are the requirements there?
How about support for our existing security, application, and database architectures? What about support for
browsers, browser versions, and mobile devices? Once we've got all those questions answered, we have to handle
the issues of installation, test, and production environments, and then system health and monitoring once the
system is up and running.
If we're going with an in-the-cloud subscription implementation, we still have questions to answer though they
may be very different questions. Which online service do we use? Do we go with a dedicated installation or a
multi-tenant service? What about security? Can we integrate with our own authentication? How do we handle
disaster recovery with the subscription service? Where is the data physically located? Does this present legal issues
for us? How about support for our internal browsers and mobile devices? How will we get our data out and how
can we connect with out internal databases or other external SaaS (Software as a Service) services to integrate
functionality?
Out of breath yet? When we're talking about an enterprise system, these questions and more are on the agenda. If
we shift this part of our project off to our highly trained technical team, they might start to think of this as the
scope of the entire project, when this is just the construction of our drill, not yet the making of the hole we need.
Configure me!
Aside from just getting our system working, there is also applying the functionality within that system to our
specific problems. I've seen Project Server deployments where the client gets Project Server up and running and
then realizes they have not allocated any funding for creating workflows, learning how to prioritize their portfolio
of projects, or learning how to make a single report. Just like Systems Analysis 101 back in college, we typically
start this part of the implementation at the far right side of a white board as we ask the business people who have
the actual business problem what "outputs" they'll need. I've spoken of this before in other writings so I won't
belabor it here, but the outputs should ultimately be business decisions. To make those decisions, what reports,
analysis, and, ultimately, data inputs do I need? We work our way from the right side of the screen to the left and
we end up with a list of all the building blocks we'll need in the form of data elements, analytical calculations, and
exports and reports that will need to be configured in the system. This configuration exercise can take weeks or
months depending on its complexity.
Often the types of resources we'll need for this aspect of the project are a combination of business analyst and
system expert, and it's common that while these people may be highly skilled in the functionality of the system
being deployed, they are not as skilled in the technical architecture. That makes having disconnected teams for two
critical elements of the system quite common. The less these two groups communicate, the more likely it is that
we'll face challenges later.
It's a process
It is impossible to deploy a new enterprise system and not affect the organization's processes. Even if you are
abandoning one centralized enterprise system and moving to its competitor, processes will change. In fact, if you
don't want your processes to change, then it is entirely possible that you don't have a problem that needs solving,
and herein lies yet another challenge. When a person's daily routine changes, it causes upset. I don't mean some of
the time. In my experience, upset at this time of change is a given. This is true even when the process change will
result in a better process! So thinking about how the processes will change and working with those who will be
affected is critical to the success of the project. However, the very experts who are critical to designing this change
in process are probably the same people who will be affected by that change, so this can be a challenging aspect of
the implementation. Usually, a skilled and experienced facilitator will work with the internal experts in guiding the
change in process that has become possible with the implementation of the new system. In our line of work, we see
this challenge all the time. "But the project managers have to do the timesheet approvals first," a new TimeControl
client tells us. "That's our process." When we explain that matrix approvals can allow project managers to do their
timesheet approvals as part of a larger, more effective process, we get upset; pushback. At this point, we have one
of our most experienced staff work with the people affected to ensure that their concerns are taken care of, and that
they are an integral part of how the process will change.
So the process people are probably not the configuration people or the technical people, yet if we don't have this
team planned for, all our hard work on the installation and configuration is probably not going to be deployed. This
team too must be part of our planning, included in communications and decisions made by the other two teams.
Training
"So, will we need training?" is unfortunately a question that is often asked last. Some training may come through
the process changes as that part of the project requires a lot of hands-on discussion, but what about the actual user
guide of how the new system will work in more of a step-by-step fashion? At one time, training was considered to
be a critical element of software deployments and clients expected to put aside about 20% of the total budget on it.
But, with the changes in software costs and speed of installation, gradually that 20% became less and less money. If
we're paying $20 per month per user for a system, should I put aside $4 per user for training? I can't promise it
won't go too far. There are many online subscription options for training, but none of that will take into account the
exact solution you've designed.
Trainers may come from the outside or may come from the configuration or process parts of the project, but they
are often people who are specialists rather than the people who actually did the implementation work. So even if
you've put funding aside for this team (and I hope you have), you still need to make sure that these people know
what the system they're training people in is actually designed to do. I've seen trainers arrive for Microsoft Project
Server and had them start explaining to users how to configure enterprise fields and set up business drivers in
portfolio analysis, only to have the users give a blank stare because their enterprise fields were already all set up
and they're not going to be using portfolio analysis in their initial roll out. Do your trainers even know the problem
this particular deployment is supposed to solve? They should. Thinking about training at the start of the project
gives it the greatest chance of success. The technical, configuration, and process teams can be putting critical data
aside all through their sections for the training that will ultimately be delivered. That means involving the training
team early.
Roll-out/acceptance/culture change
If you were forward thinking and put aside the resources to initiate these teams and have had all of them working
and communicating together through the project, then the roll-out of your new system is likely to go much
smoother than it might otherwise, but don't underestimate the resistance to culture change. Having key evangelists
available at the right time can be critical. Also, will all these team members be packing up and moving on to their
next project? There will be a lot of system knowledge wrapped up in these people by the time the project rolls out. I
was particularly impressed with one of our clients early last year. It was the IT department a large financial
organization. One of the concerns we surfaced to the key technical user who was evaluating the software early in
the project was "who will be the administrator once you wrap the project up?" "I will," he said. He was true to his
word. His skills and knowledge evolved through the multi-month deployment, which was a great success, and he
remains the key administrator still.
Wrapping up
There are a hundred other things to think about in how to make sure your teams are communicating and working
as part of a larger goal, and we've talked about only a few. Hopefully it is making you think already about your next
enterprise system deployment. "What about documentation?" you might be thinking. "What about technical
support?"
The key thing to remember is this: When you are planning an enterprise system deployment, you have to expand
your perspective to include not just the installation effort, but also the delivery of the completed solution. Make
sure the hole appears just where it should in just the right size, right depth, and right angle.
About the author

The Bat phone
The title of this article refers to Commissioner Gordon's liberal use of the Batphone whenever the City of Gotham
was in dire straits (from the 1970s "Batman" TV series).
This article is part of our "From the Trenches" collection. It relates the fictional "Batman" story to how, during an
EPM implementation, we at some time might wish we had access to a Batphone when we are in trouble. It also
discusses many ways to avoid getting into trouble during the implementation.
To download the Word version of this article, see The Batphone.
The Batphone
In 1966, the original Batman TV series came on the air. It lasted only 120 episodes but it changed a culture in ways
that last to this day. In the world of Batman and Robin (played by Adam West and Burt Ward), there was a 'bat'
solution to everything. No matter what the problem, Batman would have the solution. The Batmobile, Batboat,
Batplane, and Batcave all had their place. And if you were someone who needed help, no matter how difficult, how
could you reach Batman? Well, with the Batphone of course! Pick up the Batphone and help would be on the way.
Commissioner Gordon would turn to the Batphone when things where hopeless, which occurred of course every
episode. It didn't matter how difficult the challenge, pick up the Batphone and in 22 minutes (plus time for
commercials) the villain would be vanquished and Gotham City returned to peaceful status.
Every solution in the Batman world was made to look like a Bat. Handcuffs? Bat shaped. Utility belt? Bat logos.
Grappling hook? Of course — looks like bat wings. To my surprise, looking back at images of the Batphone it
looked upsettingly normal. A red phone with a dial (remember those?) I'm not sure why it had a dial. It only called
one place: The Batcave, where salvation was at hand.
As nostalgic as it may be to think of phones with dials and the old episodes of Batman, it's really not the point of
today's article. It's been 40 years since the Batphone was retired, but people make calls to EPM consultants every
day hoping the Batphone will work for just one more call.
Their villains are varied. Some are technical; they need to upgrade from version x to version y. Some are
architectural; they need to make their internal EPM system talk to users in the outside world. Some are cultural; the
users refuse to use the system. And some are procedural; the process they're following doesn't seem to deliver the
result they expected.
No matter what the challenge, the request for the consulting firm is the same: Can you fix it in 22 minutes?
It's a situation that a surprising number of EPM users get into — a situation where they urgently need assistance to
get them out of a difficult situation. It's often an emergency and the solution is required by management yesterday.
The people who make these calls (I get a couple each week) are not feeble-minded. They are highly intelligent,
capable, accomplished managers.
There is no Batphone, of course. I wish there were. I'd use it for all kinds of personal challenges. And so the people
making these calls are rarely satisfied with the answers they get. So, let's take a few moments and talk about how
people end up in such a tight spot that they feel that need to pick up the red phone and how you can avoid being
one of them.
Getting into trouble
First let's talk about how people get into trouble while doing an EPM implementation. There are a couple of
common causes:
Underestimating the challenge This is, by far, the most common error in an EPM deployment. It's not to
say that every deployment must be large and difficult. That's certainly not always the case. But, perhaps
because of wishful thinking, it's incredibly common to underestimate what it will take to get the benefits
from an EPM deployment. The first error in underestimating is picking the target. Some people pick the
installation of the tool as a successful project. It's not, of course. Some people pick the first use of the tool or
the first report that comes out of the tool as the target. That's not it, either. A resolution of whatever
problem(s) the EPM tools were chosen for is where you need to target. That means that the culture has
changed, the training is complete, the usage is in production, the tools are working, the data is there. Yes,
that may be a big thing — but if you're one inch short of that goal, you've still got nothing. (Well, almost
nothing, anyway.)
Making it a technical project For those of us in the technology business, we're most guilty of this and
really, most of us know better. Yet, somehow, the temptation to believe that the availability of technology
means the problem is resolved is hard to resist. So many organizations we visit say some variation of "but
we installed Project Server, why are our personnel overloaded? As we've said for some time, making
enterprise project management work is a combination of people, technology and process and a good deal of
change management thrown in for good measure. That doesn't arrive automatically when the software DVD
rolls through the door.
Not involving management This, too, happens very often. After all, the people who best understand the
benefits of an enterprise project management system are most likely those who are struggling to analyze
the vast amounts of data that come from an environment with many projects and many resources.
Enterprise project management is most popular when an organization tries to reconcile a complex set of
conflicting priorities and a myriad combination of skills and experience. You would think that management
would naturally be involved in such a project but it's often not the case. The challenge of changing the
corporate culture from a single project mentality to an enterprise project mentality is almost impossible to
overcome without them and yet all too often management is bypassed due to a worry that they will be
unable to appreciate what it will take to get an EPM deployment completed.
Making unrealistic schedules There is no one who wishes that an EPM deployment will take a long time.
And it's common to hope that the project can be accomplished in days or a couple of weeks rather than the
months that is most common. There is also a common challenge of not getting the resources for an
"internal" project such as EPM as readily as a client-based or commercial project. For these and other
reasons, it's common to make a project schedule with resource requirements that are woefully insufficient.
Not applying project management to the project management system If you've read anything I've
written, the chances are you've seen this before. Project managers are susceptible to the "shoemaker whose
children are barefoot" syndrome. The result is a common lack of a project charter, an approved budget, a
tracked schedule, dedicated resources and all the other accoutrements for their own project that are
common to all the other projects they manage.
What were they expecting?
Ok, that's how people so often get themselves in trouble. The benefits expected by management from the
deployment of an EPM system usually come directly from business challenges. It's the promise of solving those
challenges that bring management to approve the expenditures for software, hardware, infrastructure and possibly
even services. The most common of these challenges may sound familiar:
Resources are overloaded It may not be clear what the resources are being spent on, but it's very common
to find that resources are overloaded. A more complex problem is finding that some resources are
overloaded and others are under-loaded, which often indicates a mismatch between skills and experience
available vs. those required.
Critical projects are not being completed in a timely fashion It should be obvious that critical projects
should finish when they're planned, but life seems to interrupt such plans. This may be due to conflicting
resource requirements, choosing too many projects that require too many of the same skill, or just bad
prioritization. Sometimes organizations will think it's a lack of skill of the project manager but in a multi-
project, multi-department matrix environment, the more likely culprit is organizational in nature.
Projects are not being completed within budget What holds true for the schedule can equally apply to
costs. In high-tech as well as many other industries, the most variable component of a project's cost is the
amount of labor applied to it. Take a lot longer with the same people and you're adding costs to the project.
A stunning number of white-collar projects still remain untracked. They're planned but the actual cost per
project is not recorded.
Your competition is completing projects faster than you are In a competitive economy, being first to
market can make the difference between survival and oblivion. So, for many organizations, making sure that
your project management is at least as effective as your competitors is important.
There is no visibility into what a projects resources are spending their time on or no way to know
how much time is being spent on each project Sometimes no answer is worse than a bad answer. If
you're in senior management this is particularly true. If you know the results are bad, you can apply your
skills and the resources at your disposal to the problem at hand. If you know something is wrong but can't
tell what, you're handcuffed. There's no way to know where to try to fix something.
How do I keep out of trouble?
You don't want to ever get to a point where you feel you need the Batphone. So, what can you do with your EPM
environment to ensure that you don't end up there?
Okay, everything we said in the first section is obvious:
Do a good estimate
Don't think EPM is just a technical project
Involve senior management from the very beginning
Make a realistic schedule and give it a reality check by comparing it to others in your industry
Make a project schedule and project charter, and do all the things you normally do with your other projects
What else can you do?
First of all, start the project with an appreciation that at some point in the future, you're going to want to use the
Batphone. You are. Knowing that, one thing you can do is to budget for assistance that you have no current plan for.
We recommend that our clients budget 10% to 20% of the project for "unallocated requirements". "What's that
for?" we're always asked. "You'll tell us later," we always answer. It's common to not use all that money. But it's also
incredibly common to use some of it. Having a skilled expert already allocated and budget for your project makes a
huge difference later.
Start with the expectation that the plan and the people will change. My favorite project management quote is from
Napoleon Bonaparte, who said, "A battle plan lasts until contact with the enemy." It's true of EPM plans, too. Given
that an implementation is likely to last several months, the chance that some personnel will change in the plan is
enormous. So, plan for redundancy.
EPM systems evolve. It's common these days in an enterprise application to think of the "total cost of ownership". I
think we should include the total application lifecycle in our EPM project plans. Have you thought about what
version of a tool you're about to implement? Did you think about what other tools it depends on? How about the
regular update/upgrade of those tools? Did you do customizations? How about customized training? Did you think
of how those things will migrate to a new version should you deploy one?
Plan for redundancy of your experts, also. If you have a single consultant working for you, what will happen in a
few months as you move to a new phase of your implementation or introduce a new key member of your team?
Will that consultant be available? (Consultants move from one project to the next so the answer is often, "no".) If
you work with a consulting firm, have you talked about how they can preserve the work of their staff to have others
replicate it, if necessary?
Put that in writing
One of the most common and easiest-to-fix challenges comes from poor documentation. It's the easiest element to
short-change but the existence of such documentation can make the difference between going back to a written
reference and looking around for the Batphone. It's also not enough to write a document and stuff it into a drawer
somewhere. Documents should become part of an ongoing record and your EPM process might reference them as
part of a regular review process. Here are some of the documents for an EPM environment that I think are most
critical:
Business Case I don't know what it is about the original business case that makes it so unattractive, but it's
the most common thing to lose track of and in many respects, it's the kernel of why you have an EPM
environment in the first place. The business case notes what the expected organizational benefits are; what
does the organization expect from the EPM system? When we get a Batphone call, one of the very first
things we ask is, "What is the system expected to be delivering for you?" We don't just ask the administrator.
We also ask management, the users, and the business beneficiaries. The most common answer is a different
answer from each party. That's because the original business premise has become lost.
Roles and responsibilities In the last version of roles and responsibilities, we often resolve to an
individual's name, and it doesn't take long before the role that individual plays in the EPM system is
forgotten. Keeping a roles and responsibilities document will allow you to adjust the parameters of who
does what in the EPM process as the organization naturally goes through personnel changes or even
organizational structure changes.
Process Guide and Flowchart This is often forgotten when we get down to procedural guides. People are
left with the "What-to-do" steps in a procedural manual but not the context for why those steps are
important and what we do with the result of each step. A process guide and, best of all, a visual flowchart
will let future managers understand what the system provides and make it much easier to adapt the system
in the future.
System Selection Criteria When you choose your EPM system and any third party tools you may have
selected along the way, let future generations know what your decision was based on. We've gone into
organizations 5, 7, or even 10 years after a system was deployed and seen a system with several tools
associated with it and asked "Why are you doing that? It would be much easier doing this!" The reasons for
those decisions are nowhere to be found. In some cases the client has spent years doing something in an
extremely complicated fashion that could have been so much easier given more current versions of existing
tools. They can't make an easy decision to change a tool or use a more current version because they no
longer have access to why they chose to do something a certain way years ago.
There really is no Batphone.
When I say that, it feels like I'm saying there really is no Easter Bunny or no Santa Claus. It's just bad news. But
there really is no Batphone. I'm sure, though, that just the absence of that magical phone won't stop people from
calling me tomorrow asking me to vanquish Gotham City's latest villain. If you get into trouble and feel the need to
call an expert, here are a few recommendations:
1. Listen to the advice you get. It is silly to pay an expert to give you advice and then decide you know better
than they do. If you're going to ask for advice and you're dealing with an expert, try to listen and at least
consider the advice. Batman wouldn't have kept showing up for Commissioner Gordon time and time again
if each time he did so, Gordon said, "Now that you're here, Batman, please do the same thing all my other
policemen do."
2. Batman could do it in 22 minutes, but you probably won't. If you're calling an expert, let him tell you how
long it should take to fix your challenge. You can elect not to fix it after he's done, but fixing EPM challenges,
even technical ones, rarely takes only a few minutes. After all, Batman had to do it in 22 minutes because 8
minutes were allocated for commercials, and they are essential.
3. Commissioner Gordon never told Batman the solution, only the problem. All too often we get a call from a
panicky EPM administrator who knows that I need to apply a patch, write a report, and train two people. I
always listen to this patiently and then ask the client to describe the problem as they've just described to me
the solution. Before you pick up the phone to call an expert, think first about what problem you'd like to lay
on their table.
Conclusion
You really need to use the Batphone. Ask around. Don't ask just one consulting expert and don't get just one
possible solution. Ask your colleagues or others in industry who they know who might take a Batphone call, and
talk to at least two of them. It's a good reality check to see how one expert vs. another might deal with your
problem. Remember, Batman may have been amazing, but there are many superheroes to choose from!
About the Author

This article is part of our "From the Trenches" collection. It describes the challenges facing someone who
implements Enterprise Project Management (EPM ) in an organization that uses a matrix project management
environment.
To download the Word version of this article, see Balancing the matrix: white paper.

In project management circles we tend to talk often about a matrix management environment. Matrix management
isn't anything new. It has become the de facto standard for management in virtually all high-tech organizations.
The idea of matrix management came out of management thinking in the early 70s. J.R. Galbraith gives us one of
the first published works on the subject in 1971 talking about how to combine organizational and functional
responsibilities. The prevailing management environment at the time was hierarchical.
Organizations were huge silos of departments ruled by strong department leaders. That works great until there is
more than one project that must span more than one department in order to be completed. The notion of a
'projectized' matrix has been promoted by project managers and associations like the Project Management
Institute for over 30 years.
In a projectized matrix, we establish a second axis to our organization and we give some responsibility to that part
of the organization that manages projects. The result has organizational departments along one side of the display
and project managers delivering projects or products down the other.
Why talk about this while talking about Enterprise Project Management? Because this model has become the
cornerstone of virtually every Microsoft EPM Solution deployment. If you're now working on deployment of
Project Server then you're sure to run into this model in your travels. There are exceptions to the Matrix
Management model which I'll discuss before I'm done here, but suffice it to say that it is close to universal if we
look at technology organizations.
If you're now working on a Microsoft EPM Solution deployment, you'll find an organization in one of several states:
1. There is no matrix
The organization is completely silo-based. Each department head manages his or her own department as if
it were a subsidiary of the larger organization. Budgets are summarized upwards through the departments
in a hierarchical fashion (think of an Organigram). When a project is initiated it is done within each
department even when resources might be required from other departments to complete the project. If the
project can't be completed with the resources from the department that is managing it, then outside
resources are negotiated as inter-department requests.
That actually doesn't sound too bad until you try to manage such a project. If almost every project requires
inter-department resources, then figuring out the priorities between groups is impossible. There is no
incentive for any one department head to relinquish control over the priority of his or her own resources. It's
counter-intuitive to give up such power, so any project that can't be completed within a single department
suffers.
Moreover, when we talk to executives who are one level higher than the department heads, the universal
lament is that they cannot get any resource capacity planning. This makes perfect sense. There is no cross-
department structure for aggregating the information we'd need for resource capacity planning nor any
incentive for each department head to submit to the centralized prioritization that would be required for
such an analysis.
It's entirely likely in this situation that we'll find not one but multiple project offices—one per department
which cooperate very little with each other.
Deploying the Microsoft EPM Solution into this kind of scenario requires doing some thinking about how to
adjust the organization at the same time. Often we get calls from these kinds of companies asking us to do
the impossible. Train hundreds or even thousands of users, get Project Server installed and be in production
in a couple of weeks. The expectation is that because the company has purchased a centralized enterprise
project management system, then the organization will immediately line up and operate as a centralized
matrixed environment. It's an expensive fantasy. Inevitably, we have to talk with senior management about
how the organization will have to be changed. That's typically not great news for management who were
hoping that just purchasing the software would be enough of a commitment to have everyone change.
We start such projects by working on plans for a centralized project management office and centralized
project management procedures. Project Server gets introduced slowly from the middle out. It's not
uncommon for such projects to take 12 to 24 months until the entire organization is finally involved. We just
re-started such a project after a 2½ year delay while they worked on their own to create a PMO.
2. There is a balanced matrix
It's great when this happens but it's unfortunately quite unusual. Maintaining a balanced matrix requires
constant adjustment and care. But, when we do find a balanced matrix, we're also likely to find a highly
evolved set of procedures, defined roles, and a process that's well understood by everyone involved.
Deploying the Microsoft EPM Solution into this kind of organization is the best-case scenario.
3. There is a matrix but it is unbalanced
This is by far the most common scenario we face and it makes perfect sense. The matrix model carries some
inherent conflicts, so we often find the matrix either weighted towards the department with a weak PMO or
weighted towards the PMO with weak department heads. Or (and this is by far the most challenging) we
find the matrix weighted towards some departments but not others and some project managers but not
others, so that the center of gravity in the organization is hard to come by.
Deploying the Microsoft EPM solution in these environments means doing some inventory and discovery
work. Where have processes been established that are successful? Where have processes failed? What is
working at the centralized project management level which we can leverage to deploy Project Server and
what is not?
In these types of deployments, we need to be very careful to pick and choose the elements of the EPM
Solution we want to deploy first and whom to deploy them to. Deploying in a phased approach in this kind
of scenario is critical, as a big-bang approach is almost never successful here.
The Matrix Challenge
For those who have grown up knowing only matrix structured organizations, you might not even think to wonder
whether it's a good structure or bad or think of what is strong or weak about this kind of management. There is a
fundamental challenge with the matrix organization that many don't even question: it is conflict-by-design. The
structure sets up two opposing forces: the Department heads and the Project Managers. We'd never say this out
loud of course, but just looking at the structure makes it self-evident.
The goal of the department head is to watch out for the staff members in the department. They want to make sure
their people are productive, skilled, satisfied employees. If we were to leave the organization just up to the
department heads, we'd end up with delighted employees who were well-trained, not too overworked, and well
compensated, but who didn't produce much.
The goal of the project manager is to watch out for the delivery of the project. They want to make sure their project
is done as quickly and cheaply as possible while maintaining the scope and quality that were defined at the
project's inception. If we were to leave the organization just up to the project managers, we'd end up with some
projects getting done quickly but a huge turnover in staff as we burned out employees in the name of completing
the project.
The idea of the Matrix Organization is that setting up a conflict between these two forces will happily balance the
organization between productivity and employee satisfaction. The premise, though, is that department heads and
project managers are ultimately all pretty much as powerful as each other. The challenge, of course, is that people
are not created equal. There will always be some project manager who is more experienced than another; some
department head who is more skilled than the next.
This lack of equality throws the Matrix out of balance on the first day. Just realizing that the exception is a balanced
Matrix Organization often is enough to have PMOs and organizers think about how to maintain order, and that can
be a good thing.
Getting a perfect balance isn't as important as making sure that there's some effort towards identifying where the
organization's projects and people get stuck. The tools to make a matrix environment work are always the same:
processes and communication. A skilled implementer can identify processes and procedures that establish what's
important to the organization.
Giving up the matrix?
Not everyone is a fan of the Matrix Organization. In the last few years, a number of business leaders have voiced
the thought that perhaps the Matrix Organization thinking isn't the best plan. "Divide personnel into dedicated
project teams," they say "and you'll be happier for it," or "Organize projects to work within each department and
give them to the department heads." For more on this, take a look at this article by Rob Enderle to see someone
who thinks the Matrix model should be retired.
In a number of organizations I've visited lately, I've seen matrix models that have been skewed in one direction or
another and each situation causes me to make recommendations that are a bit different in how to deploy Project
Server and the Microsoft EPM solution. If there is no centralized PMO at all then that becomes my first
recommendation. I've had some organizations approach me saying that they want to use Project Server just to
reduce license costs but don't have any intention to work together. That doesn't make a lot of sense. The whole idea
of a centralized enterprise project system is to bring data together for analysis and display to allow projects to be
managed together. If you don't have any intention to do that, stick with individual Desktop licenses.
In some organizations the Matrix model has been displaced by a return to silo thinking. This kind of thing can
happen when there is a big organizational change or external stimulus from, say, a big change in the economy.
When pressured, some managers will fight for survival by any means possible. I've seen several large
organizations recently where department heads successfully described the PMO and their personnel as "redundant
project resources" and lobbied to return control to the department heads.
The result of such changes can have the exact opposite effect of what was intended. True, costs drop for a short
period, but the loss of efficiency of people whose job it was to generate efficiency through shorter, cheaper projects
often carries a rebound awhile later. Still, with large organizations, it can take months or even a year or two before
these effects are realized. In the meantime, the Matrix collapses and the power of Project Server can be inhibited.
In the more progressive organization, new emphasis might be placed on the PMO with a newfound respect for its
capabilities and, perhaps, even a new level of authority in the face of a challenging economy.
Restoring (or establishing) balance
For those working on or about to work on EPM deployments, here are a few things to think about with regard to
the Matrix Management environment you encounter:
First of all, look for the processes and the definitions of roles for each axis of the matrix. While doing interviews,
look for where the processes are making the organization more productive as opposed to more bureaucratic.
When looking at roles, watch out for the classic "responsibility without authority" challenge that is so often talked
about in project management circles.
If you're starting from scratch, you can still find processes in the hierarchical structure that can be adopted and
those might well be worth a lot to you. If you can find an existing process or procedure within a department that
could be adopted by the entire enterprise, then acknowledging the source of the process gets you two things
instantly: First, you have one process in one department that doesn't need to be deployed. It has already been
adopted. Second, you can end up with a big ally in your efforts to create the second axis of the matrix where the
department head involved can see evidence that you're not intending to throw out everything that has already
been done by the departments.
If you're creating processes that go across departments and you will have to, then think about involving the very
people who might feel disenfranchised. For example, I was assisting an organization recently who had to create a
cross-department resource capacity planning process. Needless to say, the department heads weren't overjoyed at
this idea as they felt that they would lose some measure of control over the management of their own staff. I
recommended creating a portfolio steering committee (including among its members those department heads)
that would establish project priorities. The department heads wouldn't feel the authority was being taken from
them; instead they'd be included in the new structure of authority for making cross-department decisions. Working
this way deflected an otherwise challenging aspect of an EPM Deployment by including the very people who
would otherwise oppose it.
Finally, think about going "light" on your deployment and establishing the centralized procedures without excessive
intervention by working in layers. For example, we're working on a project where the matrix is very
organizationally strong. The PMO is in its infancy, and pushing hard against the organizational structure isn't ideal.
We've recommended not working down to the individual level for resource management to start. The organization
instead will deploy resource management as a centralized process with a very small number of users attached
either directly or as emissaries from the departments to the PMO. Resources will all be defined as generic and the
goal will not be to drive to the individual task level for each employee to start. Instead, the PMO will start doing
resource capacity planning by identifying aggregate resource challenges in upcoming periods and then turning the
problem over to the department heads to manage. We expect that in time, there will be demand from the
department heads themselves to push the EPM deployment wider to ease the work they have managing resource
conflicts themselves.
Conclusion
Regardless of whether you're deploying enterprise project management as a consultant for others or if you're
deploying your own EPM within your own organization, you're almost certain to have to confront the challenges of
the Matrix Organization. Keeping your matrix balanced is one of the key challenges of EPM and EPM systems like
the Microsoft EPM Solution to making them successful.
About the Author

This article is part of our "From the Trenches" collection. It describes best practices for defining your organization's
charge code structure for the project management system or timesheet system.
To download the Word version of this article, see Charging Ahead on Charge Codes.

I'm often asked to help organizations define their charge code structure, either for their project management
system or their timesheet system. While it's true that every organization is different and different needs result in
different types of charges, there are some common practices we've found over the years that are universal.
Ask less, not more
No one likes bureaucracy, so the more complex a charge code structure you make, the less likely it will be that
people make accurate reports. Imagine, for example, that I make a list of 10,000 charge codes in a long flat list to
choose from. You might have to scroll for an hour, examining each possible entry in a drop-down list before you'd
find the exact right choice for this particular timesheet or project update. Then you'd need to scroll through the rest
of the list to make sure you didn't find something that wasn't just a little more exact.
Let's not be silly. No one will do that. They'll take the first entry that seems reasonably close and choose that.
Failing that, all hours will ultimately end up in charge "999:Miscellaneous".
So make your list simple. Ideally, it should not require scrolling at all, but should be visible on a single screen or
perhaps with one more click. That means that you're only choosing from 20-30 possible options at most. In this
case, less is more.
If management is determined to get much more detail, remind them that it is better to get more accuracy and less
detail than more detail and less accuracy.
Don't ask what you know already
I've seen many charge code structures where there is an identical charge code for each department or each project.
Yet, if people are already being asked to choose the project and we're doing an entry for meetings for example, then
I know that the line item must be "meetings on this project" so why pollute the charge list with multiple meeting
items? The same logic holds with departments. If we have a list of employees who belong to each department, then
we already know what department they're in. Why pollute the charge list with "Sales department meeting",
"Technical department meeting" and, "Marketing department meeting". Just make one item called "Meeting" and
we can deduce from the employee's department and the project they're on what the meeting was for.
Be resolved to better resolution
Picking an appropriate level of resolution for your project and your timesheet is a common challenge. Think about
what level you want to manage things in with these conditions: 1) There needs to be more value in the data than in
the time to collect it, so if you spend all day reporting on your day, how will you actually get anything done? 2)
Work at a level that you're prepared to make decisions on. 3) The more complex it is to enter, the less likely you are
to get accurate data. 4) When possible, get everyone working at the same level of resolution so you're not
managing one group in tasks that are 10 minutes long and another in tasks that are 3 days long. For many people,
being able report 3-5 lines of detail for a given day is plenty of detail.
Condition your data
Some people will make the end user answer the same questions over and over. For example, we've seen systems
with a column for "R&D" meaning that this charge is or is not a charge eligible for an R&D tax credit. But we
should be able to associate the eligibility to the task itself rather than each line of each person's timesheet.
Moreover, what would I do if some users thought that it was eligible and some users thought that it wasn't? This
likely scenario also plays out in examples such as, "Design-eligible for R&D" and "Design-not-eligible for R&D".
This doubles the number of charge codes for no return in value. Just have someone in R&D flag each drop down
value as eligible or not and you won't have to keep asking end users to try to figure it out each week.
Hierarchical
Better project and timesheet systems allow a hierarchical display of data. If you have no choice but to have a lot of
possible choices, then building a hierarchy can make a lot of data easier to swallow. Think of 5-10 items at
maximum to choose from at each level. And don't be tempted to make dozens of levels. Making a 3-4 level
hierarchy should be able to cover most options. After all, 10 items per level in a 4-level system is 10,000 possible
charges. Is your project more complex than that?
Show me less
The fewer questions and choices you give your users, the better off you'll be. If there is anything you can answer in
the background then try not to ask it of users on your timesheet. The goal is not to collect the most data possible,
it's to collect as accurate a picture as possible, and you'll do better at that if you insulate the end users from data,
questions, and options that make no difference to them.
What will you do with that data?
I'm often told by middle-management types that they need "much more detail" than I'm suggesting and my
response is always the same: "What will you do with it?" The purpose of gathering task-based timesheet data is to
make better business decisions, so I'll often ask those middle managers what business decision they're not able to
make now that they think they'd do better at if they had more detail. When you start to look at information that
way, you find that you probably need less of it. It might be enough to find out just the total number of hours spent
in meetings or in transit or in overhead tasks than to find out what every one of those tasks was.
Drill deeper… but only when you must
When you start to do timesheet analysis to figure out where your hours are all going, you are bound to find some
disproportionate results. Where you find an unusually high percentage of hours that defy expectation, drill a little
deeper. But not too deep. Add one more layer of detail for that charge and give it a few weeks to see what data you
get. The temptation will be to expand a single charge code like "meetings" into 50 new charge codes with every
possible type of meeting that could occur. Try resisting this temptation and instead change that 1 charge code into 5
or 6. If you don't get the detail or you still have disproportionate results, delve a little deeper.
Keep a clean house
Charge lists have a tendency to increase in size but never decrease. It's a good practice to review them on a regular
basis and eliminate bloat. If you do, you're more likely to continue to get more accurate information and be able to
identify areas where you're losing time.
Conclusion
Charge code management—whether it is for your project schedule or your timesheet system—can make the
difference between an efficient system from which data can be counted on or a system with too much definition
and not enough accuracy. When you design your charge code structure, we recommend starting with less, not
more. It's much easier to add more detail later if it is required than it is to undo more detail and make it simpler for
overwhelmed users.
About the Author

Being a solutions buyer
This article is part of our "From the Trenches" collection. It describes how prospective software purchasers can
make interactions with software vendors more effective by applying easily understood business analysis methods.
It walks you through an exercise that can help create software evaluation criteria by effectively determining what
problems need to be addressed by the software solution.
Being a Solutions Buyer

All too often, a software purchase is based on a list of features, an advertising campaign, or a friend's
recommendation. This article describes how prospective software purchasers can make interactions with software
vendors more effective by applying easily understood business analysis methods.
It's sure not like it used to be. Getting software working in an enterprise setting isn't even referred to as installation
any more. Nowadays, the terms implementation or deployment better describe what is needed to get a new
package up and running.
More and more software vendors are speaking about what they sell as solutions, and it's no wonder. When we
think about deploying an enterprise system like Microsoft Project Server or Microsoft CRM, we have to first think
about the different layers of technology that will be involved, and—before we even get to that—we have to think
about the impact on our overall business.
With solutions to sell comes, of course, solutions sales. If you've followed this at all, you know that almost every
high tech organization on the planet that targets mid to large organizations is working to re-create itself as a
solutions sales deliverer. Microsoft is certainly among these organizations. Microsoft has worked extensively over
the last few years to establish solutions selling as a guiding principle in its field sales and implementation forces.
So what is a solutions salesperson? It's true they're still a salesperson. However, solutions salespeople aim not just
to move a box of software, but to build something that helps the client improve their situation.
Sounds great so far; a Nirvana of salespeople all looking to improve your lot in life. But this does come with a
challenge, and addressing that challenge is something in which you—the prospective client—can participate.
Focusing on the problem
The challenge that most solutions salespeople face when they arrive to the market is our preconception about what
a solution should look like. We're so used to focusing on functions and features of software, when we speak to a
software salesperson the conversation almost inevitably leads directly to, "Can your software do this? Can your
software do that?" Experienced software salespeople—and those are the types who are moved into solutions
selling positions—are so used to selling functions and features that they often forget to ask the most basic
question of all: "What is the problem?"
Now this may sound silly, but if you think about your last few conversations with software salespeople, you might
be surprised at how rarely this question comes up. Vendors like Microsoft and its partners receive many Requests
for Proposals each year. I've seen hundreds of them over the years, and one thing that is almost always present is a
long grid of functions that the vendor is expected to fill in. This large spreadsheet often is the core of the reply to
the client.
What is rarely present is a description of the business needs that will be addressed by each of these functions. It's
so easy to get caught up in a feature we're familiar with from a previous product or that we've seen promoted
somewhere that it takes real discipline to focus on what got us interested in this new product in first place. This can
be especially so in an enterprise setting where there is a lot of input into what type of solution is being sought. It's
much easier to send out a request asking for people to list all the functions that they'd like in a new software
system than it is to talk about their particular business needs.
If you're starting to think that perhaps you've been missing something obvious, you're not alone. This condition is
so prevalent in the software industry at the moment that a new category of consultant called Business Analyst has
sprung up. These people are trained to make the connection from business need to software functionality. Let's
take a few minutes to see how you can apply the basic concepts—in the way that a Business Analyst would apply
them—in your evaluations of enterprise level software.
Identifying the business need
The first thing to think about is what business need brought you to look for a new software system in the first
place. Our own organization often consults companies on implementing enterprise project management software.
When I arrive in an organization as a consultant, long before we talk about whether to buy software, I ask how the
organization is doing project management right now.
When they finish their answer, I always ask this follow -up question: "Is that method working for you?" Surprisingly,
the client often answers that it is. For me the implementation conversation has to stop there. "If there's no
problem," I explain, "there's no way for me to craft a solution!" Often this answer makes people pause. "Why were
we called in?" I'll ask. The answers can vary widely, and it's not uncommon for people to look around the room
realizing that there are several agendas under way which must be reconciled—and our conversation is less than
five minutes old!
So, asking "What is our business need?" is a great place to start. There is almost always an overall goal which
answers this question—a goal that jump-started the initiative in the first place.
Conducting a vision exercise
Next you'll need to look a little deeper into what this means in terms of software functionality. When we implement
enterprise project management software like Microsoft Project Server into an organization, we always start with a
vision exercise which involves the key personnel—those who are evaluating the software—and the senior
management—those who are sponsoring the exercise. It's not enough to do this exercise with just technical
personnel, because the objective of this exercise is to connect business goals to technical functions.
Here's an effective way to do this: Put the key personnel into a room with a big whiteboard. Divide the whiteboard
into 4 columns: Start with a heading in only the far right column. Call it "Business Decision."
In the right column you are going to list business decisions you hope to make by using the new system you are
considering. When we do this with a client, the first thing people want to do is to list a lot of features, so you'll have
to insist that the answers which are important are business decisions. For example, a participant may immediately
say, "I need a list of all resources and their workload." That may be true, of course, but what you need to find out is
what business decision they will make with that list.
Some examples of business decisions might be:
Hiring or firing in a particular department
Making a go or no-go decision on a project
Once you've got a decent list of business decisions, pause. Now is a good time to review the business decision list
and identify the top priority decisions. You might want to ask yourselves this question: If you could only get
answers for one of these business decisions, which would deliver the most value to the organization? Picking the
top three decisions is always easiest at this point in the process.
If you have gotten this far, you've already accomplished more than most organizations that seek out enterprise
project management software. Being able to provide a prioritized list of the most significant business decisions to
systems vendors is a huge step forward for the entire process. When you can tell system vendors what business
decisions you need to make, they are empowered to move beyond talking about simple functionality to talking
about how to make the organization more effective.
Next, look at each decision and ask, "In order to make that business decision, what report would you require?"
Virtually every decision is made after looking at one or more reports. Label the 3rd column "Report." For each of
the top three decisions, list in that column the reports required for the corresponding decision.
For example, we might say that to determine whether to hire or fire personnel for a particular department, we
need a report by department showing the resource capacity planning data. This includes a forward forecast of
expected workload, expected resource availability, and schedule. If you are a mid-sized business, the cash flow
might also be a concern. You might, for example, have a need for additional personnel but not be able to find the
cash to hire them. The cash flow report would include estimated incomes and outflows of money with a running
balance.
If we fill in the Report column for each of the decisions we've identified as our priorities, the shape of what we'll
require is already starting to become clear. Once you're done, you've got a list of physical output that you require
from your prospective system.
Pause again here to find out if there are already reports of the type you've identified already in use in the
organization. Chances are that such reports exist, but in numerous formats and possibly with either incomplete
data or with excessive effort required to generate them. If you find formats of reports that have worked in the
organization, you can add these to your list of systems requirements. Now you can provide even more information
to the system vendors.
With the key reports now identified, we can move to the elements of a system required to generate those reports.
Add the heading "Analysis" to the 2nd column of the chart. For each report, identify the analyses or algorithms
that are required to generate the report. For example, for a resource capacity planning report, we might require a
critical path schedule from the project management system and a resource leveling analysis.
These analyses will often be marketed by vendors on the basis of the myriad of features that each includes. (Yes,
feature-by-feature selling is still alive and well!) What you need to be able to determine is the minimal functionality
that will deliver the reports you require with which you can then make or improve the business decision that you
have identified. You may be surprised at how basic is the functionality that you require in order to fulfill your actual
business requirements. For some reports, no analysis or calculations will be required at all; the reports need only
to be simple aggregates that can be generated right out of the new system's data.
Finally, we come to the first column in our chart. Once you've identified the analyses required, you can move to
determining what elements of data are required to feed the analyses.
Add the heading "Input" to the 1st column of your chart.
In the example we've been using, we might require a complete list of tasks for each project implicated in the
department's work. This might very well be every project in the organization. We'll also need a complete profile of
the availability of each resource along with the workload defined on each task such that when the task moves in
the schedule analysis, the workload moves in the resource leveling analysis. Also, remember how we started with
the decision of hiring or firing in a particular department? We'll also need to be able to identify the resources by
department.
We can move like this from the outputs on the right to the inputs on the left until we have identified everything
we'll need in our new enterprise system.
Assessing risks
Once this exercise is complete, it's worthwhile to go back to each of the inputs and determine how available these
elements of data are. You might find—as we often do—that some of these items don't even exist. For example,
some organizations don't maintain a complete list of resource availability. You might also find that not every
project has a resource-loaded schedule showing the resource load generated by that project. In many
organizations, certain types of projects aren't put into a system of any kind. Emergency work, technical support
work, or regular maintenance work are some common examples.
If you don't have access to the fundamental data you'll require to deliver the business value, you've got to look at
that element of the system as high-risk. For example, if we find that we can identify resource-loaded schedules for
80% of the organization's projects, can we reasonably expect to improve our business decision to increase or
decrease staff? The answer is likely, "No." Why? Because perhaps the 20% of projects that are not in the system
might represent 80% of the work load for a particular department. If you don't have all the data, you'll never know
whether the final report is accurate.
There are ways around these kinds of problems, of course. One method is to isolate all the business processes of
those aspects of the organization where you can't get access to the data elements. A division whose projects might
not be in the system wouldn't have their resources listed either. This can't be done so simply in every case; you'll
have to look item-by-item to figure out how much risk those business process and business decisions are to your
implementation. It's not uncommon at this point in the process to re-prioritize the final business decisions you
hope to improve. You might have a decision that is very desirable but turns out to be very high risk and therefore
not worth pursuing in the early phases of your deployment.
Documenting what you've done
When you conduct this kind of meeting, assign a scribe—someone whose job it will be to record notes and
comments throughout the process. The reasons why a particular business decision was ranked as a high or low
priority or why something was considered high risk will be quickly forgotten if you don't have good notes to refer
back to.
It is very important to record:
What you have written on the whiteboard
Who participated in the process
Who owns each final business decision
If you're feeling overwhelmed at this point, don't fear. This entire exercise can be accomplished very quickly, even in
the largest organizations. It is not uncommon to be able to complete the entire process in a day or perhaps two.
The key to being successful is getting the right level of management into the room. Moreover, this type of meeting
is best facilitated by someone from outside the organization who is not predisposed to do things the way they have
always been done.
Knowledge is power
If you're looking at enterprise project management systems—indeed, at enterprise systems of any kind—
completing this exercise gives you a tremendous amount of power when you interact with software systems
vendors. You can immediately distinguish between those elements of a system that are important to you and those
that are not. Software vendors can be provided with the list of reports and decisions that you want to make.
You might be surprised at some of the responses that come back to you from the vendors. Freed up to respond in
a way other than on a feature-by-feature basis—that is, trying to fit a square function into a round requirement—
the better vendors will be able to show you how you can answer your business challenges by using their systems
to their best advantage.
Here is the biggest benefit of conducting this exercise: You have created ready-made evaluation criteria. Now,
during the proof-of-concept phase, you can immediately focus on whether the system delivers the information you
need to improve the business decisions you must make.
About the Author

Track or Treat
This article is part of our "From the Trenches" collection. It describes the advantages to tracking project work,
discusses tracking methods, and explains the difference between tracking time and tracking progress.
Track or treat
It's the Halloween season here in North America so I thought we'd talk about something scary: tracking our
projects. What? That's not scary you say? Information from the field would beg to differ.
Planning not Managing is still so common
In many industries and organizations, it is stunningly common that even when formal project management
schedules are created, they are left in a planning mode only and never tracked. The exercise of plan and if you must,
plan again. Nowhere is this more prevalent than in software development. For all the progress we've made in
project management in the software industry, the numbers of projects that are only planned vs. those which are
planned and then tracked is enormous. If you are one of those who only plans, the good news is, you're not alone.
The bad news is, you're not alone!
There are many reasons why tracking projects in some industries is not popular. In some industries, for example, it
is quite common to have personnel who specialize in creating bids or in project pricing or in project contracting or
in estimating to make the original plan for the project. This is true in many different environments but we see it
almost always in construction, heavy engineering, aerospace/defence and large
engineering/procurement/construction (EPC ) projects. Once the bid is won, a completely new team takes on the
tracking and delivery of the project. On large projects, the people who created the original bid have often moved
on long ago to make other bids as the time between creating the estimate and closing the contract may be
extensive. The project that is just now starting up may be old news to them. So those who do the project
management aren't able to track against the original plan because the people who created it and the structure of
the plan itself are not available.
The most common reason given for not doing project tracking however is that the project is so fluid that tracking
the work is too challenging. Some projects are changed so quickly that just keeping up with the plan is an
enormous undertaking. If you are spending all your time updating the plan, there is precious little time left to track
what you have been planning.
This can have an interesting effect which is not necessarily a good one. In environments where the project manager
updates the plan over and over and over again based on changing conditions, the project is never really late; never
really over budget; never really off track. How could it be? After all, we just updated the plan 20 minutes ago and
we're right on track with where we planned.
If you're in the software development industry and you're thinking, that sounds a little like Agile, you'd be exactly
right. The idea of Agile project management was to build as we design and have the delivery of what we're creating
happen iteratively. Our plans would adjust accordingly and we could, at any time, say "The client reports that it's
good enough. We can stop here for now."
That's completely appropriate for certain kinds of development but for others, it's the stuff of dreams. Most
software development environments live with the same project management constraints as every other industry.
We have deadlines to meet, budgets to respect and a fixed list of scope to deliver. Let's call that traditional project
management. Even in primarily Agile environments, my experience has been that Agile management happens
within an umbrella of traditional project management.
Whatever the incentive to just plan, tracking your project carries the potential for enormous benefits. Let's take a
look at the whole tracking concept.
What does tracking mean?
You might think that project tracking has a very distinct definition and you'd be incorrect. How to track a project
depends vastly on what the objectives are. Here are a couple of more common tracking methods:
Guess at a percentage
"We're about half way there," the team leader says and we know that's about 50 percent of what we'd planned.
While this is tracking and this is much better than not tracking at all, the quality of this data is quite weak. If I had a
plan to complete a task in 10 days and I report that we're about 50 percent complete, project management tools
like Microsoft Project and Project Server will make some assumptions for me. They'll figure that based on the
limited data they have, you must have spent 5 days of effort so far and have 5 days of effort remaining. Perhaps
that's true but it would mask a situation where you are about 50 percent complete but it's taken you 20 days of
effort to get there and therefore probably have 20 days of work remaining.
Measure how much is left
Years ago a dark comedy movie called "The Money Pit" featuring Tom Hanks featured a crew of home contractors
who never seemed to be done. The running gag through throughout the movie was the answer to "When will you
be done?" "Three more weeks" all the contractors would say.
But, tracking remaining duration is a much better quality of data than just guessing at a percentage. Remaining
duration gives us a sharp focus on what is left to get this piece done and when can the next piece that is dependant
on this one get started. There are two ways to think of remaining duration based on how you've set up your tasks.
The first is to think of the total task's remaining duration. This would be appropriate if we are not focused on the
effort required to complete it. The second is to think of the remaining duration or effort required for each
assignment. This would be more appropriate if the tasks are resource driven. But either is a big step up from just
guessing at a percentage.
Measure how much we've spent
"I've spent 10 days so far," is one way to look at progress. Sometimes referred to as LOE or "Level or Effort." Level
of Effort is a great way to look at our actual burn rate but it carries a blind side. On the good side of this method,
we have a great understanding of how much we've spent on this task so far. On the bad side, we might not have a
great understanding of what's left to do. Being in the timesheet business, we deal often with organizations trying to
implement this method. At one time our staff thought of this method as only appropriate if coupled with other
more sophisticated project tracking techniques but we've been shown that it is often very strong just on its own. "If
we could just determine where our time is going," I was told by a client, "that would put us so far ahead of what
we've been doing, we could become almost instantly more effective." He was right too. We did implement a
timesheet which allowed time to be tracked against planned tasks and that alone made the organizations
tremendously more effective. They were later able to add additional methods of tracking to improve their
performance yet further.
We're going to use the earned value method
The earned-value method was developed about 30 years ago as a way of controlling extremely complex projects
but the fundamental concept is quite simple. If we make a budget for a task, then no matter how much time we
spend, we can't earn more than 100% of the budget. Earned value focuses on tracking the "physical" percent
complete and that lends itself well to some types of projects and not so much to others. If we're building a road, for
example, and we have 100 miles of road to build, then when we're at mile-marker 50, we're half done. If you've
spent 75% of the money getting that far, you've got big troubles and the earned value method will make that
obvious. That would indicate that you're probably going to go 50% over budget by the time you're done.
If you're doing research for a new drug or writing software, then measuring the physical percent complete may be
much more elusive. The earned value folks have a whole toolbox of possible ways to get at this kind of progress
and of them all, "weighted milestones" would be my favorite. In a weighted milestone project management
environment, we set up key milestones of the work and as we arrive at that milestone, we earn the percentage we'd
agreed upon before starting that milestone would represent. What's great about this method is there's little debate.
Did you complete the milestone? Yes or No? If not, you've earned nothing. If so, you've earned that percentage.
The Ivory Snow Project
Even if you are using one of these methods, one of the things you should watch out for is what I call the "Ivory
Snow" project. These projects advance almost instantly to 99.97% complete and then stay stuck there for the rest of
time.
How will all these things appear?
Regardless of what project management tool you're using, showing progress is often a fairly common element of
the display. Here we've got an image from Microsoft Project showing one bar with 50% progress:
If that's all we're tracking, we've at least got some notion of where we're headed but modern tools like Project and
Project Server can offer so much more. If we set a baseline on the project, we'll be able to compare not only how
the task is progressing but how it compares against our original plan.
Here we can see that the task was expected to be 50% complete and it is, but it started a week late. On the right
side of the bar, we can see that we've spent 50% of the time and (taking weekends into account) we've filled 50% of
the bar. If we had entered resource work, we might have had 80 hours of work to day and used 40 hours. That's
right on track for this task if we think of it in isolation but even though the task may progress at the pace and burn
rate we expected, it is still having a negative impact on any tasks that are downstream.
Okay, I'm tracking, now what?
Okay, so we've covered some of the basics. You're already in the top 20% of skilled project management managers.
Seriously. This is already better than 80% of those out there. Now for something fundamental but potentially very
impactful.
If x, then y
What I mean by that is that effective tracking needs a consequence formula: If x happens, then take y action.
It's a basic formula but one of the toughest to train people in. Many years ago, I had the privilege of working with a
team of nationally certified lifeguards. These were skilled professionals but one thing could be practiced but never
really experienced until it actually happened: How would the lifeguard react in an actual emergency. Those in the
armed forces will explain a similar challenge. You can train and train and train but you don't really know for sure
how someone will react when there is an actual weapon fired in anger towards them.
Project management is fortunately not usually a matter of life or death but we have a similar problem with those
who track projects. Does the project manager know what they should do when the project isn't tracking exactly as
planned? This is something you can think about long in advance. Do you have a contingency budget of time and/or
money? Do you have a chain of command for them to get authority to take action? Do you have a communications
plan for them to reach the right people when the project is running late or not? And, what results constitute taking
action? Is a one day delay worth escalating? How about one week? How about an increase in risk or scope? Setting
some standards for this in advance can avoid upset later.
Trick or Track
Setting your organization or your project to implement tracking isn't difficult. Virtually ever project management
product in the industry has some ability to store project progress but there is one corporate cultural aspect of
tracking that must still be taken into account to have a good chance of success and that is to not shoot the
messenger. Many project managers who I have spoken to over time express concerns that their management find
only good news to be acceptable when receiving project reports.
A number of years ago I was in a large boardroom of a large multi national firm. We were discussing the impact of
the project management tool receiving information from the timesheet we publish.
"I don't understand," a senior vice president said, "why, when we get the timesheet hours, that the tasks aren't
updating the progress."
"If I had a 40 hour task and I put 40 hours of effort from the timesheet into that task, what would you expect the
result to be?" I asked.
The VP looked at confused at the question.
"I'd expect it to be complete," he said.
"But what if it's not?" I answered.
"I don't understand," said the now upset VP. "If it's a 40 hour task and you did 40 hours of work, then it must be
over."
I wasn't sure what to answer to that but fortunately I was saved by the head of the project group who asked to
speak to the VP outside for a moment and presumably explained that life doesn't always follow the plan.
Getting management to understand that they can make the biggest impact when the project doesn't go as planned
is something that can deliver huge benefits just as much as management's insistence that all project must report
progress as planned can be crippling.
Tracking your project can be a treat not only for those who manage it but also for the entire organization.
About the Author

Beat the Half-life (t 1/2): Governing Your PPM
Solution, Post-Implementation
This article is part of our "From the Trenches" collection. It describes how to set up a framework to setup a
governance model for your Project Portfolio Management (PPM ) solution. It also includes a sample governance
plan that could be used as a starting point to set up your own governance strategy.
To download the Word version of this article, see Beat the Half-life (t ½): Governing Your PPM Solution, Post-
Implementation: white paper.
Beat the Half-life (t ½): Governing Your PPM Solution, Post-

Implementation
Introduction
In Radioactive Physics, Half-life (t½) is the amount of time required for a quantity to fall to half its value as
measured at the beginning of the time period. (Ref: http://en.wikipedia.org/wiki/Half-life).
So, how does that apply to your recently implemented, brand spanking new Project Portfolio Management (PPM )
solution? The reason it applies is because your PPM solution, implemented successfully, comes with an expiration
date. If you do not take the time to plan, design, and execute a governance process around the management of the
PPM solution, you can rest assured that the solution will get filled with stale data, bad design changes, processes
that are out of sync with actual organizational processes, and the list goes on. Just like a car that never receives
maintenance, your solution will stop yielding the ROI that is expected out of it. Your users will become passive, and
either stop using the solution or vociferously advocate a different solution.
The goal of this paper is to discuss a framework to setup a governance model for your PPM solution. A sample
governance plan is also provided that could be used as a starting point to set up your own governance strategy.
The What and the Why
While the word governance could mean different things to different people, at the core, a governance plan is a set
of self-imposed policies and procedures, to make sure the application is healthy in all areas and yielding the best
return of value for the investment made on the tool.
Why is it necessary to have these restrictions, you ask? It is akin to the maintenance of the house you are living in.
Imagine, every time you need something to be fixed or added to your home, a different contractor shows up, and
does the work differently than the previous contractor. Pretty soon you can be sure to end up with mismatching
windows, multi-design door knobs, and so on. That is why it makes sense for builders to have all those codes and
guidelines to follow while building something, standards of components they need to maintain, and so on.
Similarly, once your PPM solution is live, there are going to be several changes, enhancements, and removal of
features that will come up. Unless you set a standard on 'how' these changes are performed, you can rest assured
of a solution that is in complete chaos down the road.
Areas of Governance
When you start considering setting up a governance plan for your PPM solution, you need to consider which areas
you actually want to govern. There are many theories and models for establishing a governance plan for enterprise
solutions, and you are free to choose the best one that fits your organization. In this article, we will discuss one of
these models that will fit most of the PPM implementations.
The simplest way to figure out the areas of governance needed is to consider the areas where changes are likely to
happen, and then set up a governance plan for managing those changes.
NOTE
Even for items that are not 'changes' per se, and rather standard maintenance (Ex: Adding new users, updating Timesheet
Periods etc.,), it is important to have a set of standard procedures recorded.
In general, there are four key areas where changes could happen for your PPM solution.
Information Governance
When your PPM solution is implemented, it is reasonable to assume that you start with good 'master' data in the
solution. For example, these include Enterprise Resource Details, Enterprise Calendars, related custom fields and so
on - essentially all the 'master' data that will enable you to use your PPM solution effectively. However, as you keep
using the solution, people change departments, some leave the organization, calendars need to be updated with
new holidays, time reporting periods need to be created, fiscal periods may need to be changed, and the list goes
on and on. Obviously, if this data is not kept updated, then all your reporting will be inaccurate, and so does your
security configuration.
Information governance is taking responsibility to keep this data updated and complete so that the rest of your
solution can take advantage if this core data.
Design Governance
The second area that needs to be part of your governance plan is the maintenance of "design" of your PPM
deployment. As you continue to use the solution, there are going to be requests to tweak the solution design. These
could arise out of a particular group wanting to change the way they use the tool, or wanting to take advantage of
new features. A classic example is switching the way time reporting is done. You might have chosen to go with a %
Work Complete method, whereas with a new department added, you might need to switch it to the 'hours worked
per period' method for the sake of integration with other financial solutions. So the question is who will evaluate
the impact of this change across your solution, and how are the changes going to be rolled out.
Design governance is the plan to manage changes that impact your overall design of the PPM solution.
Process Governance
It is easy to think of this area of governance as part of the design governance, because most of the time, process
and design go hand in hand. However, holistically speaking, this area covers more than just the design. It addresses
the governance of processes inside and outside of the PPM solution that drive its effectiveness.
For example, take a scenario where your PMO is supposed to submit a report to senior management every
Wednesday AM. You might have setup a process to make sure that the timesheets are submitted every Friday by a
certain time, and all you project managers update and publish their project plans by Monday AM, before the
reporting happens. Now, let's say the senior management asks for reports to be sent Monday AM instead of every
Wednesday AM. This triggers a change in the process as to how the PPM solution is used, rather than a change to
the design of the PPM solution itself.
These kinds of changes will need to be governed by a standard set of rules, defined as part of process governance.
Infrastructure Governance
This is another one those areas that appears to be easy to silo, however can overlap the other three areas
mentioned above. Simply put, the infrastructure that supports your PPM solution should be maintained with the
installation. Some examples of the key items that should fall under this kind of governance model are:
Installation of service packs or cumulative updates.
Installation of new add-ons, or applications.
Upgrade of the infrastructure (addition of application servers, Web servers etc.,) to address performance
concerns.
Changes to the infrastructure due to changes to other applications in the organizations (for example,
virtualization of all servers).
On one side of the equation, the decision to install something or not is purely merit based (for example, whether it
will impact any current production solution adversely). The other side of the equation of any infrastructure is to
look into the 'process' or 'design' changes that will be caused by the installation. In some cases, the infrastructure
change could be the result of any changes in the other areas. As mentioned before, while our attempt is to classify
each change as part of one of these areas, it is possible for some changes to completely overlap all four areas.
Key Questions
No matter which area of governance you are trying to set up, there are three key questions that need to be
answered that will form the core of your governance plan.
How does the PPM team know that a change needs to happen (for example, what is the trigger for these
changes?). Sometimes, these changes are not 'triggered' per se, but are part of regular care and feeding of
you PPM implementation (for example, the addition of new views for the Project Center)
Who approves these changes, not just from a business return-on-investment (ROI) standpoint, but from a
governance standpoint?
Who actually makes these changes? For many of these changes, multiple teams are involved. In some
organizations some of the change capabilities are transferred to a subset of end users, based on business
needs. In these kinds of scenarios it becomes even more important to define who actually will make what
changes.
Governance Team
A key component of any governance strategy is the team that actually works the governance plan. While there are
several ways to slice and dice as to what this governance team should look like, the one recommendation that all
schools of thought will agree on is to keep it simple.
The following is one way to set up the team structure:
Governance Area Owners These are the owners of each of the governance areas mentioned previously in this
article. In general, any change requests that will impact the designated area for these governance owners will
become the responsibility of these owners. It will be their role to evaluate, provide recommendations, set up
governance around the new features, and so on.
Central Governance Committee (CGC ) This would be the team of decision makers who can approve or reject
the recommendations made by the governance owners. Having a central governance committee not only helps
reduce bureaucracy, but also helps bring all ideas to a common platform, and evaluate them in cognizance of one
another.
As mentioned above, depending on the size of the implementation and the current processes that exist in an
organization for other applications, the definition and structure of these roles could be smaller or bigger. The
important point is that to have at least a minimum structure in place.
Other Key Components
Some of the other key components for a successful governance strategy include, but are not limited to:
A Work Request solution, which allows users to request changes, features and functionality. This can be as
simple as a SharePoint list or a currently used in-house work request solution.
A process for handling changes, which includes reviews from IT, governance, CGC, and other business
functions involved.
A process for actually implementing changes. This could be a simple progression of changes from
Development to Test to Production Solutions or a full-fledged Release Management per your organization
standards.
The Process
Let's take all the components discussed above as part of building a governance strategy, and build a process
around it. Here it how it might look (could vary based on organizational requirements).
Conclusion
While it is difficult to predict and plan for every change that can occur to your PPM solution, it is important to have
a strategy in pace that is flexible and scalable to any scenario.
As parting thoughts, please consider the following basic common-sense approaches to building your governance
strategy.
A governance plan does not need to be a tome with a lot of obscure terminology, and language that no one
can use in daily life. It can be as simple as an Excel sheet, with quick answers to the key questions (addressed
in Key Questions).
Remember that a governance plan is not a documentation of your configuration. It is a "plan" for protecting,
maintaining and changing (if necessary) your configuration.
A governance plan needs to be easy to be implemented, and should integrate well into the existing
processes of the organization. It is not necessary to reinvent the wheel.
Understand that governance of your PPM solution is a constantly evolving process. It is important to not get
hung up with paralysis of analysis. Start small, deliver value and then scale it up.
About the Author
Prasanna Adavi (PMP, MCTS, MCITP, MCT) is a Senior Enterprise Project Management (EPM ) Consultant and
Trainer specializing in the Microsoft Project, Microsoft Project Server, and Microsoft SharePoint platforms. His
main focus is to build and enable business solutions to help organizations achieve the best return on their
investments.
He also has extensive experience in leading projects end-to-end in a wide spectrum of domains and verticals,
including IT, ERP (SAP ), Manufacturing, Application Development, Automotive and Creative Services. He is a
regular presenter at various Project Server, EPM and SharePoint events across the country, and a regular
contributor to the SharePoint and EPM Community.
Prasanna is a regular blogger (http://www.prasannaadavi.com) and also runs a bi-weekly podcast
(http://www.msprojectpodcast.com), mainly focusing on Microsoft Project and Project Server solutions. Prasanna is
a Senior Consultant with EPMA (http://www.epmainc.com).
This article is part of our "From the Trenches" collection. It describes some common challenges you may face when
scheduling projects. It describes coming up with the best approach when you try to determine how long tasks
should be and how many tasks there should be to optimize a project schedule. It discusses how different industries
typically require different types of schedules (for example, software development, EPM (engineering, procurement,
and construction), and plant shutdown). It also discusses several factors in choosing project resolution (for example,
length of project, resources involved, management or division of resources, speed and effort required in collecting
data, and data update schedule).
To download the Word version of this article, see They say they want a resolution: white paper (Project Server
2010).

With apologies to the Beatles for the title, today's topic is the resolution of your project.
There are lots of materials available on how to make a schedule, but one of the most critical lessons is awfully hard
to come by—how many tasks you should have in your project schedule and how long each task should be?
On a regular basis I'm confronted with project schedules that seem impossibly complex or with project managers
who seem helpless to pinpoint trouble in their schedule because the schedule is at such a summary level. I've seen
a project that was over a hundred years long (yes, really) that was perfectly appropriate in length and in which
there were some tasks that were decades long. I've also seen project schedules that lasted only an hour or less that
were perfectly appropriate and in which some tasks lasted only a single minute. I've seen projects with only a
handful of tasks and others with over 100,000 tasks.
The software we use today can handle thousands of tasks and a wide range of durations.
So, what's the right approach?
How long should tasks be, and how many should we have to optimize our project schedule? I will call this the
resolution of the project.
Different strokes for different folks
Because the requirement might be different for different industries, different kinds of projects, and different
situations, let's look at how to decide how many tasks to put in your schedule and how long tasks should be.
Different kinds of projects naturally call for different kinds of schedules. Let's think about three different examples:
1. Software development. Many software projects have common characteristics. While every software
project is unique, there is typically a design phase, a programming phase, a quality assurance phase, a
document phase, and a deployment phase. Software projects are typically measured in weeks or months,
and that lends itself to tasks that are a day to a couple of weeks long. Resource allocation here is often
assigned to the individual level.
Those who have embraced the Agile process for developing software look to short "sprints" of one or two
weeks and within that sprint put tasks that are of brief duration, but the overall project duration is still
measured in weeks. We'll talk more about Agile development a bit later.
2. EPC - Engineering, Procurement, and Construction. EPC projects are where the Critical Path
Scheduling methodology got its start. In this kind of project, something very big is being developed. It could
be a large defense project like the Polaris Missile project that gave PERT diagrams their start, or it could be
an offshore oil rig, a new ship, or a power plant. In these kinds of projects there is an engineering phase
where the finished project is conceived. The Engineering phase typically has some aspect that has never
been designed before. The Procurement phase looks at locating, contracting for and managing the delivery
of supplies or sub-contracts for elements of the project. In the Construction phase, the final product is
constructed and then commissioned for use. We typically think of EPC project schedules in many months or
several years with activity durations lasting anywhere from a couple of weeks to a couple of months. It's not
at all unusual to have 5,000 to 20,000 tasks on such a project. Resource scheduling here is almost always
assigned to the skill level rather than the individual, and (just to add to the fun) there may be many sub-
projects made into a program or master project for ease of management.
3. Plant shutdown. When you do a project schedule for a plant shutdown and turnaround for maintenance
you are working in one of the most challenging scheduling environments possible. A plant shutdown to do
maintenance comes in two flavors: planned and emergency. Let's leave the emergency type aside for a
moment; it's a world unto itself. The duration of a planned plant shutdown is heavily dependent on the type
of plant. A nuclear power plant unit, for example, might do a "fast" plant shutdown and turnaround in 12
months. An oil refinery might last 4-6 weeks. But the type of plant project schedule that I find most
interesting is a manufacturing mill like a steel mill, a paper mill, or something similar. There are thousands or
tens of thousands of such plants around the world, and they must undergo regular maintenance every year
or so.
The cost of the shutdown for these situations is usually measured in opportunity cost; the cost of the
product that will not be produced while the plant is idle and undergoing maintenance. This cost is measured
in hours, and the cost can be upwards of $150,000 to $250,000 per hour! So the pressure is on minute-by-
minute to get the job done. In this kind of situation, the shutdown typically lasts 5-8 days and the delay of a
single day is calculated in the millions. If you are only used to longer, more traditional schedules, you might
think that in a few short days, "how many tasks could there typically be?" but it's not at all unusual for such a
shutdown to have 2,000 to 4,000 tasks, each lasting from 15 minutes to a couple of hours. Resource
assignments here are done by skill but resource leveling is rarely done on personnel. With the cost per hour
being so intense, it does not matter if you put more people on the project, just get it done in a hurry.
Resource leveling in this situation is often done for highly constrained bottlenecks. For example, "we can
only fit two people in the electrical room, so that's got to be managed discretely".
Ok, we now have three kinds of examples, and there are many more, but these three will serve the purposes of the
discussion just fine. In type one (Software development), we get tasks that are typically a day or two days to two
weeks long. In type two (EPC ), we get tasks that are weeks or months long. In type three (Plant shutdown), we get
tasks that are measured in units of 6 minutes (1/10th of an hour), 10 minutes, 15 minutes (1/4 of an hour), up to a
couple of hours long. It's obvious that in some cases, short tasks make sense and in others long tasks are more
appropriate. Following the same logic, sometimes it makes sense to have a huge number of tasks and sometimes it
just doesn't.
Factors in choosing your project resolution
With these three distinctions, it's easy to see that the two-month EPC project task would look ridiculous in a six-day
shutdown schedule and that a 15-minute task would be out of place in the EPC or Software project. But aside from
referring back to this article and saying, "Vandersluis says it's a software project so tasks can only be 1-10 days
long," (and please, don't do that) what characteristics of the project tell us what level of resolution to choose? Let's
take a look at a few obvious ones:
How long is the project?
Let's start with the most obvious. If your project is expected to be a few days long, such as in our Shutdown
example, then having tasks that are several days long makes no sense at all. Starting with a top-down approach is
often productive when we think about sub-dividing the scope. Use work-breakdown structure thinking. Start with
the major components. Think about having no less than 4 and no more than 20 items.
Is it a rule? No, of course not.
It's common sense. Less than 4 makes you wonder why you divided the work up at all and more than 20 is too
hard to hold in one's mind at one time. Personally I go with no more than 8 items per WBS element and that's
because of some article I read years ago that suggested that an octagon was the most complex simple shape the
mind could immediately recognize.
Think about that for a moment. You can identify a circle, a triangle, a square, a pentagon, a hexagon which has 6
sides, a heptagon which has 7 sides (ok, that one is hard to visualize) and an octagon.
Can you identify a 9-sided shape without counting? I can't. It's called a "nonagon" for you trivia buffs.
So, personally, I strive for the 8-item limit but my rule of thumb is 4-20.
For each element that you looked at, think about how you should divide up the work. Again, think of the 4-20 rule.
But knowing when to stop is the secret. Newer project managers will sub-divide and sub-divide and sub-divide
until every step down the corridor is a managed task. Some good watershed questions you can ask yourself about
the length of a task could be:
What action would I take if this task was late? If the answer is 'nothing' then it's a good indication that
the task you're thinking of is too small to be worth managing. If that's the case you are looking in too much
detail. Back up a level, take a step back, and see if you are done.
Will collecting the data on the update of this task take longer than the task itself? We do not always
think of what kind of effort it will take to manage a scheduled task, but it's worthwhile to think about even if
for a moment. If it's going to take more effort to manage the task than it will take to complete, then that is a
good indication that the task is being defined at too fine a level of detail.
How long is this task? When we are sub-dividing work, sometimes we lose sight of how minuscule a task
becomes. The big phases at the top level were perhaps weeks long, but as we get down a couple of levels of
granularity, we can easily fall into the trap of defining a task to be managed that is only a few minutes long.
When we get to tiny tasks, we have to ask what the benefit would be of managing them.
Let's apply a reality check to what I've just talked about. In a two-year EPC project, if a one-week task is a day late,
it's almost certainly not worth taking action over. In a six-month Software project, a one-week task that is a day late
is probably not worth taking action over. In a six-day Shutdown project, a one-week task that is a day late is a
massive emergency. In other words, a one-week task in the EPC project may be too fine a level of detail; in the
software project, it's probably just about right; and in the Shutdown project, it almost certainly needs to be broken
down into more detail.
How many resources are involved?
I know we are just working on the scope, but when we look at what kind of resolution we require, it's worthwhile to
think about how many people will be working on a task. In a large EPC project, for example, we may have dozens
of workers from one skill involved in a phase of work. But when we end up with many different skills in the same
task, managing that task becomes very challenging, if not impossible. So, in that situation, tasks that require many
different skills probably have to be divided up.
In a software project, we tend to think of almost every individual as a highly technical resource with unique
capabilities. Plus, in software projects it is common to have many tasks that are re-assignable within a department
but only one task assigned to one person. So when we have tasks that are allocated to a one-person level of a
particular resource group or department (for example interface programming) we are close enough to say that we
do not need more detail.
How are resources managed or sub-divided?
How resources are managed is a big determinant in how to sub-divide your tasks. In large EPC projects, for
example, projects are often cut up into sub-projects that are parceled out to huge sub-contractors. In this situation
we need to do a couple of things:
Define the work in a way that lets a project manager oversee the sub-contractor with confidence that
progress being made is a big factor.
Define the tasks in a way that the sub-contractor's project management and engineering staff will
understand what they mean with no ambiguity.
Ensure that the level of resolution that you have adopted as your standard is understood and agreed to by
the sub-contractor.
When we look at white-collar projects such as software, biological research, or engineering, we are most likely to
encounter a Matrix Management structure where project managers own none of the resources and we must work
across department managers who allocate those resources across many different projects. In this case, the key
questions would be:
How many projects is a resource likely to work on across a single day?
How long does it take an employee to switch from one project to another?
Is the work defined such that both the employees and the resource department managers understand how
to allocate the right skill to it?
When we look at a Shutdown or Construction project, we tend to work across crews that are purpose-built. In
these situations, a Resource Team Leader might be managing the Electrical Team (even if that team includes
carpenters and pipe-fitters), a Plumbing Team, or a Boiler Unit Refurbishing Team. The work has to be organized in
such a way that the crew can be kept busy throughout the shift and that they won't arrive on top of another crew
already working in something in that area. Given the intense pressure of getting a Shutdown project complete, the
work is often organized by work first, scheduled, and then regrouped and sub-divided by a Resource Team Leader
so each team leader can walk around with only their tasks in one document and with the entire project in context in
another. So tasks have to be defined in a way that is understandable by the employee and by the Resource Team
Leader. Tasks here are probably defined down to the hour or with even more granularity to the tenth or quarter of
an hour.
How quickly can you gather data and how much effort does that take?
It sounds like a silly question when you're used to seeing your project data all nicely lined up at the end of the week
to be reviewed, but when you are trying to determine the level of resolution of your project, this can be a key
question. For example, when you are working through numerous sub-contractors, it is likely that you will get some
kind of weekly or monthly update. In fact, building the project management update clause into your contract is
essential. In this situation you have to integrate the data from these different companies into your own, validate
that the progress data makes sense, and then do your own analysis and reporting. In an EPC mode, this is probably
a monthly occurrence.
In a shutdown project, you will need to be updating your project every shift, update it quickly, and get the updates
to the Resource Team Leaders in the middle of the next shift. In this situation, project personnel swarm all over the
plant all during the shift, gathering data in as close to real time as they can and having Resource Team Leaders and
Foremen use 'take-down' sheets to 'take-down' the progress of their assignments. In a software or research project,
you are probably working on a weekly schedule or something like it with individuals reporting their own progress
and going through approvals over a day or two.
This is an important point to consider when you are looking at how many tasks to have in your project, because
there is a cost to gathering the data.
So thinking about how quickly you can collect, approve, integrate, analyze, and report the data on a regular cyclical
basis is key, as is the consideration of the cost of collecting the data and the return on investment of that data being
collected.
How often will we update?
Here are two keys to determine how much data you can collect and include:
Think about how you will collect your data.
Think about how often you can reasonably update your project and provide management with the decision-
making tools required to guide the project and the resources in the right direction.
I've seen some project managers insist that they want to move to 'real-time' project management and project
collection and while this may be possible in theory, it is terribly difficult to realize in practice.
When we look at project management data we make some assumptions. We assume that:
The data is all there. We do not expect to be looking at some tasks that are updated and other that are not.
The data was all updated at a similar time. We do not expect that half the tasks were updated a few
minutes ago but the other half have not been updated for two weeks.
The data has all had some level of approval. We expect the project manager to stand behind the data
being presented and that he or she is able to say "This is a fair and accurate representation of the project."
The data belongs together. We do not expect risk to be blurred with costs and with resources unless we
have specifically designed our reports and analysis that way.
I often ask executives who are excited about the concept of real-time project management what they will do if we
could overcome the points I just raised above. "Are you prepared to take management decisions all throughout the
week?" I'll ask. The response should depend on the level of resolution. In a shutdown project the answer had better
be 'Yes'. In a software project, the answer is probably 'No, we'll do that weekly'. And in an EPC project the answer
would be, 'Monthly'.
At some point the law of diminishing returns kick in to say, "Delivering project reports any quicker will not give us
any increase in efficiency."
Reviewing your work
You have now had some food for thought, you have used the Work Breakdown Method to sub-divide your data,
and you have watched for some of the warning signs that the data is too finely defined. Now it is time to lean the
schedule up against the wall, step back, and look at the project with some perspective. Amazingly, many project
managers never do this. They get so caught up in getting the last details defined and are so busy sub-dividing tasks
again and again that they push themselves right up to the go-live deadline and never look up to see whether what
they have made will be a nightmare to manage.
In some cases, executives are sure from all that MBA training that "more detail is better" and they are pushing for
those 5-minute or 15-minute tasks on six-month-long projects.
Changing the project before it starts is always easier than at any time later, so build time into your schedule-
building activity to rework the schedule if required.
Is it too much?
Sometimes project managers look at the scope of what they have created and realize that they are at too fine a
level of detail. If that is the case, the fix is obvious. It may be a lot of work, but you will thank yourself later to make
the schedule simpler by moving up a level.
Sometimes the picture is not so easy. In some cases, it is only once the entire schedule is assembled that the project
manager can see how complex it is. Complex projects are, by their very nature, riskier, and risk in today's economy
is a key selection factor for projects. Some questions that are worth considering before such a complex project gets
underway might be:
Can we do it in pieces? Some risky projects can be broken up into smaller bite-sized portions and as
smaller projects, their risk goes down. However, if you are using this strategy, each discrete project should
have its own value when it is complete.
Should we rethink the scope? Sometimes the simplest actions are to go back to the designers of the work
in the first place, explain the complexity that seems apparent in the schedule, and see whether the work can
be restated. This often leads to innovative thinking that would have never had a chance to occur.
Should we do it at all?
Some projects were never meant to be, and the cheapest time to cancel them is the day before they start. If the risk
of the project is only now apparent, better to realize it now than later. When you weave the findings of doing your
schedule back into the Project Portfolio Management (PPM ) process, you might find that the risk of the more
complex project has the work score much worse in a return-on-investment scale.
A nimble… no, an Agile project
I promised to say a few things about Agile project management and if you are an Agile fan and you have read this
far, I appreciate your patience. Managing software projects through the Agile method is something of a philosophy,
but it is a more and more popular philosophy with those who have been burned on massive software development
projects that failed.
In an Agile software development world, we try to break our project into bite-sized, one-to-three week "sprints"
and the goal for each mini-project is to end up with useable code. In this case we are working within some fairly
well-known constraints so that our level of resolution is pretty much picked for us.
We have a one- to three-week window, the resources are available to us, and we are going to assign work to each
resource. The number of possible tasks that we can define in that structure is finite and this lends itself to keeping
an appropriate level of resolution. Yes, you can get into trouble in Agile by defining tasks that are much too short.
"Define Field1: 10 minutes, Define Field2: 10 minutes, Define Field3: 10 minutes" etc. but it's much less common.
Agile was designed for a corporate development environment where we are creating software for in-house use,
and its use is often extended to commercial software development. (We use the method here at HMS for our own
development of TimeControl.) The Agile method results in a more maneuverable and nimble development
department but it is not going to be applicable to every industry or even every software company. If you are doing
project management in a software environment then my recommendation is to read up on Agile, learn from it, and
then adopt those elements (all, some, or none) that will make you most effective.
Wrapping up
As with most aspects of project management, there's no set answer to questions that at first seem to be so obvious.
How many tasks you have in your project and how long each of those tasks should be is something that you need
to look for yourself to decide … but decide you must.
Choosing your project level of resolution is a project management responsibility that can be a key success factor in
the management of the project schedule.
About the Author

Breaking Bad...News that is
This article is part of our "From the Trenches" collection. It describes how project managers can share bad news
about their projects most effectively and with the least damage to themselves.
To download the Word version of this article, see Breaking Bad...News that is: white paper.
Breaking Bad… News that is

Following an article ( Cancelling a project without cancelling your career: white paper ) I did a while back, I received
a number of comments from project managers expressing their concern at sharing such bad news with their
management. "No matter what the potential benefits might be," one said, "I'll be fired if I share news that bad."
No matter what your work environment, it seems that some people are better at sharing bad news than others and
for project managers, being able to share both good tidings and bad is part of the job description. So let's look for a
moment at how a project manager can share bad news most effectively and with the least damage to themselves.
Get all the news before you start sharing
The first and most important lesson is to make sure you have all the news. Whenever I have a staff member who
approaches me with some upsetting news I inevitably have questions. If they haven't taken the time to even
consider what questions I might ask and what the answers are, it is irritating. So, before rushing to your manager
to exclaim how the sky is falling, make sure you pause for a moment to get all the facts. Are you sure the
information you have is complete? Is it accurate? Are there extenuating circumstances? Do you know how this bad
news came to occur? Is this a temporary condition or something more permanent? Do you have an assessment of
the impact of this news?
Whew! We're not out of the gate yet and already you have a list of things to do. There's nothing more upsetting to
a person in management than to have a problem dumped on their desk by someone on their team but not yet
know whether it's a problem or not. It should be easy to determine the initial questions that may arise from
whatever your bad news is so get them answered for yourself before you start sharing your news.
Ostrich thinking isn't productive
Like an ostrich which pokes its head into the sand at the first sign of danger in the hope it'll go away, some project
managers avoid bad news at all costs. Avoiding bad news is rarely productive. Indeed, it is because not all news is
good that project managers have a job in the first place. If all projects always worked just the way they were
planned, why would we have project managers? So just because you're not ready to share that bad news yet
doesn't mean you won't be sharing it at all.
Who's to blame?
This may be the least valuable question and the answer is almost certainly of little value also. Yet, many people will
default to point a finger at someone else as a reaction to the upset that the bad news is about to cause. Staying
away from blame will allow you to focus on "What happened?" and "What should we do next?" as opposed to
"Who do I lay the fallout of this problem at the feet of?"
Is it bad news? Are you sure?
I recently had one of my staff appear in my office letting me know that due to resource constraints we would be
unable to meet a client's expectations that we do several days of training after hours. "Did we commit to do this?" I
asked. There was a long pause. The staff member wasn't sure and it turned out to be a key question. No. We had
never promised to do this training. The client had a desire that we would but had not even gone through the proper
channels to schedule it. It turned out there really wasn't bad news to share and the appropriate action was to
contact the client to schedule some training time at a future date.
Problem solved.
A problem typically gets expressed like this: "This was expected but this is what happened". Sometimes just the
semantics can make you think about it differently. Try this: "This was expected and this is what happened." Conflict?
Perhaps not, but it's healthy to start with seeing if there was as commitment that was broken. If not, perhaps there
isn't a problem to deal with.
Silver linings
When something unexpected happens there is often impact or fallout as a result. If you are pausing or cancelling a
project for example, one thing that almost always happens is you have extra resources that were not expected that
can be assigned to other work. Pausing a project may have the result of refocusing more effort on other more
critical work.
When you have bad news to share, it's common to see everything around you through the filter of "It's all bad" but
that is rarely true. Some impact from your bad news will be good and you owe it to your management or your
client or whoever you need to share your news with to share not just the bad impact but also the good.
Mitigation
So you have some bad news. One thing that's worth doing before you share it are some mitigation factors. Perhaps
your project is behind schedule. That's bad news. But, if you had already hidden some management reserve in your
schedule (as many good project managers do) then perhaps you can catch up on your schedule during that period.
The bad news is mitigated; neutralized.
Mitigation also lets you think of potential solutions to the problem before you share it. Managers greatly appreciate
problem descriptions being delivered at the same time as a list of possible solutions. Sometimes those solutions
become opportunities to open up a whole new line of thinking. A number of years ago, I was working with a large
software company and in the middle of the development of their next major release, they determined that they
would need to cut a marquis function from the scope. It was bad news. If no further action was taken, they would
release their next version and already be much less functional than many of their competitors. They company
selected one of several mitigation plans and went to the market and bought a company who had exactly the
functionality they were missing. The end result? The company made the market delivery date, had the appropriate
functionality and, moreover because of the acquisition, had a team of highly skilled staff who allowed them to
leverage that functionality to leap ahead in the marketplace.
Problem solved.
Presentation is Power
As project managers we often lament that we have all the responsibility and none of the authority. After all, it is
rare that a project manager has all the project resources reporting directly to them, yet it is the project manager to
whom we turn to ask about progress in the project.
While the project manager may have little authority, they do control one thing that is even more impactful; they
control the presentation of information and controlling the presentation is key.
Is it any wonder we call it "Power"Point? How you display something can make all the difference. A number of
years ago, filmmakers Stephen Spielberg and George Lucas bought an old flight simulator and were amazed to
determine that the human body can detect a change in pitch (the angle on which you're standing) of less than ½ of
one degree. When augmented by visual cues, the mind will fill in the gaps and the body will react as though an
event is actually happening even though it's just a tilting floor and a movie with some sound.
Pilots in training who are using a flight simulator will have the same body reactions (heart rate, breathing,
adrenaline etc.) in a simulator emergency as they will in an actual emergency.
The result of Spielberg and Lucas's investigation? The Star Tours ride at Disney World.
By the same token, a project manager controls the visual display. Show a trend line instead of a table of figures and
the eye follows the trend all on its own and the mind draws its own conclusions.
Project Managers typically control all the elements of how data is displayed. Showing dashboard data or analytical
data or data in a graphical format along with simple bullets on a slide can make an enormous difference.
In one recent engagement I had to explain to the client that their current workload was almost two times the size of
their workforce and that no amount of prioritizing would result in all the work being done on time. Before
presenting this bad news however, I spent some additional time digging into the data of what work was actually
being done. I pulled volumes of timesheet data into Excel and started charting it. Finally a pie chart showed a major
nugget of gold. An incredibly high percentage of work was being expended in IT maintenance. Further digging
determined that much of this work was either avoidable through strategic decisions (for example, supporting an
unusually high number of database products and versions) or through restricting a practice of allowing projects to
be sub-divided into such small mandates that they could be handled operationally through a technical support
request. The organization had been so challenged in getting work accomplished that many business team leaders
had learned to sub-divide projects of 30, 40 or even 60 days in duration into 3 day segments which they would get
accomplished through a call to the help desk. This was so prevalent that there was as much unauthorized project
work being done this was as there was through the actual project management office. Stopping this practice gave
the PMO renewed insight into project requests and the volume of requests dropped significantly.
The data had always been there. The practice was known to many but until we showed the slice of the pie chart in a
graphic, no one was aware of how impactful the practice had become. Indeed, the management were shocked at
the numbers.
Perspective counts
It's important to not let the urgency of the moment or the concern over how sharing your bad news cloud your
perspective. It's easy to get caught up in the upset of the moment but if you don't, if you keep your cool, you can
become the voice of reason in an otherwise upsetting day. I have used the following two charts for years to
demonstrate the difference in perspective of the Chief Financial Officer vs. the Project Manager and the potentially
dramatic impact of not widening your view of information.
Here's the CFO view:
And here's the project manager's view:
The first chart is of a project which has overspent its expected budget to date. The planned budget was agreed
upon by all parties and as of today, the Chief Financial Officer is having a very bad day. The project is clearly way
over its expected budget as of today. He would like to take action immediately and is demanding a project review, a
halt of the project, cutting of staff and other drastic measures to try to bring this runaway train back under controls
If we extend the perspective just a little and include the project manager's projections, the picture changes
dramatically. Yes, the amount spent on the project as of today is higher than was originally project as of today.
That's unexpected and at first glance looks like bad news. However, if we include the forward looking forecast, we
can see that the project is actually expected to finish on time or earlier and that the project will finish under budget.
Taking action to "rescue" this project would be the worst possible course.
Problem solved.
It is critical to look at whatever you think might be bad news from more than one perspective before taking dire
action. We're just looking at one project and just from a cost-per-time view and already it is clear that just a historic
perspective does not give a complete picture. What about other perspectives like schedule, resource usage, quality,
market impact and more? Perhaps finishing over budget but earlier would be so impactful from a market
perspective that it would more than make up for the unplanned extra expense. That's impossible to discover if you
don't pause to consider the news you're about to deliver from more than one perspective.
Wrapping up (Is that the end of the bad news?)
Bad news is part of life and it is certainly part of a project manager's life. If you were hoping as a project manager
for only happy news, you'll need to think again. As a project manager you must be able to confront bad news and
be able to communicate in a way to provide the most value and avoid the worst damage possible.
A project manager is typically the center of a large web of information about the project and the organization. They
are almost always in the best position to share unwelcome news in a way that avoids drama and leaves people in
action. A project manager who can communicate this type of news effectively is an asset to any organization.
About the Author

The executive connection
This article is part of our "From the Trenches" collection. It describes the importance of having executive
involvement for a successful Enterprise Project Management (EPM ) deployment. It describes reasons why a
company might choose to not involve an executive in the deployment, how executives should be involved in the
deployment, and tips on how to effectively involve an executive in the deployment.
To download the Word version of this article, see The Executive Connection.
The Executive Connection

Over the years the most successful EPM deployments I've been involved with have always had a strong executive
connection. In comparison, those deployments which have been the most difficult have been those where our
connection to senior management was kept at arm's length. It's made me do some thinking about what causes
executives to be more or less involved and what recommendations I can make to organizations at the very earliest
stages of an EPM deployment with regard to what kind of executive involvement should be required.
No executives? How is that possible?
Let's talk first about how it could possibly come to pass that executives wouldn't be intimately involved in an EPM
deployment. After all, EPM stands for Enterprise Project Management. Shouldn't there be someone who is
representing the enterprise in the project? You would think so. But, in many organizations there are numerous
reasons why executives would not be involved.
Lack of executive knowledge of EPM
The first and most likely reason is a lack of understanding of what project management is all about. Old-school
executives sometimes have little project experience and what experience they do have leads them to think of
project management as a very tactical, in-the-field type of exercise and not at all a strategic exercise. When the
need for enterprise project management arises they are often surprised that recommended initiatives require a lot
of time, a lot of effort, and a lot of money and certainly don't think their personal involvement should be required.
Project Management infrastructure projects are often thought of as overhead and, while upper management often
has a great desire for the results of such systems and processes, they are rarely keen to invest in them. This isn't
helped by how the project management industry must "sell" such projects internally. In a Quality Assurance (QA)
manufacturing example, it's common to recite hard savings dollars for what can be achieved by improving quality
by a couple of percentage points. Project Management doesn't have this luxury. Project Management savings are
always a cost-avoidance savings and much harder to prove directly. As a consequence, project management
projects take a lot more internal effort to sell than some others.
EPM - that's a technology project
Another common pitfall is to think of an EPM project as primary a technology project. "If we buy this software,
we'll have enterprise project management." As I've said in my column before and as has been echoed by virtually
everyone in the project management industry, this simply isn't true. Enterprise project management products like
Microsoft Project Server and the associated products that make up the Microsoft EPM solution are a platform from
which the automation of enterprise project management can occur. They can be thought of as the tools or the
medium through which EPM benefits will arrive, but they are not, in and of themselves, the solution. A successful
enterprise project management solution must be crafted with processes, the skills of the personnel, practices and
procedures, standards and, often, with technology that is designed to empower those processes, people, and
procedures to make it more efficient. However, there are many project management software vendors on the
market and their message talks about the benefits clients have achieved while using the EPM tools purchased, so
perhaps it's not surprising that some executives believe that the tool is the solution.
Certainly I'm committed (for about 10 minutes )
Some executives do sign on as an executive sponsor for EPM projects and are generally upset when someone like
me arrives to announce that the project will require their commitment for 6 to 24 months. "How could this not take
more than a few days of training?" they ask. This often comes as a result of a complete misunderstanding of the
fundamental nature of an EPM project. Once they understand that the deployment of a working EPM environment
will include changes in process, in day-to-day procedures, in the way resources are allocated and even in how
projects are selected, it's not uncommon to have senior management take a step back to regroup. Several times
I've been called into a company a year or more after meeting them for the first time to find that the company has a
newfound respect for what they need to do and have now marshalled their forces around doing an EPM
deployment completely and properly.
We didn't tell the executives
This is all too common. I get numerous calls every year from personnel within an organization who are working in
a project management capacity and who can see an urgent and significant need for enterprise project management
yet who have no executive support for the project. They hope they can work under the radar and quickly create an
enterprise project management environment before anyone notices and then present this new process and system
to management nicely wrapped with a bow. This is the "throw it on the wall and see if it sticks" method and it is
almost never successful.
Those who try to establish an enterprise project management environment without the support of their
management run headlong into all the things that require senior management before they're out of the gate. EPM
after all is often done to improve resource capacity planning, improve portfolio management, improve inter-project
impact and improve intra-project collaboration. Almost none of this can be changed without the intervention of
management. Also, those who are most interested in this kind of approach have significant project management
challenges that they are trying to address. It's inevitable that those project management challenges are centered on
other departments and personnel who have a vested interest in not changing.
In a matrix organization for example, it is common to see conflict between the resource managers and the project
managers. "If only we could be more projectized," becomes the battle cry of the project managers and it is at this
point that someone like myself gets a call asking if we could quickly (on the order of a few days) assist them with
creating an enterprise project management environment. These exercises are sometimes labeled as "Proof of
Concept" projects and the first thing we tend to ask is, "What are you trying to prove?" The best thing to do with
these kinds of projects is to bring management in on the conversation early and expose the causes of project
management not being as effective as possible and to make a plan together on doing an enterprise project
management deployment.
I'd like anyone to be responsible for that (but me)
Some executives can see the depth that an enterprise project management implementation can represent and
consider it a career risk to involve themselves. So, when the project management office or the middle management
who have been tasked with creating an EPM come to the executive suite looking for support, it can be hard to
come by. This is often the result of a lack of understanding of how key executive involvement is in making this kind
of deployment a success.
How should executives be involved?
There's no one right answer to that question. Each organization I've encountered has a different structure, different
personalities and different requirements. What works in one organization sometimes doesn't work at in the next.
So, it's impossible to say "It's the Chief Information Officer who must always be the executive sponsor." and have
that be accurate for every company. Here are a few things about executive involvement in EPM projects that I've
found over the years to be common among most if not all organizations I've encountered.
I speak for those involved
When we define which resources will be involved in the enterprise project management exercise, it's critical to have
executive commitment from someone who has authority over everyone involved. I've got plenty of examples of
this both in successful and unsuccessful attempts.
In an EPM deployment that I was involved in many years ago, we were working with the blessing of a senior
director of a high technology engineering company. It started out with great excitement from both ourselves and
the project management office of the client. We should have been less excited and more insistent on who was
implicated in the whole exercise as we found out about half-way through the deployment that this senior director
while highly committed himself, was only one of five such directors who controlled the personnel who were
implicated in the deployment. When we pointed out that we'd need consensus and support from all five of the
directors, the project ran into trouble quickly. Attempting to petition the VP of Operations turned out to be
unsuccessful as three of the five directors felt they would lose control of their groups if the EPM project were to go
forward and were petitioning the VP at the same time as we were. In the end, we had to settle for a reduced scope
and a much longer period before the company could start enjoying the results of the enterprise project
management environment we'd created together. The client ultimately would be satisfied but we were not. It was a
good lesson in not getting too caught up in your own enthusiasm.
In another project I am still involved in, we were working on the EPM environment in organization's IT department.
I met the CIO during our very first meeting and he understood what would be required of him right away. Within a
few weeks, the very first stages of an EPM environment was established in the IT department he controls. It started
producing some results immediately and the organization has expanded the effort over the last five years to make
the system more and more valuable. Now the organization is moving towards portfolio selection and we are
working with them again at the most senior levels of management. There was concern from the project
management office and even the CIO that there might be resistance from the senior executives to involve
themselves in the process when we scheduled our first meeting, but the concerns were unfounded. It turns out that
the executives were ready to accept the responsibilities that I outlined to them. We consider this client to be a big
success story and they have been references for us for many years.
I understand what is required of me
Trying to tone down or minimize the effects of an EPM deployment is ultimately not productive. I've seen many
people try to minimize the implications of an EPM deployment to management to get at least some support. This
is often because the people who are trying to garner support from the executive suite are concerned that the
project will appear too complex, too expensive or too risky to get any support at all. The theory is to get some
support to do something, no matter how minimal and then hope that the environment can be expanded over time.
I've always found that working with the executives to show them exactly what is required of them and, if necessary,
educate them on what will be affected is much more productive. After all, executives typically don't get to be
executives if they're stupid. For all the concern I've heard over the years over how when I meet some executive or
another they may not understand what I'm trying to say, it's never happened. The executives I tend to meet are
interested, highly intelligent and ready to take action. What they are not is endowed with unlimited time. So, I make
sure to make my point succinctly, ask for what we need and not put demands on the executive that can be handled
elsewhere. However, I also don't pull punches in terms of how long it might take to get return on investment or
how long until the ultimate goals are reached. In my experience, when executives know what's required of them,
they tend to rise to the occasion.
Next Steps
Are you working on an EPM deployment right now? Are you wondering how you might involve your own
executives in deploying enterprise project management? Perhaps you are a senior executive and you are wondering
what you can do to help ensure a successful EPM deployment. Here are a few tips that may be valuable.
Find the right executive
Finding the friendliest executive isn't always where the search should stop. We look for a couple of criteria to
ensure we've got the right executive involvement. First, we look for the person who has authority over the
resources that will be implicated. If the EPM project is for the IT department, that's usually the CIO. If we're talking
to a matrix organization, we may be looking for the Director of Operations or the CEO. A "committee" of executives
is usually a red flag unless there is a clear chain of command over who will make decisions within that group. If the
group is made up of several executives who are all peers we'll ask for someone who manages the group to attend
also. So, sufficient authority is first. Next, this someone has to understand and be committed to the benefits that the
EPM project represents and the effects that may result. If there is no desire to change the way resources are
allocated then a desire to change resource allocation to be more effective is moot. So, getting that onto the table
immediately is important.
It's a change management project
This might be the single most important factor in making an EPM deployment succeed. This is not to say that
technology is not important. But we want management to appreciate that what we are about to do is change
organizational behavior and that some of the factors involved may reach deep into how all kinds of aspects of the
organization will function. When management understands that, we get a huge level of respect for the project and
much better support. After all, if EPM is desirable, it's because there is a need to change how some fundamental
business decisions are made. These decisions might include how resources are hired, or how projects are selected
and almost certainly how projects are prioritized. In an organization that does projects (as any organization
interested in EPM would be), this ultimately affects almost everything.
Use a lifeline — phone a friend
Just like popular contests, sometimes the best thing you can do is reach outside yourself to take advantage of
others who may have a perspective that would be appreciated. We've always found that one of the most productive
things we can do with an executive is to set them up to meet other executives of their stature. Executives typically
really appreciate being able to talk to others like them who have or who are facing similar challenges. There are
restrictions in some cases, of course. You typically can't have senior executives of direct competitors talk and those
in certain industries like defense have some restrictions but in almost all cases you can find other executives who
will take the call from your executive over what worked in an EPM deployment. Not sure where to find such
people? Your local PMI (or similar organization) chapter is a good start. Listen for stories of those who have
completed successful EPM deployments and ask if your VP could talk to their VP. You'll be surprised at how
cooperative most people are. If you're already looking at technology such as Microsoft Project Server, ask your
vendor to set up a call with a successful deployment. They obviously have a vested interest in getting your
executives hooked up with executives who have successfully completed an implementation. If you do this, don't get
too hung up on what version of which tools got implemented. It's the overall process of executive involvement that
needs to get communicated.
It's not just the tools
Try to avoid the pitfall of thinking that just the tools without the process will fix your enterprise project
management challenges. Some executives I meet are enthralled with thinking that the delivery of project
management software constitutes the working solution. To those people I usually ask this:
"If I were to go to the local Do-It-Yourself store and ask for a kitchen," I'll say, "and someone were to bring out a big
box of wood, nails, glue, paint, and tools would they have delivered?" I think not. They might have delivered the
potential for a kitchen but I wouldn't be able to immediately make myself a sandwich. To do that I'll need the wood,
nails, glue, paint and tools but I'll also need some skills, some knowledge, a plan and some time. Now, could I
figure out myself how to make a kitchen? Sure, given time and a lot of patience. But, if I want a kitchen a little
quicker, I might consider working with a contractor to help.
Ultimately, having executive support from an executive with the authority and the commitment to make your
enterprise project management deployment a success is a critical success factor, but you really knew that already.
After all, in any major project in your organization you'd have that executive sponsor as a natural part of how you
manage projects. It's only easy to forget because it's an internal project and in so many cases, we forget to apply
what we know about project management to our own internal projects. In this case, make an exception and get the
right executives onboard as you move forward with your own EPM deployment.
About the Author

Is there a pilot on board?
"If there is a pilot on board, would he or she please ring their call button?" is something no passenger ever wants to
hear. I re-read a remarkable news story from a true incident just like this that happened back in December 2013.
After the pilot of a flight out of Des Moines, Iowa suffered a medical emergency, the co-pilot made a request for
any pilots on board. Capt. Mark Gongol, a B1 bomber pilot in the US Air Force, stepped into the breach. The plane,
passengers, and crew all landed safely.
It's a great story but my going back to re-read it recently was triggered by something very different. A prospective
client of ours called recently and asked if they could "pilot" our enterprise project timesheet software. These kinds
of calls always make me take pause. When someone on an aircraft says "pilot," we're all very clear about what is
meant, but when someone who is evaluating software options says "pilot," I'm not so sure.
The term "pilot," in the software world, is often blended together with other challenging evaluation methods, like
"proof of concept." Let's take a look at what these terms mean and how you can best use them in your own
enterprise evaluation process.
Proof of Concept
This is a term that dates back many years and is popular in electrical engineering. "Bread boarding" a circuit was
done to see if the circuit was possible, not to start creating it for production. In proof of concept, you might spend
more time at a lab bench than you would in creating the production circuit, but the only damage you could do was
to the circuit board you were working on in front of you. It was an inexpensive and low -risk method of proving that
an electrical circuit could deliver a desired result.
In software terms, a proof of concept should be designed to prove something. When prospective clients call to ask
if I can help them deliver a proof of concept for enterprise project management or enterprise timesheet software, I
always have the same response: "What concepts do you want to prove?"
This is typically met with silence and a confused expression.
If you're going to conduct a proof of concept, and you have no notion of what you're trying to prove, how will you
know if it's a success or failure? There's no way at all of course.
Why, you ask, would someone even want to do a proof of concept then? The most common answer is that the
requestor probably doesn't have the necessary buy-in from management to implement the software they're
researching, and hope that if it was just running in front of them they'd fall in love with the idea and agree that it
should be deployed. In this case, the "proof" is to management, and the "concept" is the whole idea of enterprise
software.
If it were that easy to convince management that enterprise project and timesheet software is a great fit for them,
we'd deploy an awful lot more of it.
The problem with this method is that the work you're going to be able to do to deploy this proof of concept
instance is extremely unlikely to have the same support as you would get for the production deployment of an
enterprise system. When an organization deploys an enterprise system, such as a timesheet or project
management system, there are many things that are required to make it a success. First, there will need to be input
from management and line-personnel for any aspect of the organization that is implicated in the deployment. Next,
there will need to be time for configuration, assistance from technical services to link to other enterprise systems,
management sponsorship, time for training, and, yes, money.
If you don't have any of these things, then what will be the system that you can complete in your proof of concept?
It will be a shadow of what you desire at best. In today's in-the-cloud age, you can probably get access to a system
that is fully hosted so that you can at least not worry about buying servers and software, but just having a system
installed is a fraction of the work required to make even a basic deployment of your proof of concept system.
It's easy to understand why an organization will hesitate to devote a lot of money and resources for the
implementation of something that has the potential to impact the whole organization. It's a high-risk exercise. We
tend to talk only about the benefits of enterprise project management software, but it's easy to imagine that the
same project gone-wrong can have an equally negative impact. So, mitigating the risk is an obvious concern. But if
the real challenge is to convince management of the benefits of the system, then surely there are better ways to do
this. At HMS Software, we've focused on a few of the following techniques:
1. Talk to a real, already-existing client.
We're blessed here to have some great clients who are by and large quite satisfied. When a new prospective
client has concerns over what they're getting into, we get that organization together with an existing client.
In many cases, the existing client has been generous enough to offer to host an in-person meeting. In other
cases, they do calls with each other that we deliberately don't become a part of. We encourage the existing
client to share both good news and challenges.
2. Let us prove it.
If you really do have a concept that needs proving, then let us help prove it to you. There are legitimate
reasons why some aspects of some implementations need to be proven first. Perhaps the deployment will
have very large volumes of certain kind of data. We were asked once for example, to show our solution
functioning with a particularly large project load. We've been asked to show software working with certain
browsers or with certain databases, or linking to particular versions of certain external systems. If that's the
kind of concept that is blocking the evaluation, then the best people who can overcome that challenge are
the subject matter experts.
3. You can have some training with that.
In the case where the prospective client absolutely must show the system working with their data used by
their personnel, we help load the data into a hosted system, then do a minimum to configure the system as
desired by the client and to train the people who will be involved. We highly prefer being brought into the
company to help with the demonstration itself, but if that's not possible, we ask to review the script or
demonstration that the people involved will use, and ask to help adjust it or train people to deliver it.
Where's a pilot when you need one?

So what about the pilot project? That's better, right? It could be. If you've been asked to establish a pilot deployment
of an enterprise timesheet or enterprise project management system, you should start by determining the goals. If
the goals are all about proof of concept, then you're not in a pilot program at all.
A pilot project is a real, in-production, live deployment. It typically involves a subset of the total user base that is
being considered for the system being evaluated, and therefore a pilot program is likely to take some time. While
the needs of the complete target user base are considered from the beginning, the pilot program focuses on doing
a real implementation for the pilot users. They will actually be managing their projects or actually filling in their
timesheets with the new system.
The same challenges that a complete production deployment will face are also faced by the pilot implementation,
with the exception of the volume or complexity of data. The most common challenges of Pilot projects I've seen
include a lack of sponsorship, insufficient budget, time and resources and, probably worst of all, a lack of articulate
goals to know how to determine if the pilot project was successful or not.
This isn't to say that a pilot project is bad. Doing a pilot could be very sensible and can serve to mitigate the risk of
impacting the entire organization with an incomplete or poorly configured deployment. But making a pilot project
successful takes some thinking.
Recently, we started working on a significant-sized deployment for a public sector organization. What is gratifying
about the exercise is that the organization has already spent all the time they should have completing their
evaluation. They've made their choice of enterprise system. Happily, it's ours. We've worked with their evaluation
team over the last year to make sure their technical questions were answered, but now the focus turns to the
impact on the day to day process of the people in this organization.
They proposed that we work over a 6 month period with a group that, while sizable, is still only about 10 percent of
the entire group. There's an adequate budget, the pilot has the support of management at the most senior level
and we've got enough time to make sure we can assist with everything we'd normally do on a deployment like this
one. The group who will be put onto this project tracking and timesheet environment will be working with it, in
production, for the foreseeable future, so it's not just a test. This is more like the first phase of deployment, not a
"try it and we'll see how it goes" exercise. With all these factors in place, we have every expectation of a successful
result late this year.
Wrapping up
Pilot and Proof of Concept projects are a fact of life in enterprise software, but if you have one in your future, you
can help make it a success to point out some key success factors to everyone involved:
1. First, make sure you have your goals clearly articulated.
2. Next, make sure that management understands what you need and will support you in terms of money,
resources, and time in order to achieve those goals.
3. Finally, make sure you make a project plan and manage it like any other project in your portfolio.
About the author

which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, PMI's
PMNetwork, and Project Times. He teaches Advanced Project Management at McGill University and often speaks
at project management association functions across North America and around the world. HMS Software is the
publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution
Partner since 1995.
If you would like to read more EPM -related articles by Chris Vandersluis, see his EPM Guidance blog
This article is part of our "From the Trenches" collection. It discusses the evolution of project management systems,
the use of Enterprise Project Management, and the importance of understanding which project management
solution is best for you.
To download the Word version of this article, see Would you like some EPM with that?: white paper.

In my office recently one of our most experienced employees came to me with a strange question.
"How do you know if something is a project management system?"
I opened my mouth to answer then paused … for a long time. The answer is not obvious.
In the early 1980s the first critical path scheduling packages became available for personal computers. In fact, I find
it interesting that history shows that critical-path scheduling software has been one of the first commercial
applications published in each wave of computing starting back with the first commercial mainframes in the 1960s.
My start in the project management software industry dates back to the early 1980s though and we would have
used the terms "project management software" and "critical-path scheduling software" synonymously.
In 1983 if someone had shown me anything but a critical-path scheduling system and asked if it was a project
management system, I'd likely have shaken my head and said no.
Microsoft Project at its core is a critical-path scheduling system and we still use the terms project management
software to describe it. So if someone were to ask me "Is Microsoft Project project management software?" I'd feel
pretty comfortable answering in the affirmative.
But what about accounting software? Several Dynamics products do project budgeting and cost tracking. Is that
project management? I'd have to say that it is.
SharePoint products allow you to manage documents and document workflow and make lists of outstanding
issues. Is that project management software? It sure sounds like it.
Microsoft Dynamics CRM allows you to attach activities and resources to client initiatives. Isn't that project
management? It certainly could be.
How about contract management, timesheet management, workforce scheduling, material consumption and
equipment usage management, and production value tracking? Are any of these project management? Yes. Any of
them could be.
Years ago I worked with a specialist in construction project management whose main tool was something that
managed the pace of work of several trades simultaneously. This single graphical report tracked carpenters and
plumbers and electricians and several other trades. This very experienced project management showed me how
just managing the pace of work from one team to another avoided electrical teams arriving to an area before the
drywall was erected and kept the plumbing team from overrunning the electrical team. This single report for this
particular type of project allowed this project manager to be remarkably effective. Was that a project management
system? You bet it was.
To make matters more complex, we have both project management tools that make individual project managers
effective and other tools which are more appropriate to the organization. Enter "Enterprise Project Management"
software. To be fair, the concept isn't that new. The first project management systems in the 60s and 70s were all
enterprise tools, though access to computer systems in general was much more restricted then for most
organizations.
Like all good things, Enterprise Project Management resolves to a three letter acronym: EPM. If I do an Internet
search for EPM, though, I might find Enterprise Project Management. I might also find Enterprise Performance
Management, Enlisted Personnel Management, Electric Propulsion Motor, Exchange Permission Manager or any of
about 40 more definitions. Make sure you're looking for the right one because a propulsion motor is unlikely to
help you with project scheduling.
If we have difficulty defining a project management system, it's certain that we'll have even more difficulty defining
what makes a project management system an "enterprise" project management system.
In the end, is it that important?
I've been known to say for some time that I always prefer to define the problem before we start looking for the
solution. Our office often gets calls asking for help deploying an "enterprise project management system" and
inevitably I must ask about both what they mean by "enterprise" and what they mean by "project management." It
takes a minute or two for some to get over having to explain themselves. After all I have some background in
project management and they're certain that I must know what these terms mean.
Sometimes I find out that the "enterprise" is in fact a handful of people. There's nothing wrong with that. I run a
small company myself and no size is too small. But not asking might have had me recommending software that
was designed for company of 1,000 people, and while I'm sure it would look lovely, it would be a complete
disconnect between tools and requirements. Plus, the return on investment of such a deployment would likely be
awful because of the difficulty in paying back such a disproportionate investment with efficiencies of a small team.
If you want to give advice on tool selection, not only is it important to get the scale right, it's critical to determine
what the business challenges are.
A number of years ago, I visited a very large power authority where we had built up a good reputation for assisting
with deploying project management software. During this visit, I met with the head of a new department who
wanted to deploy "enterprise project management software". I sat with him and went through his requirements.
"How many projects do you have?" I asked.
"Ten to twelve at a time," he answered.
"And how many tasks would you have in these projects?" I continued.
"Oh, it's always the same. Six tasks," he replied.
"Six," I repeated. "So, we're talking about 60-70 tasks to manage at a time?"
"Yes, that's right. It's very complex," he said.
"I understand," I said. "And how many users will be involved in managing these tasks.
"It would just be me," he answered.
You can see this coming, I'm sure. There was no critical path, no issue management, no document management, no
resource leveling, no risk management and no cost management required. All he needed was a visible guide to
outstanding tasks for himself so he didn't let something drop through the cracks inadvertently. The amount of
money on these projects was actually huge, in the millions of dollars, in fact, but the unique type of project meant
that managing it was relatively simple.
"Why not just put them on a white board here in your cube? I suggested. You could use some permanent marking
tape to make rows for, say 15 projects and then use colored dry markers to update the schedule and it would be
right in front of you. You could use a red marker for example to make a note of important milestones and a green
marker for tasks with a long lead time."
He seemed quite perturbed and upset even that I couldn't recommend a large enterprise piece of software to
manage his projects. He'd heard from others in the company that there were great enterprise project management
packages out there and was sure I'd come to him with a recommendation of deploying one.
The meeting wound up shortly thereafter and I was sure I'd left an unhappy new contact behind. To my surprise he
called my cell phone a half hour later while I was on my way home.
"Thanks so much for the meeting," he started. "I've already ordered a white board from the office supply
department but if you could spare a minute, could you go over with me again which color I should use for which
kind of tasks?"
Fifteen minutes later he had taken copious notes and was a happy camper.
It was a great lesson for me which I've carried to many more engagements. I try to take that extra minute early in
an engagement to determine what is meant by terms that deceptively sound like a universal standard.
Project Management software could be represented by numerous categories. If we just start with the Project
Management Institute's Project Management Knowledge Areas we'd end up with:
Integration Management
Cost Management
Communications Management
Scope Management
Quality Management
Risk Management
Time Management
Human Resources Management
Procurement Management
It's easy to imagine a variety of tools, packages and techniques for managing any of these areas, and, depending on
the particular situation, any one of these categories could produce the most significant improvement in project
management or project management across the enterprise.
Let's say an organization has project communications challenges; perhaps its resources are spread across
numerous time zones and countries and even companies. In that case, it would be easy to see how you could
deploy Lync and SharePoint to make a huge improvement in communications.
If an organization deals with many sub-contractors on its project or if it has a large purchasing component in its
project, then strong procurement management with a Dynamics ERP and SharePoint might make the biggest
difference.
If the organization is complex or of larger size and the project challenge is prioritization and resource capacity
planning, then perhaps Project Server is the fastest path to a return on investment.
Remember that staff person asking about how do you know if a particular package is project management
software? My answer was this: "Is it software? Does it apply to managing projects? Then it's project management
software. Now go back and find out what the client's project management business challenge is."
Articulating your project challenge before deploying your project solution will always yield better results.
About the Author
Are we there yet?
This article is part of our "From the Ttrenches" collection. It describes how enterprise system implementations
need to able to adapt and evolve to be successful.
To download the Word version of this article, see Are we there yet?.
Are we there yet?

Over the years one of the biggest pitfalls I've seen to the selection and deployment of enterprise software is the
thinking of the implementation as fulfilling a static purpose. It's possible this is just a sign of our times as we
attempt to sound-bite everything in our world. "It manages our projects" "It's our timesheet" or "It's our ERP
system" or "We have an EPM system" minimizes our having to continuously think of all the aspects of our business
that may be touched by our enterprise system. Yet those organizations I've encountered which have been the most
successful at deploying an enterprise project or enterprise timesheet system inevitably think of them as a "living
system"; a system which is continually evolving by design.
Why think of it as a static system?
If it's true that there is a better chance of success in an enterprise system being thought of as a dynamic
environment, why do so many organizations consider their enterprise system as a fixed piece of software?
There are many possible reasons.
Perhaps getting the enterprise system accepted meant making a business case in a complex budgeting
environment where there would be one chance and one chance only to get a budget approved for the system.
Going back each year or each budget cycle to ask for another phase and then another is politically impossible.
Or, perhaps you've inherited the system and certain promises were made about what it was to deliver or perhaps it
has been there awhile and everyone in the organization thinks of the system as delivering only a set list of business
features.
Or, perhaps inside politics are at work and there are those elsewhere in the organization who would be scared of a
system without boundaries.
What may be wrong about that thinking?
It's odd that we even think of a software system as static. We don't usually think of the problem it is to solve as
static. The problem statements that we associate to the implementation of an enterprise system are almost always
evolving. They are dependent on changing economic conditions, changing business conditions, changes in what
competitors do, changes in personnel or changes in technological architecture. An organization that thinks that
business conditions will never change is unlikely to stay in business long. If we think of enterprise software, think of
how quickly the technology aspect of the solution changes. In our own TimeControl timesheet business, we've
gone through 6 major technology architectural changes in 20 years. We started in 1994 with a DOS version, then
followed up in 1995 with a Windows version, then a Client/Server version in 1997, then a browser-based version
in 1999, and then a hosted in-the-cloud and a mobile version in 2010. That's just technology architecture.
Additional evolution occurred thanks to changing economic conditions, competitors and just from experience. For
those of us in the enterprise project or enterprise timesheet software publishing business, we accept that change is
a constant.
It's no different thinking of the deployment of an enterprise system. In the time it takes to implement an enterprise
system like Project Server, the organization implementing it is bound to change. There will be new clients, new
personnel and personnel who depart. In the time it takes to choose and deploy the EPM system, other competing
products will emerge. We've seen organizations paralyzed by this phenomenon. Due to concern that they will not
select the perfect product, the release of another product by another vendor has the selection group pause its work
to consider the new product. Or, the release of a new version of one of the products being considered has everyone
worry that their evaluation will not consider all alternatives. These groups start over and over and over again. A
final decision is never realized because the organization requirements and the solution options never stop
changing.
The problem for these organizations is that the business challenge that had them look for a solution in the first
place doesn't go away, and in the absence of a decision, they are not solved.
So if not static, then what?
Enterprise system deployments will have a better chance of success if they are living environments. They should
grow, evolve and adapt to the changing conditions around them. And, yes, perhaps at some point in the future
when they're old, they will need to be retired. The most critical change to this way of thinking is that the perfect
solution is not the starting point. The priorities become choosing a solution that meets the most critical needs but
which has the capacity to adapt to more complex needs in the future even if these have not been perfectly
articulated yet. One of the most important selection criteria becomes flexibility rather than breadth of functionality.
How can we avoid static cling?
There are a number of things we can do in order to avoid being stuck in a static deployment paradigm.
Make phases in your implementation plan and never run out of phases.
If we adopt a phased approach to the enterprise implementation, we can concentrate on a first phase that is
much more modest. Our consulting staff are taught to identify not the most we could do but the least. We
tell them to "look for the most minimal deployment, the deploying of which will produce an ongoing
positive return on investment." The great news about this is that value from the system will start much,
much more quickly and in the use of the system, even at a more minimal level, the requirements for future
use will become clearer.
Make a budget that allows for evolution.
One challenge we've seen in many deployments is the "one visit to the well" thinking where a request for an
enterprise system can be made only one time. Making a phased budget instead with the expectation that the
first couple of phase budgets are quite detailed but future phases are less so is inevitably more successful.
Pick highly flexible solutions.
Our staff have adopted the motto "Semper Gumby" (after the flexible toy Mr. Gumby). It's a play on words
first coined in the US military but it fits our thinking perfectly. Just like Mr. Gumby, we never know what
shape we'll be twisted into next so we think in terms of flexibility. In whatever enterprise solution you
choose, placing a premium on flexibility is a success criteria.
Don't abandon all of your implementation team when you go operational.
Keep key resources going forward. This is an extremely common challenge. Often in an enterprise
deployment, the organization is drawn to assigning its most experienced and skilled resources and that
certainly helps get the system selected and implemented. However those resources are the very ones who
will be needed on the next critical project and they are likely to be pulled off of this one just as the system
goes live and is at its most critical juncture. Planning in advance to have certain key resources stay with the
implementation for a longer period can make an enormous difference.
Make a permanent system enhancement team, small perhaps, but skilled.
The team that assembles the requirements for the enterprise system will be looking at business processes,
system functionality, integration with other key enterprise systems and more. Having these people abandon
the system once it's installed makes future evolution very challenging. Put this enterprise system and
perhaps other related systems into long term evolutionary care where the needs of the organization and the
system capabilities are evaluated on a regular basis.
Learn from actual use
Get your system into production early.
This is so much easier in today's world than it was even 5 years ago. You can take advantage of cloud-based
installations and remotely-accessible services to get your system running quickly. Most enterprise systems
which have both cloud and on-premises offerings have methods of evolving from one to the other. This is
certainly true with Project Server. It's true for our systems also.
Ensure there is a feedback loop that results in system enhancement.
It's good to see things that can be improved, not bad. Some implementation teams discourage suggestions
for improvement, concerned that they will keep people from using the system they have already deployed.
Our experience is that those who make suggestions for improvement are usually the biggest allies of the
enterprise system. Even if an idea can't be implemented right away, it should be welcomed. Creating a
system for identifying and encouraging new ideas for the enterprise system keeps everyone invested and
can bring enormous benefits.
Don't abandon hope too quickly.
Some firms will say "The problem is in the software" and jump ship before there's a chance of success.
Are we there yet?
So when will we get there?
Hopefully never.
That's not to say that the way stations along the way won't be great places to pause. Your first target for a new
implementation of enterprise software such as an enterprise project or enterprise timesheet system should be a
production environment that is delivering a positive return on investment. Look for a system that can deploy in
layers or phases and with enough flexibility to be able to grow, adapt and change and you're likely to find more
productivity along the way than you might find waiting to pick the perfect destination.
About the Author

GPS assistance in roadmapping an EPM deployment
This article is part of our "From the Trenches" collection. It describes how to make an Enterprise Project
Management deployment "roadmap" when you plan to implement EPM. It uniquely describes factors to consider
when you plan your deployment path.
G.P.S. Assistance in Roadmapping an EPM Deployment

In my last column, I talked about using a phased approach to making your plans for a deployment of Microsoft's
Enterprise Project Management (EPM ) Solution. Today we'll tackle making an EPM deployment roadmap as part
of your project plan.
If you've been to Microsoft Live Maps you know that directions require two things: A destination and a point of
origin. When we apply this analogy to an EPM deployment we have to think in similar terms:
1. Point of origin defined in technology, process, and personnel terms
2. Destination defined in business terms and prioritized
We may also want to define some 'way stations' or interim stops where you can regroup, take pictures, enjoy the
scenery for awhile and replenish your supplies for the next leg of the voyage.
When making a roadmap or directions, it's pretty common to have two scales. We keep the next leg of the trip in
great detail, down to a turn-by-turn route. We might also, however, keep a higher level map of the entire trip in less
detail to keep our current leg in the context of the entire trip. In project management terms, we call this "rolling-
wave planning."
"Directions"
When making an EPM deployment roadmap, we always start with the vision or intention of where the company is
heading in terms of its EPM efforts. This gives us the destination we'll need to make directions just like Microsoft
Live Maps would.
If we were just to ask, "What do you want?" the answer almost invariably comes in terms of a solution. People are
likely to say "I need a report that looks like this" or "Our firm needs portfolio analysis."
For those of us in the solutions business, we know these kinds of design notes are fraught with risk. We train our
consultants to be listening for clients who describe their problem as a solution. "That's a solution to a problem,"
we'll say, "not the problem. Let's define the problem."
So we tend not to ask "What do you want?" Instead, questions that may be useful during an envisioning might
include:
"What business decision are you now unable to make or are able to make only with great difficulty, the making of
which would be made easier as a result of this EPM deployment?"
Or:
"What aspect of the organization do you believe could be made more efficient either through an increase in
throughput or a decrease in effort through this EPM Deployment?"
Now, who should we be asking these questions of? Why, the people who make these decisions, of course! If you've
ever had a minivan full of kids and turned to ask them where you should go as a destination, you know that you'll
get 50 answers.
By the same token, we need to make sure that the organization's decision makers are a key part of this process or
we run the risk of picking a direction that the "driver" isn't prepared to travel to. There's an additional benefit to
bringing senior management into the EPM roadmapping process at this time. Aside from being a critical
participant in choosing the direction the EPM deployment should go, they are also able to get a sense of the
magnitude of the project. One of the most common and difficult challenges to a successful EPM deployment is
long-term management support. Some senior executives have not considered just how much this might change
existing practices and procedures and how disruptive, even temporarily, this might be. They may also not have an
appreciation of how much effort a culture-change project like EPM may be.
During our work with senior management as well as project management and perhaps line personnel, we try to
connect business decisions or business efficiency with process and technology. Is there a process that must be
created in order to fulfill this requirement? What would it need to accomplish? Is there a system function that either
exists or must be created to serve that business decision? What would it need to deliver?
Basic systems analysis is key in this phase. We start from the business decision "output" and work our way back to
the data elements required to make those decisions. In some cases, we find that the basic data simply isn't there
and this results in that element of the roadmap being flagged as "high risk." After all, we'll now need to include
collecting data in a new format or structure to capture those new data elements before we can even think of
delivering the better business process, and that can be a tall order in some cases.
We have one more thing to do before we close off the destination process and that's prioritizing the different
elements of the final vision. It is very common to think at the beginning of the roadmapping process that the
priorities will go one way but find that as you go to actually record them that they go very differently. Interestingly,
by the time everyone has agreed on what targets are included in our destination, there is remarkable consensus on
what the top priorities should be.
The next thing we need for directions is a point of origin and we manage that through an inventory of where the
organization is now in relation to the goals we've chosen.
We look at existing personnel. Are they trained in project management for their particular roles? Do we have
sufficient personnel with sufficient experience to accomplish the goals that have been set? Remember that we have
to look at multiple measures here because different people will have a different role in the eventual enterprise
project management process. It makes no sense to train every employee to be a project scheduler if, in fact, they'll
never be responsible to create schedules. By default, we think of four roles: Administrator, Project Manager,
Individual Resource, and Executive. If timesheets are involved, we think also of Supervisors as fifth role. Of course,
depending on what destination we've defined in our original envisioning process, the roles may be quite different.
That changes the skills inventory process profoundly, which is why we always start by defining the destination
before thinking about the point of origin.
We also look at existing process. Is there a stated or documented project management process? How is it
maintained? Who is in charge of it? If there is a Project Management Office already established, then a lot of this
effort is focused there. After all, there's no point in creating new procedures if there are existing procedures and
processes that are already effective. We may inventory existing processes that are both inside the current project
management process and outside, depending on what the ultimate goals of the EPM environment will be.
For example, we may have decided that contract management is going to be a significant element of our new EPM
environment, and that this has never before been part of the project management processes within this
organization. Yet, if we look a little farther afield, we may find that the organization has a strong set of controls for
managing documents and existing workflow already moving documents, perhaps in SharePoint. This would be an
ideal process for us to adopt and, if need be, adjust to make sure it will empower this aspect of the new enterprise
project management environment. Doing so carries a triple-edged benefit. First, we don't need to expend the effort
creating a new process. Second, we know that the personnel already have the skills and habits to use the process in
this way, which means no training effort or effort to get the personnel to comply. Finally we don't have the difficult
situation of trying to create a separate process that might be at odds with an existing process for managing
documents, such as contracts.
We know that one of our biggest challenges is going to be compliance. Not building the system, but getting
everyone to use it and to use it consistently. The more we can adopt existing habits, practices, and procedures that
are embedded in the organization, the easier compliance becomes.
Finally, you need an inventory of the technology platform. Since the Microsoft EPM Solution is built on a platform
of technology, it is likely to find some of that technology already in place, but it's also possible the organization will
have to upgrade some of its platform in order for the solution you're designing to function. SharePoint and SQL
Server are obvious elements of deploying Microsoft Office Project Server, but you may also need to check on
browser compatibility (is everyone using the latest version of Internet Explorer?), security status (will the system be
outward facing?), what version of SQL Server is deployed (is OLAP Services or SQL Server Reporting Services
already being used?). You may also need to consider other systems with which you'll need to interface or integrate.
How will you get access to those systems in production?
The size of the planned system may also necessitate looking at hardware, network, and other infrastructure
elements to ensure the system will have the structure it requires when it arrives.
As with any enterprise system, you'll want to plan both a production and staging area so that updates and
enhancements can be created in the lab rather than on the live system over time. You may also have to make plans
for a Pilot or Proof of Concept phase; something I'll talk more about in my next column.
"Recalculating Route"
When the G.P.S. unit in my car discovers that I've missed a turn, a very nice lady's voice says "Recalculating route".
Moments later, the line through my map changes and I've got new directions. In an EPM deployment we need to
be ready for a detour or a turn that's blocked for repairs. Perhaps we missed that freeway exit. How do we deal with
replanning? There are two things to ask when you go off course: First, are you still going to the same place?
Second, how do we get there from here? One of my favorite project management quotes on this subject comes
from Napoleon Bonaparte, who once said, "A battle plan lasts until contact with the enemy."
In an EPM deployment how do we apply this same principle? First of all, you need a measure to determine if you're
no longer on course. If one team member has an emergency dentist's appointment tomorrow and is absent from
the office for four hours, should we then let that discrepancy change all downstream tasks, reschedule everyone
from tomorrow at noon through the end of the project, and then e-mail everyone with their new assignment
times?
Of course not.
A discrepancy of four hours for one resource over the six-month lifetime of a project involving dozens of people
isn't enough of an interruption to warrant changing our path. What we need to do in starting any kind of enterprise
project is to set thresholds of acceptable progress. The aerospace and defense world is finding a new term for this
lately, "Tripwires," which is very descriptive. We can establish what criteria would indicate to us that our route needs
to be recalculated. There are several typical metrics or measures to consider. First, if the projected completion cost
varies by more than X percent from the original budget, then that might constitute a project plan review. You might
do the measure of cost in labor hours or money. Either is effective. Perhaps if the forecasted finish date varies by
more than X days from the originally planned finish date, then that might constitute a project plan review.
You might also decide that missing certain key milestones by more than a certain number of days is a tripwire, or
you might identify certain risks being realized as a tripwire, or you might determine that a change of certain key
project team members such as the executive sponsor is a tripwire. It's more important to set some criteria than to
get the criteria exactly right. Also, remember you're going to need to measure against these criteria throughout the
lifetime of the project, so if you choose 50 or 100 different metrics, you could end up spending more time
measuring the project than doing the project!
Once you've determined you're off course, the best way to get back on track is to conduct a project plan review. We
recommend including representation from both the original group of senior management who helped establish
our destination in the first place and from the group within the project management team who helped do the
original inventory. Project Plan reviews can get mired down in assigning blame for why the project is off track and
why a certain tripwire has been triggered. Such effort can be hugely counterproductive. We recommend focusing
on the following questions:
1. What happened?
2. Where have we ended up? What's our current point of origin?
3. Are we still committed to our original destination or is there a compelling reason to review that process or
even redo the envisioning process?
4. Do we need to reset any of our intermediate milestones or phases?
5. Do we need to change any of our project team?
6. Do we need to reset any of our tripwire metrics?
Questions which we've found to be less productive include:
Whose fault is it that we're here? Who's responsible? Who's to blame?
How do we get "back" on track; back to the old plan?
The most common reason for a project plan review is that the organization's priorities shift. For example, items that
were designed to be in Phase 3 are being demanded in Phase 2. This is usually a sign of a healthy dynamic within
the organization and the result of people starting to think seriously about the implications of the EPM System's
deployment.
Bad Weather
Before you set out on a long drive you probably check the Weather Channel (or weather.msn.com) to make sure no
inclement weather will affect your voyage. Risks are a part of life. Remember, if there were no risks, there'd be no
need for project managers! Planning for the most glaring risks is not a complicated process. Start at the beginning
of the envisioning process, and as you look at each of the elements of the destination you are designing, ask the
group what barriers to reaching this destination they can think of. In some cases the risks will be significant. It's not
uncommon for an organization to desire a particular result, only to find that the raw data required to deliver that
result has never been gathered and that there may be considerable resistance to the collecting of that data.
In one example, we found an organization that wanted resource capacity planning. That was going to require a
complete accounting of all of the resource availability of all project personnel and a complete accounting of all of
the possible workloads that could be applied to those staff. When we asked if both of those were available, we were
told that sure, they were available but only for two-fifths of the organization. When we then discovered that the
three-fifths of the organization that the data was not available for weren't even represented at the envisioning
meeting, we said, "Let us guess. The problems you're experiencing with resource capacity planning are in those
three divisions." Naturally they were, and we had to identify enrolling the division leaders of those divisions as a
separate phase of the project and very high risk.
As you move on to work with the project management and line personnel in the inventory process, ask during the
interviews for any risks these personnel might be able to identify.
Once the risks have been identified, it's important to organize them. If you've not done this before, the most basic
information will be the most valuable. Include:
1. A short description of the risk
2. The area or phase of the project which it may impact
3. The severity of the risk if the criteria is realized
Finally, one of the most important things you can do is to add some details on risk mitigation. Just thinking about a
risk is a huge mitigating factor, but while the EPM deployment is in its infancy, entering some notes on how you
might deal with a particular risk during the project can be invaluable. It's common for decisions to be made in
haste in an emotional context when risks are realized. Having some notes that were thought out while cooler heads
prevailed may be useful.
Let's drive the car we're building
Here's a tip on making your roadmap that may pay huge dividends: Use Project Server and the Microsoft EPM
Solution to help make and manage your roadmap plan. It seems obvious perhaps, but it's rare enough for
organizations to do that we mention it here.
I had a senior manager once tell me that his project staff had asked him if he thought using the Microsoft EPM
solution to deploy the Microsoft EPM Solution wasn't overkill. "If we built jet planes for a living, we wouldn't fly
them to work," they said. "Are you kidding?" he replied. "If I could fly a jet plane to work, I'd do it every day!"
In fact, using the Microsoft EPM Solution for the EPM deployment team is a great idea.
Installing Project Server and the other elements of the Microsoft EPM Solution isn't a huge technical challenge,
and with the absolute minimum of configuration you can be up and running with a small deployment team as the
users within a couple of days. This is a great way for those users who will become your deployment champions to
become familiar with the use and benefits of the system before it arrives at the desks of the bulk of the staff.
This deployment shouldn't be your production environment. You'll almost certainly be configuring that and
customizing it to fulfill the vision of the original destination. You almost certainly won't be working on things like
multi-project scheduling or resource capacity planning or portfolio optimization in your EPM deployment iteration
of Project Server, but you'll be able to deliver a system that can deliver great benefits. We'd recommend:
1. Do a rolling wave schedule as a published project.
A rolling wave schedule highlights the current phase in great detail and future phases as more of a
summary. This lets the team members know what they need to be working on now and still lets them see
the project in a larger context.
2. Manage the vision document in the Project Workspace.
The Project Workspace is a SharePoint site tied to the project which by default includes an area for Issues,
Risks, and Documents. Why not put all your project documents here for the EPM deployment project and
institute SharePoint's version control so that you can always get back to the original version?
3. Put your milestone sign-offs and "gates" in the Project Workspace deliverables.
This is a simple task list that you can link into tasks in Project Server. It will give a very high-end view of the
project and is an easy tool to use for threshold management to determine when you go "off course."
4. Put change management into the Project Workspace as issues.
Change management is one of the great challenges of technology projects. As new suggestions for changes
to the project arise, get them into the Issue area as a potential change to be managed. By adding a few fields
to this area you can get a list of high-priority items and who is responsible for them at any time.
5. Put the project risks into the Project Workspace.
Aside from documents and issues, the risk area of the Workspace is the ideal spot to add your risks and
mitigation plans. In fact, the default screen has all the fields there ready for you to use.
Are we there yet?
"Almost. We'll be there soon."
An EPM deployment can bring an organization to so many different places that there's no way to simply publish
the default schedule for everyone. But a few minutes searching the Internet may provide you with lots of possible
examples for different parts of the project. If I summarize the roadmap exercise above, you are likely to end up with
a project that has a few obvious phases:
1. Roadmap exercise
2. Envisioning (Choose the destination)
3. Inventory of existing processes (Identify the point of origin)
4. Inventory of existing personnel (Identify the point of origin)
5. Inventory of technology (Identify the point of origin)
6. Deployment of EPM solution for EPM team
7. Phase 1
8. Design
9. Configuration, Customization, Documentation
10. Pilot
11. Training
12. Roll-out
13. Review of Phase 1 and adjust Phase 2 as required
14. Phase 2
15. Phase 3
16. Phase 4
17. Project wrap up
Applying a roadmap exercise to your EPM deployment can change the experience from chaotic to manageable
very quickly. Just remember to pick your destination first, figure out your point of origin next, and draw the path
between them.
Happy traveling!
About the Author

Top-down or bottom-up
This article is part of our "From the Trenches" collection. It discusses project management, portfolio management,
and task management, and it compares the top-down and bottom-up management practices related to them.
To download the Word version of this article, see Top-down or bottom-up: white paper (Project Server 2010) .
Top-down or bottom-up?
"We need project management… Ummm, I meant portfolio management… Ummm, I really mean task
management… Oh heck, we need all of them," is a battle cry I hear often. It's not a lack of definitions of these three
concepts that causes confusion, it's their similarity.
Those of us who have worked in IT for many years tend to see things from a technical perspective and sometimes
it doesn't serve us well. If we look at data from Portfolio Management, Project Management, and Task
Management, it might look very similar. I've got an ID field, a description field, and a start and end date in all three.
Linking all three of these should be natural then.
Perhaps not.
Let's take these three concepts one at a time. It's easy to see their similarities, but there are fundamental differences
in the three perspectives.
Portfolio Management — a top-down approach
People can mean a lot of different things by "portfolio management," but the most meaning common is probably
project selection and prioritization. The principles ultimately affect everyone in the organization, but the process is
of great interest to senior executives. Management starts off with certain constraints, such as a total available
budget and a need to answer the question, "What can we and should we accomplish with this amount of money?"
If the portfolio management process is sufficiently mature, this analysis might include not just new ideas but also
existing projects.
To create a portfolio selection and prioritization process, management must confront what business criteria drive
the company and agree in advance on the metrics that will be considered when looking at new and existing
projects. Should return on investment be a key metric? Perhaps we should consider effects on client satisfaction or
staff retention or alignment with strategic objectives. Whatever the key metrics are, management has to weigh each
project initiative with a view to how that project can advance those objectives and how each project compares with
alternate initiatives on which the money could be spent.
This is a highly analytic process even if it's done in one's head. It's certainly highly analytic when you are using
project portfolio management software. Even once the analysis from software arrives in a report or a view, there is
virtually always some management-level oversight where a final decision on priorities gets made. When that is
complete, the final results must be transmitted to those who will do project management of each of the projects.
The effects of these decisions will be to fund some projects and not to fund others, to make available resources on
a higher priority to some projects and not to others, and to advance the schedule of some projects and to delay
others.
Project Management — top-down and bottom-up
Once a project is approved, it moves into a different realm altogether. Now the more classic view of project
scheduling comes into focus. Now we have to actually build the thing we described in our business justification
before it was approved.
A project manager starts thinking in terms of project scope and deliverables. The project manager knows the final
product that must be created, whether it is a piece of software or a building ready for occupancy. They may think of
the major phases of that project and create a work breakdown structure.
A critical path of logical steps required to complete the project gets designed. The project manager also knows that
he or she will be held to account for the schedule that is produced, so he or she consults a range of subject matter
experts in the project. The project manager creates a bottom-up view of the project by looking task by task and
summarizing those tasks up to project phases and eventually to the project itself. At this time the project manager
might also start allocating resources by skill, by department, or even by name. These resources might have costs
associated with them. The result of calculating the duration of the tasks, the resources required, and their rates
gives us a bottom-up estimate of the project.
So far, so good.
But when we look at the top-down approach of the project portfolio selection process, there was a cost, too. In fact,
the estimated cost of the project was part of the business justification that management considered when it
approved the project. If we're just getting the bottom-up estimate of the project from combined expertise of the
subject matter experts now, what did they use in the project selection up in the executive suite?
It's a good question. In some organizations, the project will be given a rough estimate from the project department
in order to create a business justification for the project. In other organizations, a complete bottom-up estimate is
created prior to considering the project in the portfolio process. The problem with both of these approaches is that
they take effort. A complete estimate may take a lot of effort and yet the project has yet to receive approval for
funding any effort. So, in many organizations, someone in management simply makes a guess as to what the costs
of this project will be.
So the process looks all integrated but there may be a bit of a catch-22 here. Which comes first, the work spent on
doing the estimate or the selection of the project in order to be able to spend time on the project?
Moreover, what happens if the bottom-up estimate doesn't match the estimate of the portfolio selection process? If
the estimate is less, there's probably no issue, but if the work can't possibly be completed in the time or budget
estimated by the portfolio selection people, there is a conflict.
You might think that the natural thing to do would be to reconvene senior management and just discuss the
problem, but there are a lot of situations where that isn't as easy as it seems.
First of all, the portfolio selection committee is rarely the project management staff. Senior project management
staff members are almost always included in the portfolio selection committee, but the group itself is usually very
senior executives who find it challenging to organize time to all be together. Secondly, the selection committee may
meet irregularly, so getting them back together to discuss all the ramifications of a mismatched cost for one project
versus the estimate might be a big challenge. Finally, there are some corporate cultures where it will not be a
career-advancing move to have to deliver the news to the senior executive that their guess is completely wrong on
what the appropriate schedule and budget for this project is.
Task management — a bottom-up approach
When we think of task management, we tend to think very operationally, and that most often brings us to our daily
agenda and a product like Outlook.
Now we're working at an individual or a small team member level. We don't see the tasks in context. We see those
things we've committed to or perhaps those things we've asked a team member to commit to. This is not an
analytic view at all. There are tasks to do and the individual has promised to do them.
At its core, task management is very straightforward. You do the task and when you're done you tell the person
who gave you the task to do that it is complete. All the functionality for this is already in Outlook.
The mischief of similar data
There's a saying, "If it looks like a duck and quacks like a duck, it must be a duck." That's true for ducks, but it isn't
always true for task-based data.
Let's consider these three levels of project-oriented data:
At the portfolio level, we have a project and perhaps phases below that project. The phase information
might have a code number, a description, a duration, a start date, and an end date.
At the project level, we have a project and tasks below the project. The task information might have a code
number, a description, a duration, a start date, and an end date.
At that task management level, we have a task and the task information might have a code number, a
description, a duration, a start date, and an end date.
They sure look the same, but in fact, the perspective of the data makes each of these rather common records serve
a very different purpose.
I'm often asked, "Can I move data from the portfolio view to the project view to Outlook and back."
The short answer to that question is "Yes."
But in our firm we have a mantra we say to ourselves when we're giving technical advice: "Don't tell me how to do
it, tell me why you should do it."
1. To make the point, imagine this example. We make an entirely integrated environment. At the top end of the
scale we have a list of projects organized by portfolio. Not only do we select these projects, but we integrate
even further, following them after they've been activated into live projects from the EPM system. To do this,
we use functionality already available to us to move the project and phase definitions from the Portfolio side
of our integrated system to the project side of the system. The data looks identical.
2. In our enterprise project management system we now make a more detailed definition, using the original
phases from the portfolio definition that was pushed from the top down. Doing this allows that summary to
be updated in the portfolio system when we update our projects. We make many tasks and assign many
resources. We now do a resource-leveling analysis to determine our capacity across many projects.
3. We use our resource assignments to push task and assignment data to each user as an Outlook task or
calendar event. Users no longer need to go to a "project management system". They are now able to see
their data in their daily agenda. The data looks just like it does in the project list and is linked further
upstream to the portfolio view.
4. Progress from these tasks and availability from Outlook is moved back from the individual to the project
management system along with estimates on when this work will be completed. The data looks just like it
does in the other two systems, so moving the data is relatively easy.
Creating such a system is technically very straightforward using the tools available to us today along with a bit of
configuration and development. And it would demonstrate beautifully.
We get asked for exactly this type of structure on a regular basis. But, even though we can do it, should we?
Imagine that at the task level, an individual takes the morning off for an emergency dental visit and updates her
Outlook that she will not be available this morning. That's bad news for him but the ripple effects to the project
could be massive. Now, the project system calculates that the task that was scheduled to be done this morning
won't be completed today; it will be completed only at mid-day tomorrow. It dutifully looks at the critical path and
all tasks downstream from this one and pushes them forward by four hours. Perhaps hundreds of tasks were
affected. The result might be pushing the end date of the project a half day later. Other projects are also affected as
other people working on this project must now have their tasks re-arranged and the portfolio view itself slides
forward a few pixels.
If we imagine this in real time, the problem is magnified. Hundreds or thousands of people are making changes all
through the day, and the EPM view, the resource leveling view, and the portfolio view animate back and forth with
the effects.
In reality this doesn't happen. First of all, the hapless dental patient will be back at her post at noon and may just
work a few hours later tonight to make sure this critical path is caught up and all will be back on track in the
morning.
Plus, even though the data looks the same, it is never integrated this way because of exactly this effect.
Data Context — the perspective matters
When we look at data, the context of the data is critical. Data that may look the same from a record-to-record
schema is used for very different purposes based on the perspective of the application.
In a top-down portfolio view, we are making strategic decisions of where to put our resources to maximize our
return on investment. We might make choices that a project manager wouldn't make. In my own organization, we
have sometimes chosen projects that are completely outside our existing skill set, knowing that we would be
terribly ineffective at accomplishing them but doing so because we wanted to improve those very skills. The return
on investment wasn't an effective installation, it was trained installers. This is an analytic view.
In a tactical project view, we are making operational decisions about where to get the best throughput of our
personnel and to get our projects completed as quickly and efficiently as possible. A project manager's eye is
always to the future. What happened in the past is only of interest to the project manager insofar as it improves his
or her view of the future. This is also a highly analytic view.
In a task management view like an agenda, we are not analytic. An agenda is a commitment system. We promise
ourselves or others that we will do a particular thing at a particular time. This might fit the analytic view. And it
might not.
Mixing these perspectives and contexts without understanding the impact can cause chaos.
Top-down or bottom-up?
There is, as usual, no right answer. Some aspects of your project management system really need to come from the
bottom-up. After all, in the end, it is individuals who will build whatever your project is about. But some decisions
are, and should be, made from the very top and are, as a necessity, top-down.
When you keep the distinctions of what each level of the project management paradigm is for, it does become
clearer to see if some of these systems should really be integrated or not. If the process and thinking of one level
doesn't have direct benefit by being fully integrated from another level, then integration is not the best play. It's
important to walk through how such integration would work in a real-world context and whether the frequency
and detail from one level delivers any value to the other.
If, for example, a steering committee only meets once a quarter to make big-play decisions about which projects to
move forward and which not, then what is the benefit to updating their view every day, every week, or even every
month?
Does the enterprise project management resource-leveling algorithm really need to see the dental appointment of
an individual or is it enough to know the approximate availability of that individual?
And yet, if we could send an assignment to an individual's agenda or timesheet screen directly, would that save
them a few minutes each day having to go into a different system and interface to see the same data?
So, top-down is right in some circumstances and bottom-up is right in others. You have to look at your own
situation to see where integrating these tools and concepts can pay back the right dividends before tying them
together.
About the Author

This article is part of our "From the Trenches" collection. It discusses using strategic drivers in Portfolio
Management to effectively create a standard approach for making important project decisions.
To download the PDF version of this article, see Aligning projects with strategic drivers.

Have you ever worked on a project that started great then over time lost firm commitment from your executive
sponsors? If you are fighting for the attention of key executives and the project lacks direction, then there is a good
chance you shouldn't be doing it.
This change of executive commitment is rarely the fault of the project team and typically represents a change in
direction. Rather it represents a shift in priorities. Our project might need to be re-scoped, re-prioritized or even
killed. These decisions can be very emotional.
A great way to remove some of these emotions is to attack the challenge head-on with a standard approach to
making important project decisions.
The approach I am referring to is Portfolio Management. An approach to making informed decisions is to align
Projects with your organization's strategic objectives. Microsoft Project Server 2010 has some very powerful
features that enable real-time decision making based on all sorts of criteria, including business strategy.
What You Will Learn
This article is primarily devoted to ways in which you can define measurable strategic drivers that will assist your
executives in selecting the right projects. Before diving too deeply into strategic driver definitions, I first provide an
overview of Portfolio Management and the basics of how Project Server automates the process.
What is Portfolio Management?
For purposes of this article, let's keep the definition really clean.
Portfolio Management means we follow a formal process to prioritize, select and agree on the right
projects based on a business strategy.
Project Management means we have teams to deliver these projects successfully.
Life Lessons
Back when I first started in this business, I thought I had Portfolio Management licked. I compiled a list of all my
projects, brought them to my Manager, prioritized them in order of criticality from 1-5 then reviewed that list with
my customers.
My fancy little system failed and I took the brunt of the pain because everything ended up being a priority and
frankly no one cared that there were too many projects with the same or higher priority—they just wanted their
projects delivered. So what did I learn? Here are a few things:
1. Priority ranking does not work. Why rate projects 1-5 or 1-10? These numbers are far too subjective.
Even if you have "1" that means "top priority" there is far too much more detail required to back up this
decision.
2. Executives own the portfolio. Executives need to work together to decide which projects will be funded
and need to agree and endorse the decisions. In my case, I took ownership of it, I ranked the projects and
then asked for confirmation. The people that really needed to be involved and tell me the priorities and work
out overlap never really talked to each other. I should have facilitated this rather than 'fill in the paperwork'
for them.
3. Be consultative. Ask lots of questions about why certain projects have certain priorities. If no one is
challenging each other and everyone's projects get on the list, there is a problem and I can guarantee there
are not enough resources to deliver.
4. The portfolio is alive. Not to go all Mary Shelley's Frankenstein on you but the fact is, priorities change.
They change because we have new management, there was a shift in the market, or whatever else you can
think of. Every few months a formal portfolio review should occur to ensure continued alignment.
5. It is okay to kill projects. It is perfectly acceptable to decide a project is no longer worth doing. Just make
the decision, be firm about it, thank everyone for their hard work, and move on. I have yet to meet someone
who told me, "My project is lousy, no one wants to work on it and our sponsors are checked out but hey, I
love spending endless hours on this dead elephant." Trust me, if killing projects is made acceptable by solid
process and even-keeled decision-making, people will be happier with their work.
The Portfolio Process
Our focus will be on prioritizing the Portfolio and using Strategic Drivers, but before we get to that, let's take a
quick look at a generic portfolio process.
In the example below, we start by creating proposed projects (I like calling them 'Project Stubs' since they are
basically placeholders at this point). With these proposed projects entered, we ask a team of knowledgeable people
to build the business cases for each and every project.
With our proposed projects created, the next step is to align those projects with the business strategy so our
Executive Team can select the right projects based on the data they have received. Once the projects are selected,
the Project Managers come in and start delivering with their defined teams.
TO DO THIS... USE THIS...
Create proposed projects Risk, strategic alignment, resource needs, benefits, and other
pertinent data
Select the right projects Executive-driven portfolio analysis
Plan and manage projects The selected projects
Strategic Drivers Defined

Microsoft Project Server lets you prioritize projects based on different criteria. You could start out with a simple
numbering system to the more advanced and value-added approach which is Strategic Driver-based optimization.
It is the latter that we focus on in this article.
A Strategic Driver is one of a few critical objectives that are set by your senior executives. These drivers must be
carefully crafted and meet the following criteria:
1. Easily understood and read by anyone.
2. Be measurable.
3. Is it specific enough to clearly measure value?
Okay, so give me some examples!
Sure. Let's say you are working for a discount airline. Your executive team recognizes that all the major airlines are
consolidating, that fees for checked bags are increasing and that customer service issues are increasing. These
smart executives realize there is an opportunity to grow and pick up frustrated customers, so they come up with a
multi-year plan that has some bullet points like this:
Increase revenue by 25%
Be recognized as offering the best customer service in the industry
Add 50 more planes to our fleet
Be seen as a leader in adopting new FAA regulations
This is great. Your executives have stated their objectives clearly and concisely. You now know the direction and you
have a list of strategic drivers to begin a portfolio analysis, right? Perhaps not.
A common mistake many companies make in defining their strategic drivers is to take this list and use it as their
Strategic Drivers. You might be wondering why I am telling you these are not good enough. Let me explain.
Pardon the pun, but those bullets are a bit too vague at the 30,000 foot level. We want about 5-8 drivers. Too few
drivers and everything will be prioritized too similarly. Eight or more drivers becomes too many and will wash out
the differences between various projects.
Let's see how we can relate those 30,000 foot bullet points down to a set of measurable drivers at the 15,000 foot
level.
Step 1: Hold Meetings
The Executives stated their 5 year plan with some specific goals in mind. You need to quickly align projects to those
goals by defining a set of Strategic Drivers. Hold a number of meetings to come up with those drivers. The
executives may be in the room or it may be a group that reports to them who will come back with
recommendations but the meetings must be had.
At this meeting you come up with some selected drivers to meet each objective.
BUSINESS OBJECTIVE STRATEGIC DRIVERS
Increase revenue by 25% Introduce new premium products

Increase energy efficiency
Be recognized as offering the best customer service in the Reduction of call hold times
industry Pre-emptive service programs
Add 50 more planes to our fleet Penetration into family destinations

Increase short-haul business destinations
Be seen as a leader in adopting new FAA regulations Standardize fleet and components
Step 2: Recognize "Force-ins"

You may have noticed we are a little light on the FAA regulations part. Many airlines today that are behind on
modifying their planes due to FAA regulations blame the various types of planes they need to retrofit or buy
special parts for. Other airlines can complete their changes in record time because their entire fleet is of the same
or similar make and model. Our fake airline decided that since they are building up a new fleet and want to be seen
as a leader in the space, they need to standardize.
If you live in the United States, you know the FAA, or Federal Aviation Association, is a government agency. If the
FAA tells an airline to replace their seatbelts, the airline has to replace their seatbelts. Our seatbelt replacement
project would have to be "Forced In", meaning even if we had other projects to do we must do this one.
There are other types of projects our airline has to do as well. Maybe to keep up with technology changes on their
website, they need to upgrade to newer computers and software.
We will recognize two types of projects that will get done independent of their ranking:
FORCE-IN EXAMPLES
Regulatory and Compliance Regulatory projects ranging from changes to tax laws to
industry-specific laws
Projects you must do to remain in legal compliance as a
corporate entity
Sustaining Projects you must do to keep the company running

Building maintenance
Airplane maintenance or replacements
IT systems updates or replacements
Please do keep in mind that just because these projects are "forced in" does not mean they have to be done right
away. If projects can be deferred to a later date or accommodated by another like-type project, there are always
options for you to consider.
If the FAA tells you to replace those seatbelts by the end of March, it gets forced in and the resources will be
allocated to get it done. On the other hand, if your corporate office needs an expansion to accommodate new hires
but could wait a year while doubling-up office space, perhaps that is what you do.
To wrap up this step, recognize there are always projects that must get done. Categorize them as such and
remember that budgets, resource needs and start dates can always be challenged.
Step 3: Weight the Drivers
In Step 1, we decided on the Strategic Drivers and asked our Executives to agree or disagree. Let's say we all
agreed that these are the drivers:
BUSINESS OBJECTIVE STRATEGIC DRIVERS
Increase revenue by 25% Introduce new premium products

Increase energy efficiency
Be recognized as offering the best customer service in the Reduction of call hold times
industry Pre-emptive service programs
Add 50 more planes to our fleet Penetration into family destinations

Increase short-haul business destinations
Be seen as a leader in adopting new FAA regulations Standardize fleet and components
Right now, everyone is probably very pleased with themselves and there is likely little disagreement by anyone.
Remember how I said earlier in this document that Drivers need to be Measurable? In Step 3 we measure the
drivers. This is where people start to realize perhaps their projects won't be selected because they are not aligned.
Expect push-back and some politicking. This is a normal process but getting through this can be somewhat difficult
so hang in there.
Microsoft Project Server has the ability to create Strategic Drivers and weight them. You can do everything I am
about to share with you directly in the tool. In fact, many of my clients will actually input information into the tool in
real-time so they can see the impact of their decisions.
Let's get started. There are two ways we can weight our drivers. One way is to simply weight the drivers manually
so they add up to 100% in total like this:
STRATEGIC DRIVERS STRATEGIC DRIVERS WEIGHTING
Introduce new premium products 15%

Increase energy efficiency 40%
Reduction of call hold times 5%

Pre-emptive service programs 10%
Penetration into family destinations 10%

Increase short-haul business destinations 5%
Standardize fleet and components 15%
TOTAL WEIGHTING 100%
Another weighting method Project Server supports is called the Analytical Hierarchy Process (or AHP for short).
This is a very powerful tool to get the weightings by asking all our executives to compare each driver against each
additional driver then Project Server will calculate the percentage based on those answers. Here is how this process
works:
You pull up each driver and then ask your executives to say whether it is more or less important. Here is a simple
example:
MORE OR LESS IMPORTANT THAN THIS

IS THIS DRIVER... DRIVER... DECISION
Introduce new premium products Increase energy efficiency Much more important
Introduce new premium products Reduction of call hold times Much less important
All drivers are weighted against all the others.

The point of this exercise is to get our executives thinking in terms of just how important each driver is based on
the merits of other drivers. At the end of this effort, Project Server will give you a set of weightings that may
surprise you and everyone else. At this point you can say "Okay, this is what we agreed to; let's stick with it" or you
can re-adjust the weightings. A best practice we recommend is to stick with what the tool came up with because it
is based on real conversations with people in a room that made the decisions. Just make sure there is follow -up
documentation and communications so people understand where these numbers came from.
Step 4: Add Measurements to the Drivers
So far, this whole exercise has really been to get our executives on the same page as to what is important to them
so we can fund and scope the right projects. Now it is time we get to a point where the project teams have
something they can use, too.
Let's say after Step 3 is completed we came up with the following Drivers and Weightings:
Introduce new premium products 40%

Increase energy efficiency 15%
Reduction of call hold times 10%

Pre-emptive service programs 5%
Penetration into family destinations 10%

Increase short-haul business destinations 5%
Standardize fleet and components 15%
TOTAL WEIGHTING 100%
At this point, we could ask our project teams to get all their proposed and in-play projects aligned with these
drivers. The problem we are faced with is measuring just how well these projects are aligned. If all projects are
aligned to "Introduce new premium products", which ones do we choose?
Microsoft Project Server allows you to define measurements for how well a project might align to any given
strategic driver. Our executives are not done yet. We need to ask them to help us get some good measurements in
the tool. We do this by setting up some selections the project teams can pick from:
STRATEGIC DRIVERS WEIGHTING ALIGNMENT
Introduce new premium products 40% Extreme: Brings >$25M in new revenue
Somewhat: Brings <$10M in new
revenue
Less: Only supports premium product
projects
Not Applicable: No impact at all
Increase energy efficiency 15% Extreme: Breakthrough technology

Somewhat: Reduce oil price by x%/gal
Less: Lightens plane load by x%
Not Applicable: No impact at all
Reduction of call hold times 10% And so on...
Pre-emptive service programs 5% And so on...
Penetration into family destinations 10% And so on...
Increase short-haul business 5% And so on...

destinations
Standardize fleet and components 15% And so on...
As you can see above, we put some measurements in place that clearly articulate what executives expect if projects
are aligned with drivers. There are in fact more than just three measurable inputs that can be associated with each
driver, but I just added these for simplicity's sake.
Step 5: Aligning Projects with Strategic Drivers
This step wraps up the final objectives we set at the beginning of this paper, but it is certainly not the last step. I'll
cover some additional details in the Final Thoughts section.
So far we have sat with our executives to define a manageable set of Strategic Drivers. We weighted those drivers
using the A.P. method and then we set some clear metrics on which the projects must align. We also discussed the
fact that some projects, like regulatory or sustaining projects, may not need that level of alignment but should still
be in the portfolio as 'forced in' projects.
Before we can do a portfolio analysis, there is work the Project Teams need to do. Whether a project is an actual
funded project or just an idea for consideration, they can all be entered into Microsoft Project Server.
The teams will then associate their projects with these drivers, including the measures that have been defined. This
is a simple website page that is easily filled in.
The teams will have to sit together in a meeting and share their results with the sponsors to ensure they have
properly aligned their projects.
Final Thoughts
Microsoft Project Server has some very powerful capabilities to help you more effectively prioritize, select or even
kill projects. This document does not cover the entire Portfolio Management process, but suffice to say, it is very
powerful, allowing for real-time decision- making.
Strategic Alignment is but one component of selecting and analyzing projects. You might also capture other data
such as Lifetime Project Costs, Net Present Value (NPV ), budgets and resource plans so you can look at the
complexity of delivering a project.
Going back to our airline example, a project may return a significant value based on the strategic drivers but take
up too many resources, take too long and the return on investment might be in question. Just because it aligns
doesn't mean we have to do it. Keep this in mind.
Microsoft Project Server doesn't just say, "Here is a set of projects and you get one portfolio." Indeed, you can
create many portfolios and "what if" scenarios that take various things like risk or cost into consideration. You
might have one locked-down portfolio that represents the work to be completed for the current year then a few
working portfolios for the coming years.
The journey to becoming a portfolio-driven company may have just started, but I guarantee you that, if done right,
it will pay off in the end. I sincerely hope you have found this article worth your time and am always happy to
answer your questions anytime.
About the Author

Bill Raymond is a seasoned executive with over 20 years delivering transformative projects. A businessperson at
heart, with a strong technical background, he is able to focus on delivering successful projects while architecting
technical solutions that solve difficult challenges. His experience ranges from managing commercial software
releases to implementing ERP systems and developing business processes to build corporate governance policies
and standards. Throughout his career, Bill has always embraced new technologies to help companies organize,
prioritize and manage their largest projects. With his technical background, he has helped organizations realize
their potential by driving standards while recognizing their unique culture.
Bill is Vice President of Solutions at Program Planning Professionals, Inc. (Pcubed.com) and has held the
prestigious title of Microsoft Project MVP since 2001.
Feel free to contact Bill anytime:
Phone: +1 415-294-0165
Work E -Mail: William.Raymond@Pcubed.com
Personal E -Mail: William_Raymond@Yahoo.com

A phased approach to deploying enterprise project
management
This article describes various challenges you can face when planning to deploy the Enterprise Project Management
solution in your environment. It also describes several different deployment scenarios that can be used, as well as
important prerequisites that need to be considered.
To download the Word version of this article, see A Phased Approach to Deploying Enterprise Project
Management: white paper.
A Phased Approach to Deploying Enterprise Project Management

This article provides business decision makers, network administrators, and Project Server administrators guidance
about various challenges you can face when planning to deploy the Enterprise Project Management solution in
your environment. It also describes several different deployment scenarios that can be used, as well as important
prerequisites that need to be considered.
Introduction
I own a company that does deployments of Microsoft's Enterprise Project Management (EPM ) Solution. To be fair,
HMS Software does more than that. We're also an ISV, but I spend a fair amount of my time working with
medium- to large-sized organizations on how they can deploy EPM. Some of the challenges are specific to
Microsoft's technology but many of them are similar to what I've seen companies face since I started in the project
management software business in 1983. We'll look at how you can plan your own EPM deployment here.
One of the biggest challenges we face when we start an EPM deployment is establishing a credible roadmap for
producing the intended result. While we have deployed enterprise project management systems here for over 24
years, one thing that hasn't changed is the desire of senior management to have all the results yesterday.
The challenge is compounded by a couple of factors that are almost always present:
1. The Sales team has shown the client the end-result without explaining the effort that would be required to
reproduce the effects in a production environment or even how much effort went into creating the virtual
image and data involved in the sales demonstration (typically several man-months).
2. Microsoft carries an ease-of-deployment legacy. People have gotten used to stuffing a DVD into their PC,
waiting until it pops out and then getting the benefits of the software they've purchased immediately. Oh,
there may be some notion of optional training but there is rarely an expectation that what is being
undertaken is an organization-changing exercise.
What is Enterprise Project Management?
That would be challenge enough but there are other aspects that are often overlooked by the client during a
purchase, starting with 'What exactly is EPM?' That's a short question with a potentially long answer. In the early
stages of an EPM deployment we do an envisioning workshop with the client's senior management. One slide that
I always use looks like this:
"What is EPM from your perspective?" I'll ask. The responses are often found in one of the circles on the slide. The
responses might be:
Basic Project Management. "For us, enterprise project management would mean that everyone would be
doing project management the same way and using the same tools."
Enterprise Project Management. "That wouldn't be enough for us," someone might say. "For us,
enterprise project management would mean that our project management data would be integrated. We
would be able to get reports that would show our schedules in an integrated, summarized report and we
would be able to manage the impact from one project to another."
Project Portfolio Management (PPM ). "It's about project portfolio management for us," someone might
say. "For us, enterprise project management would mean managing one level higher at the project level. We
would need to group projects into portfolios or groups of projects, and analyze and report on them together.
We'd need to be able to track progress at this summarized level as well as implement stage-gating."
Resource Management. "For us, enterprise project management would mean resource capacity planning.
We need to know not only if we can take on a new project and what the impact might be on existing
commitments, we also need to know what the status is of managing the work we've already committed to
based on project progress and resource availability."
Reporting Analysis. "For us, enterprise project management would occur in the reports," someone might
say. "We need a report that pulls from project management, finance, HR and other internal systems to make
roll-up reports for management and decision making. While we're talking about reports, we'll also need
dynamic dashboards, scorecarding and other visible systems."
Budgeting and Cost management. "For us, enterprise project management is all about the money. We
budget at the beginning of the year. We then budget for each project and the only thing that matters for us is
tracking the money against the plan, month after month."
Timesheets. "Never mind the planning. If you could just tell me what my people actually spend their time
on, we'd be so far ahead of where we are now, we'd call that an EPM success," someone often says.
Communication and Collaboration. "It's not about the fancy algorithms. We need to facilitate talking to
our people. Can you help us connect our project teams that now include not just planners but also senior
management, clients, users, sub-contractors, outsourcers and team members?"
Integration with External Applications. "We've got a big ERP/Finance system which is great except that
we don't have any of the forward looking projections for deliverables and costs that come with project
management. If you could connect a project management tool with our ERP/Finance system then that
would be plenty of enterprise project management for us!"
Workflow. "We envisage a system that tracks not just tasks but procedures in an automated fashion. We'd
like project managers to fill in an online form to request project funding which would then go to the person
responsible who would then, in an automated fashion, accept or reject the request. If approved, the project
would instantly be included in the EPM system. We'd like to do the same with all our project documents. In
fact, we'd like to automate all our project management procedures in this way through workflow
management. That would really be enterprise project management."
Business Intelligence. "What we need is scorecarding, dashboarding and data mining of our project data,"
some people will tell us. That would be the ultimate Enterprise Project Management environment."
The Project Management Maturity Model. "We're working on improving our maturity level as
measured by the 'Project Management Maturity Model'."
So, what's the right answer? They're all right. In fact, it's probably not an exhaustive list. EPM can mean so many
things to so many people and is highly dependent on the perspective you are looking at the problem from.
When we do this with senior management, what often happens is that there is no one of these aspects that is not
desired. Yes, people want all of them. And, when they ask if all of this is possible in a Microsoft EPM Solution
deployment, the honest answer is, "Yes". The problem is that each of these aspects of EPM can be considered as a
vector or a direction in which you can push the EPM environment. If we decide to push on all of these vectors on
the first day, the size of the project we'll end up designing will be so large, so potentially disruptive, so complex, and
involve so many other corporate systems that it will have little chance of success.
Remember, an Enterprise Project Management deployment isn't just technology. If it were, the implementation
would be over in a few days. No, an EPM deployment involves Strategy, People, Process and Technology.
Successful Microsoft EPM Solution deployments virtually always consider the project a 'Change Management'
project rather than a technology project. What we're looking to accomplish is to change the way the business
works. How? Well, depending on which direction an envisioning exercise goes, the direction could be very different.
If we try to implement every aspect and every direction at the same time, we could end up creating a huge project
that is complex and very difficult to understand and that just makes the deployment much riskier.
EPM Deployment Approaches
Let's talk for a moment about how many people approach an EPM deployment. There are a couple of possible
scenarios: the Big Bang, Instant Bang, and Phase Approach.
Big Bang
The Big Bang theory says "Let's do it all!" The idea is that we'll spend an inordinate amount of time designing,
building, rewriting and programming the ultimate enterprise project management environment. It will take a
phalanx of programmers and, one day, sometime in the future, on a given weekend, we'll flip a switch and everyone
will have enterprise project management. If we were to graph this as Return on Investment over time, it would look
like the picture at right.
There are pluses and minuses to using the Big Bang theory. On the plus side, there's a better chance than with
other types of approaches that the end result will be closer to the original intent. After all, the team doesn't rest
until they've checked off all the desires created at the beginning of the project.
On the negative side, however, there are a few big challenges. First of all, the organization doesn't receive any
return on investment until the project is 100% complete. That may be months or a year or more down the road.
Every day that the project is incomplete is a day someone can wander through the building with a "better" idea.
Also, the nature of life is that it changes. Any team change, management change, change in corporate mission or
strategy, change in fundamental technology architecture, change in corporate ownership can result in the project
being restructured or cancelled. If this happens, the organization receives nothing for its efforts.
Instant Bang
When we talk about the legacy of instant gratification legacy that follows Microsoft, we see a different
phenomenon. Some clients will assume that deploying the Microsoft EPM Solution is just like playing a Microsoft
Game. We load in the DVD and a few moments later, we're doing projects in a coordinated, collaborative fashion.
The return on investment looks good for a few days or even weeks as the pilot group with the most excitement
over the new system starts to use it. However, without the investment of the senior executives it is extremely
difficult, if not impossible, to effect culture or behavioral change and the project rarely extends. The system stays in
use for a short period of time and then is either abandoned or left in use by a tiny number of users who are often
frustrated that they've been unable to entice the rest of the organization to work together.
Phased Approach
We've found over the years that a phased approach is the most successful method of deploying an Enterprise
Project Management Environment. There are a lot of reasons for it. Here are a few:
First, the organization starts to receive a Return on Investment early in the process. This serves to safeguard
the implementation and validates to management their decision to do an EPM deployment in the first place.
Second, the deployment tackles technical challenges in waves rather than all at once. As the complexity of
the system grows, so, too, does the maturity of the organization in handling that complexity.
Third, the deployment eases the culture change into the organization over time, which is always easier. It's a
truism that change causes upset. That there will be some upset at such a change in managing projects is a
certainty. Deploying the entire vision over time lets the users adapt to the different way of doing business.
Finally, no matter how much time the organization spends in doing the original design, it is bound to change
its mind as soon as it sees the system in operation. Getting that first phase of the deployment into
production earlier lets the organization learn from it as they move forward.
The most critical element of this plan is the first phase. We instruct our consultants to determine "the most minimal
deployment possible which will return an ongoing positive return on investment." I've worded that very carefully.
We want to find a first phase of the deployment that can be put into production that will provide results and that
each week will give back more benefit than the effort required to produce them. If we do that, the deployment will
last forever. No one would remove the deployment because they'll say, "Oh, we can't remove that, we get 'this' out
of it every week." If we're successful creating that kind of deployment, we'll be able to build on it in the months to
come. If we're not, the project and the deployment is still very much at risk.
Getting started with your EPM Deployment strategy
If I've made you think twice about doing an EPM deployment, that's probably a good thing. Not that you should
not do it but a successful EPM deployment always starts off with a bit of extra thinking. So, how should you go
about doing your deployment? Let's start with a few prerequisites.
1. The Project Management Office
If your intention is to deploy an enterprise project management environment, there's no way around having an
enterprise project management organization. This is commonly referred to as Project Management Office, or
PMO. You can call it whatever you want, but there's got to be a central management of a system like the Microsoft
EPM Solution. Who will declare templates to be the 'official' template? Who will determine who has authority to
change resource priorities? Who will determine what a report will look like and who will have access to it? Who will
decide whether to manage risks and, if so, what process must surround it? And so on, and so on… No, a PMO is
essential. If you don't have such an organization (even if it's one person) then you'll need to start there as one of the
earliest steps towards your EPM environment.
2. Executive Sponsorship
Next, get sponsorship and support from senior management. Whoever is supporting this project from the
executive suite needs to know not only what the goals of the deployment are, but how long they'll be required to
provide support. We typically tell executives to plan for a minimum of a full year of sponsorship duties. One pitfall
that we often see is a small group of middle management or project managers who desire an Enterprise Project
Management environment but lack executive-level support and decide that they'll try to do the deployment
themselves in order to get that support. It's the Field of Dreams "Build it and they will come" approach and it's
almost never successful. The problem is that the very benefits that would be attractive to management (such as PM
methodology compliance, global project reporting, resource capacity planning, and collaborative project
management) are those benefits that can only be achieved with the participation of management.
3. We're project managers - we don't need project management!
If you want to avoid the most common pitfall to an EPM deployment, make a project plan. I know, that sounds
strangely simple but it's amazing how many EPM deployment projects don't, in fact, have a project plan. One of the
easiest pieces of advice we can give to organizations considering deploying the Microsoft EPM Solution is to make
it a project and to apply all the same methodology they already use for any other project. Is there a project
schedule; a budget; an executive sponsor; a project charter; resources; success metrics? These things might be
found in every other project in the organization but, just like the shoemaker's children who go barefoot, project
managers often forget to apply their skills to their own projects.
4. Set goals
Work at the very beginning of the project to determine what the measures for success will be at each phase.
Having a clear set of performance metrics goes a long way to helping not only the project team but also
management focus on completing a phase of the project.
Getting started
If you're wondering how to get started, here are a few suggestions.
Envision
Start with a facilitated vision session with senior management. If you use external assistance in no other aspect of
the project, you'll find it's most useful here. Having someone who has been involved in several other EPM
deployments is the key to success. We're not just talking about someone who has been a user of an EPM system
but someone who has worked through some of the issues we've described above and who has a good
understanding of both the capabilities of the Microsoft EPM Solution and the process of managing projects in an
organization.
Who's who?
One of the things you'll need to decide on early is, who is the 'enterprise'? I've used that term several times in this
article but the enterprise could mean whatever you decide. Is it your department, your division, your entire
company? One common mistake made by people doing a deployment is making a plan for an entire company but
only having authority over their own division. The hope is that others will come on board if the system is available.
It's a variant on the Field of Dreams approach and it makes for a solution that's not attractive to those other
divisions and not useful for the ones who you do have authority over. So decide early who will be involved and
make sure they're included in the planning.
Make a Project Plan
Just like you would do with any other project, take the time to make a proper project plan. There are numerous
plans available online that will give you guidelines on some of the subjects that you need to cover. They're a good
place to start, but you almost certainly have all the skills required to make a proper project plan for an EPM
deployment.
Conclusion
If you are considering or have started a deployment of the Microsoft EPM Solution, focus your deployment by
considering these three points:
1. Treat this project as a project. Use all the skills you already have for managing projects to manage the
Microsoft EPM Deployment project. Remember, it's primarily a change management project, not a
technology project.
2. Break the project into manageable pieces and treat each phase of the project as a sub-project with its own
success metrics, schedule, budget and resources. You'll get some of the benefits of the overall system faster
and that will serve to get even more support from management.
3. Remember that Return on Investment has to work at every level. It's not enough to make a system that
works for senior management but doesn't work for the people who have to manage it. Or, a system that
works for the project managers but doesn't deliver the reporting required by senior management. Or, a
system that works for the project managers and senior management but is too hard or too much effort for
individual users. Each person who must invest time and energy into the use of the system should be
considered in terms of their own return on investment.
If you're designing a deployment that follows a phased approach and uses the basic project management
methodology you already have for other projects, you've got a great chance of success. Good luck and happy
planning!
About the Author

Resource management: white paper
This article is part of our "From the Trenches" collection. It describes challenges in different aspects of resource
management and provides suggestions on creating a resource management system.
Resource Management
Resource management is the most popular reason organizations will switch from individual project management
to enterprise project management with systems like Microsoft Office Project Server.
You'd think that would mean we'd have an extensive playbook on how to get the very best resource management
out of such systems.
If only.
Defining Resource Management
The first problem, like so many aspects of enterprise systems, is defining exactly what people mean by "resource
management". Depending on your perspective, resource management could be a number of different things.
Resource Leveling
Let's start with the purist view. This comes from those of us in the industry for more than 15 years or so. When
project management software was first made available as a commercial product, it was a critical path methodology
(CPM ) scheduling tool. There was no consideration of resources at all in those early systems. It was exciting
enough to get a schedule out of the system and then, when roll-feed plotters came out (mostly to support the
technical drawing industry), to use them to get bar chart or logic (network) diagram displays of our projects.
When resources were factored into these systems, they were to enhance the original calculations with the addition
of resources. The algorithms varied, but the intent was to ensure that any delays from insufficient numbers of
certain trades were identified long enough in advance to hire those people and get them on the job. We'll come
back to resource leveling a little later.
Critical Chain Planning
It's actually been around a long time, although I know for some people the concept of Critical Chain seems new
and is very exciting. For those who are schedule-centric, Critical Chain applies the resource constraints right into
the schedule and looks for the resource(s) that will have the most profound effect on the schedule's delivery. It is,
perhaps, what CPM should have been from the beginning, and when it's applied in the right situation, it can be
very revealing.
Resource Capacity Planning
If we expand our thinking a bit, we can include those first two definitions in a broader concept of managing the
capacity of our resources. This is, by far, the most popular concept that we are asked to deliver on in an enterprise
project management deployment. Resource Capacity Planning seeks to answer several questions for an
organization's decision makers:
Can I meet the commitments I've already made with the personnel I have?
If not, what changes in personnel would be required to meet my commitments?
If so, what excess capacity do I have to take on additional commitments?
If I'm given an additional project, can I accomplish it with my existing personnel?
If I cannot change my personnel, what will be the impact of new work I'm required to accomplish?
Resource Capacity Planning includes several concepts that must be implemented as part of your project
management processes. These include:
Resource Loading
To start the Resource Capacity Planning challenge, we can start with how much work needs to be done. (If
there's no work to be done, there's no need to manage the resources.) Having an accurate picture of how
much work each task will take and who needs to accomplish it is critical to an accurate analysis.
Skill Scheduling
In modern project management tools like Microsoft Project, we can manage the resource requirement now
just as a department or an individual but also as skills. Skill scheduling includes managing the resource
requirement but also managing the skills availability as an inventory, which seems to be more effective
overall than just managing the number of people available in each department. After all, you might have a
database management department but if the skills of your personnel are lacking in SQL Server 2008 and
that is the skill needed for the next project, then you're still lacking when it comes to getting the project done.
Resource Allocation
Who puts what resources onto the assignments? There is a process to be created to determine how resource
requirements are defined and then resolved. Should you start by requesting a category or competency of
resource? Should you make requests of individual resources in 'Proposed' mode and then have someone in
authority make them 'Committed'? Should you have different projects with proposed resources which are
kept separate? Should a project manager be able to commit resources from different departments or should
department heads have that privilege?
Resource Availability
You have the needs of the projects for resources but what resources are available? Who decides how much
time each resource will make available for project vs. non-project work? Who decides when vacations can be
taken? How will you determine how many hours of overtime can be worked a day? How will you deal with
unpaid overtime? Will it become banked time?
Resource Leveling
Once you have both the availability and the needs of the resources for your projects, comparing the two
should let you know where you're over-allocated and present the challenge of dealing with the over-
allocation. Should projects be prioritized so that some get the resources and some don't? Should some tasks
be prioritized so that some get the resources and some don't? Should you use automated resource leveling?
How about manual movement of tasks? Who will deal with reconciling a conflict where some parts of the
company are waiting for work from other parts?
Resource Contracts
This term is typically found in a matrix organization where we have department heads who manage groups of
resources and project managers who manage work that must be accomplished by those resources. The term
"Resource Contracts" refers to the negotiation between the project managers and those department heads to
commit resources to certain work. This might start as a request from the project manager for a certain person to
be available at a certain date for a certain time. The department head might reply with a counter-offer with an
option of a different person with similar skills or the person requested on a different date. The project manager
then replies with an acceptance or a counter-counter-offer and so on until the resource requirement is fulfilled.
Resource Tracking
For some organizations, the most important aspect of resource management is not the planning, it's determining
what has actually happened. "If you could just tell me what my people are actually doing with their time we'd be
much more efficient," a senior executive might say. For these organizations, the timesheet aspect of an enterprise
project management system becomes the most significant. Even without the integration back to the project plan,
the by-activity accounting still gives an enormous richness of data to management of what each task costs in terms
of effort. And it paints an interesting picture of how much time is available for project work and, more interestingly,
what time is being spent on aside from project work. When we can tie the timesheet collection back to the project
plan, then resource management can extend to budget vs. actual analysis. We can see what time was required for
each planned task, the progress on that task so far and the impact of the progress on the projected finish of that
task and any other tasks which may be affected by it.
Resource Communications
In a mega-project construction world, we used to not worry so much about resource communications. Foremen
would pick up the latest news from the project office in the morning and tell their crews what they needed to know
as they got started. In white-collar high-tech types of project environments, that's not the case at all. A project team
may now be made up of all kinds of people. Aside from the project schedulers and the resources who will do work,
you might have executive sponsors, the users, the client, sub-contractors, out-sourced developers and more. It's not
at all uncommon to now have a project team which exceeds not just the walls of your office but also the boundaries
of your organization. Communications in such an environment become much more significant. Resource
Management in this context might be just being able to effectively collaborate with all the resources implicated in
our project management process.
Resource Commitments
When we talk about project management systems, we tend to talk about a very algorithmic environment, but
managing the commitments of resources within a project is also an important aspect of getting things done.
Project team leaders need to manage the commitments they've requested and the commitments they've made. A
resource might say "I'll finish that by Friday." That's a commitment; a promise. It might be a perfect match for the
expected finish date in our schedule, and it might not. It's a commitment and that's distinct from when the
scheduling algorithm says the work should be done. Resource commitments might be managed in Outlook or
Office SharePoint Server or on a white board or in some other commitment tool, but they must be managed
somehow.
Resource Sub-Contracting
For some organizations, just managing the resources that are contracted from other companies is resource
management enough. When sub-contracts are involved, managing the promises that the sub-contractor makes
and ensuring that the contract provides the right incentive and is honored by the sub-contractor can make or break
a project.
It sounds pretty straightforward. After all, there are tools within the Microsoft EPM Solution for all these aspects of
resource management. Resource leveling, resource allocation, resource loading, skill scheduling are all referred to
in the basic functionality of Project Server or even just with Project Standard or Professional. Multi-project
resource allocation can be done with the Resource Substitution Wizard or the Team Builder in Project Server.
Resource tracking can be done with the timesheet in Project Server. Resource Contracts don't have much of an
interface by default but the whole idea of Proposed vs. Committed Resources is in that area so a more robust
interface for dealing with resource requests could be done with a web-based form with Office SharePoint Server
and tie into the functionality directly. Even Resource Sub-Contracting could be addressed with functionality from
Office SharePoint Server.
The Challenge
You may note that I've not talked about Resource Capacity Planning, and it's not because it's not possible. This is
typically the most requested aspect of an EPM deployment, but it's one of the hardest to actually deliver.
There's a fundamental challenge when we try to apply a resource leveling algorithm to a highly skilled group of
resources. In order to understand it, it's worthwhile to go back to what original designers were thinking when
resource leveling algorithms were created. I promised to come back to resource leveling and even critical chain
analysis and this is why.
When we think of the original resource leveling engines, they were designed for an engineering context. The first
project scheduling tools were written for heavy engineering and construction projects where calculations would be
done on one project at a time. Indeed, the entire organization might have been created to deliver a single project.
Original commercial tools targeted the Defense and Oil and Gas industries, which could take advantage of the
heavy volume of data these tools could manage. But, when we look at resources on such projects, we always think
of generic resources.
Resource scheduling on such a project is inevitably done by skill. A project scheduler thinks of how many
Mechanical Engineers, Electricians and Pipefitters they might need. Resource Leveling algorithms are perfect for
this question. We have a number of resources, we level the tasks, and the numbers of full-time staff can vary
upwards or downwards as need be. When we think of this for a significant number of the same type of
interchangeable resource, the algorithm works rather well.
Modern project management has extended the concepts originally created for mega projects with large numbers of
interchangeable resources and applied them all the way down to the individual level. The algorithm still seems to
work, at least in theory, and it sure works just fine in a demonstration because we only ever show one resource at a
time.
Let's take this example:
I've got a simple project here in Project Professional 2007. I've started the project with a milestone and added two
tasks which are to start right after the milestone is complete. As soon as I assign Chris to both tasks, I've got a
resource leveling problem. As you can see by the split screen, Chris is allocated to twice his availability which
makes perfect sense.
Now let's level the project using Project's Resource Leveling algorithm:
Again, things are perfect. Chris's tasks have been spread over a two week period instead of one, showing how one
of the tasks has to be delayed to a second week in order to get it all accomplished. Also, Chris is shown to be
working continuously from week one to week two.
All's well it seems until we add another resource to the calculation. Let's go back to our first situation and add a
couple of additional tasks to the project but assign them to someone else:
Now I've got two people working at once. Chris is back to his over-allocated situation (you can see both of his tasks
in week one and we've added three tasks for John who will start at the same time. John's tasks, though, are already
resource leveled because there is some sequence to them. If we're looking just at John's situation, it looks fine. John
is working continuously from week one into week two, but what happens when we apply the resource leveling
algorithm now?
Project levels Chris's time just the way it did the first time and Chris's work is continuous from week one to week
two. John, however, is going to have a full week's gap in his work as he waits for Chris to complete his second task.
It's unlikely that we'll want to have John reading the newspaper and staying idle in his cubicle for an entire week,
so it will now be up to John and Chris's supervisor(s) to manually manage how they should schedule their time.
We're only looking at the simplest example of two resources. The challenge becomes that much worse when we
have a full team to talk about, more than one project that's affected or more than one person put on each task.
This isn't a fault of Project. This is just how resource leveling works with virtually every scheduling tool on the
market that does resource leveling. First it calculates the critical path, and then it applies the resource constraints to
the schedule based on the options you've chosen. Different systems will have different options but when we apply
a resource leveling algorithm to individuals, this is where we always end up. Modern project schedulers have
learned not to apply classic resource leveling when scheduling must be done to the individual level.
This is also one of the fundamental reasons why we don't have analytical tools like Project push information into a
Resource Commitment system like Outlook. Outlook at its core could be considered a personal commitment
system. You make commitments in Outlook every day. You promise someone you'll be at an appointment next
week at 2pm. (That someone might be yourself.) You promise someone you'll complete a task by this Tuesday. We
look at Outlook today to see what tasks and appointments we need to fulfill and then use the communications
functionality of the system to respond to others about the commitments we're making or requesting.
Imagine that we would now integrate that with Project, which is, at its core, an analytical system. Moving activities
from Project or Project Server into Outlook and retrieving the progress on them is one thing. What if all of
someone's Outlook tasks were integrated back into the schedule? I might make an appointment next week to be at
the dentist for the morning. Should I now let the impact of this four-hour gap in my availability ripple through
every task I have scheduled in the future? Should all tasks be pushed four hours later? What about all the
schedules of all the people I interact with or whose tasks are affected by my four hour delay? Should the entire
company now start receiving emails saying their schedule has been pushed four hours later? But wait, I'm only one
person. What happens when everyone's Outlook commitments are affecting every task from every person in the
company? In short order, we'd have chaos.
If we are to integrate a resource commitment or resource communication tool like Outlook with a resource
capacity planning tool like Project or Project Server, we need to reconcile the philosophical differences between the
two paradigms. When the link from Project Server to Outlook was designed, this made up part of the thinking.
Outlook would be enabled to receive tasks from Project and to integrate those tasks into the Outlook calendar or
task list. "Pushing" tasks from Outlook to Project Server was not permitted.
Creating a Resource Management System
If you've made it this far, then you may be hoping I've got some advice on how to create resource management,
and I do have a few suggestions.
First of all, it's worthwhile to talk about what aspects of resource management apply to your organization and
which you can take advantage of quickly. It's quite common to find that some aspects of resource management will
be a bigger challenge to implement than others. I'm always keen to grab the low -hanging fruit first. You might be
most interested in Resource Capacity Planning, for example, but find that creating such a process and gathering all
the data to create a consistent process is a daunting challenge. Yet, you might find that implementing Resource
Tracking with a timesheet system gives you less cultural hurdles to overcome. So, start with broadening your
perspective of what Resource Management is to consider some other aspects.
If you're looking at Resource Capacity Planning, then you have to appreciate that any resource leveling algorithm is
going to have difficulties with resource definitions at the individual level. If that's so, then you can think about doing
resource leveling to the skill or generic level and leaving individual assignments to team leaders. This is often an
area of an EPM deployment that is upsetting to senior executives. For anyone who hasn't considered all the
implications, it isn't uncommon to imagine a system where analysis is done somewhere centrally and it not only
magically reconciles every individual's day-to-day calendar with their personal and corporate commitments, but
also ensures that they are working a full workday every day.
If Resource Capacity Planning is your concern, I've got an idea for you that's not suggested very often. In any high-
tech organization, skill scheduling to the individual level is very common because many people have a unique
collection of skills and knowledge that makes them particularly appropriate for certain kinds of work. If that is your
situation, then consider creating a 'Key Resource Project'. In my experience, the key resources in an organization
represent less than five percent of the total number of resources. These key resources are the people that are
essential to every project. They have that combination of skills and knowledge that is not found elsewhere, and
successful project managers know to make sure to get one of those key resources onto their projects if they want
to succeed.
A Key Resource Project would be a list of all of the tasks assigned only to those people. You would resource level
their work and let all the other resources around them be scheduled however they are by team leaders. This can be
implemented almost instantly and takes a relatively small amount of effort. Organizations who have tried this find
it often resolves much of the heartache of resource leveling without the cultural challenge and process
improvement challenges of a process that must include everyone.
It's also worthwhile to think of your solution as being more extensive than just Project Server, just like the Project
team does at Microsoft. The "Microsoft EPM Solution" after all is a stack of technology. When you consider all the
different aspects of Resource Management, then Windows SharePoint Services, Windows Workflow, Office
SharePoint Server (for forms), SQL Server all become vectors that are essential to creating an environment that is
tailored to what you need for your organization.
About the Author

Learn how an Office 365 global administrator can delete a user's information from a Project Online environment.
What user data is deleted?
Delete scenarios
Process Overview
Step 1 - Download the delete script files
Step 2 - Find the Project Web App sites in your Office 365 environment
Step 3 - Find the user's Resource ID on each PWA site (optional)
Step 4 - Close and check in all of the user's projects
Step 5 - Export the users data (optional)
Step 6 - Delete user account information added through SharePoint Online
Step 7 - Delete your user's data from the PWA site
Step 8 - Clear the cache for Project client users connecting to the PWA site
What user data is deleted?

In Project Online, admins can use the steps detailed in this article to delete user data and identifying data (data that
can be used to identify a user), such as:
Display name, phonetic name, GUIDs - You can choose to delete or rename the user's display name.
Users specific view settings - For example, if the user has customizations on their view settings (views,
filters, groups, tables, maps, drawing, reports) on top of grid pages with views (such as the Resource Center,
Project Center, Schedule webpart, etc.), these are deleted.
Calendar exception details - For example, if the user was out for a week in January because he or she
was sick or on vacation, the name of the exception is removed. Dates for the exception will remain.
User Permissions - For example, if user is associated with categories, groups or has been granted
individual global permissions, we will remove all the associations. The user will also be set as inactive.
User information contained in Project sites - such as issues, risks, deliverables, and documents - that are stored in
SharePoint Online might not be deleted through the Project Online user data delete process because some of
these users are given access to the project site but aren't PWA users. You will need to delete this data through the
process found in the Step 6 - Delete user account information added through SharePoint Online section of this
article.
IMPORTANT
We recommend running the SharePoint Online user data delete process before deleting the same user's information from
Project Online. This will prevent issues in which syncing with certain SharePoint Online items (such as Issues or Risks) will
overwrite user data in Project Online that has been deleted.
How does this differ from deleting a user through Enterprise Object Delete?
The user data delete process described in this article is different from deleting a PWA user through the Enterprise
Object Delete page in PWA Server Settings in several ways:
Enterprise Object Delete will delete the user as an enterprise resource. However, deletion is blocked if the
user/resource is any one of the following:
A project owner
A timesheet manager
On timesheet manager list
An assignment owner
In a resource plan
A workflow proxy user
Deleting user data through the steps in this article does not delete the enterprise resource. It changes the
user account to inactivate, removes the user data, and can optionally change the name of the resource to
something you choose (such as "Deleted User") .
Delete scenarios
Depending on your needs, this process allows you to delete your user data listed above, but also allows some
control of in regards to deleting the users display name in shared items, such as timesheets, projects, and
assignments. There are three delete scenarios that you can do:
Scenario 1: Delete user's information from Project Online except for the display name
In this scenario, all of the user's data is deleted, except for the user's display name.
You might choose this scenario if you want to know the work the user has done, such as through their timesheets
and tasks.
Scenario 2: Delete user's information from Project Online, but update the display name everywhere
In this scenario, all of the user's information is deleted. In all locations where the user's display name was shown, it
will be replaced with something of your choosing, such as "Deleted User". The resource ID for the user will remain.
You might choose this scenario if there is no business need to retain the user display name, even in shared records
such as timesheets and projects.
Scenario 3: Delete user's information from Project Online, but update the display name everywhere except for
timesheet records
In this scenario, all of the user's information is deleted, except in timesheet records. You can choose to replace the
user's display name with something your choose, such as "Deleted User". However, this will not affect timesheet
records, where the user name will still remain. The display name in the timesheets records is generated a new
Resource ID so that the updated user name cannot be identified through data in timesheet records.
You might choose this scenario you need to do further review of timesheet records in which the user appears.
Process Overview
The following is an overview of the process that admins need to do to delete a specific user's information in their
Project Online environment:
1. Download your PowerShell scripts: You need to download and unzip the PowerShell script files needed
in this article.
2. Find the PWA sites that contain the user's data: Find a listing of Project Web App sites in your
environment.
3. Find the user's resource ID on each PWA site (optional): On each Project Web App site, find the unique
Resource ID for the user. You can also choose to specify the user by login account (for example,
adambarr@contoso.onmicrosoft..com).
4. Close and check in all of the user's projects: This needs to happen before running the export scripts to
ensure that your changes aren't overwritten.
5. Perform an export of the user's data: This optional step is described in Export user information from
Project Online .
6. Delete user account information added through SharePoint Online (optional): This step is only
required if you need to delete a non-PWA users account information, such as a user who might have been
given access to a project site.
7. Delete your user's data from the PWA site: Run the script to delete the user's information from each
PWA site.
Through the script, you can choose to change the user's display name to something different (for example,
"Deleted User"). This is allows you to make the user anonymous, while keeping the item in which the user
information appears relatively unchanged.
8. Delete the cache for Project Professional users: After the script is completed successfully, PWA admins
need to delete the cache on each device in which Project Professional was used to open the project while
connected to the Project Online site. Clearing the cache prevents the user info from being readded to the
project if it is cached on the device.
Work with your Project Admins
Depending on your company, your Office 365 global admin might be knowledgeable about managing Office 365
administrative tasks, but may know little about Project Online administration. If this is the case, we recommend
that the Office 365 global admin work collaboratively with their PWA site admins to accomplish these tasks. For
example, a global admin would probably be best suited to run the PowerShell script to find all PWA sites, but
would probably need to work collaboratively with the PWA admin to accomplish the remaining steps and for help
regarding business rules and configuration of each PWA site.
IMPORTANT
As a best practice, make sure to backup your Project databases before deleting user data from your site. You can delete your
backup once you are sure you were successful.
Step 1 - Download the delete script files

You will need the use of several prepare PowerShell script files for the procedures in this article. The script files
referenced in this article are contained in the Project Online User Content Export and Delete script package.
Download and upzip the files to a location you can reference.
Step 2 - Find the Project Web App sites in your Office 365 environment
Global admins will need to use the SharePoint Online Management Shell to connect to their SharePoint Online
Admin Center and run the Get-SPOSite PowerShell cmdlet to get a listing of URLs for each PWA site in their
Office 365 environment.
NOTE
To run the Get-SPOSite PowerShell cmdlet, you need to be either in a Global admin or SharePoint admin role.
1. In the SharePoint Online Management Shell module, connect to your SharePoint Online Admin Center with
the Connect-SPOService cmdlet:
Connect-SPOService -URL <AdminSiteURL>
For example:
Connect-SPOService -URL http://contoso-admin.sharepoint.com
After connecting to your SharePoint Online Admin Center, use the Get-SPOSites PowerShell cmdlet to find all
PWA sites in your Office 365 environment:
2. After connecting to your SharePoint Online Admin Center, use the Get-SPOSite PowerShell cmdlet to find all
Get-SPOSite | ?{$_.PWAEnabled -eq "Enabled"} | ft -a Url,Owner
After successfully running, a list of all PWA sites and site owners in your Office 365 environment will display.
Step 3 - Find the user's Resource ID on each PWA site (optional)

IMPORTANT
If you have the user's login account, this step is optional. You will need either the user's login account or Resource ID for
each PWA site in order to run the delete script.
If you want to find the user's resource ID, PWA admins need to do the following on each PWA site that you found
in the previous step:
1. In the Project Online Server Settings, in the Enterprise Data section, click Resource Center.
2. On the Resource Center page, in the ** Resource Name ** column, locate the user's name then look in that
row to see if you can find a value in the Unique ID column. This value is the user's Resource ID. For
example, in the graphic below, you can see Aaron Painter's Resource ID value listed in the Unique ID
column.
In some cases, your table may be customized so that the Unique ID column is not available. If so, select the
checkbox to the left of the user name and then click Edit located in the Resources tab in the ribbon, and
then go to the next step.
3. On the Edit Resource page for the specific user, go to the System Identification Data section and find
the value listed for the GUID. The GUID is the users resource ID for this PWA site.
NOTE
If you have multiple PWA sites, each PWA site will have a different Resource ID for the same user. Make sure to pair the
Resource ID your find for the user with the specific PWA site URL.
Step 4 - Close and check in all of the user's projects

Before running the export script., you need to ensure that all of the user's projects are closed and checked in by
users on your PWA site. This will ensure that changes made by the delete script are not overwritten.
If needed, a PWA admin can force-checkin the project through the PWA Server Settings.
1. On the Server Settings page, in the Queue and Database Administration section, click Force Check-in
Enterprise Objects.
2. On the Force Check-in Enterprise Objects page, from the project list, select the checkbox next to the
project that needs to be checked, and then click ** Check-In **.
3. A message will display asking if you are sure you want to force-checkin. Click OK.
NOTE
Forcing a check-in of a project that is being modified by a user may result in the loss of those changes. We highly
recommend that users check in projects in the typical manner and that you use force check-in only when it is absolutely
necessary.
Step 5 - Export the users data (optional)

Before deleting your user's data, you should know all projects in which the user was a part of. This will allow you to
later verify if the user's data was removed, since some issue might have prevented deletion from happening (for
example, the project was checked out. You can see these projects through exporting the user's data. To learn how to
do this, see Export user information from Project Online (GDPR ).
The export script will also tell you if any of the user's projects are current checked out, since they need to be
checked in prior to running the RedactProjectUser script in the next step.
If needed, a PWA admin can force a checkin of the project through the PWA Server Settings.
1. On the Server Settings page, in the Queue and Database Administration section, click Force Check-in
Enterprise Objects.
2. On the Force Check-in Enterprise Objects page, from the project list, select the checkbox next to the
project that needs to be checked, and then click Check-In.
3. A message will display asking if you are sure you want to force-checkin. Click OK.
IMPORTANT
If you force check-in an project that a user is modifying, the modifications may be lost.
Step 6 - Delete user account information added through SharePoint

Online
NOTE
If you are deleting user data from SharePoint Online as well, we recommend deleting the SharePoint Online user data before
deleting the Project Online user data to prevent sync issues that can overwrite deleted content.
Users in your Office 365 environment who do not have Project Web App (PWA) accounts can also have their
name and account information in Project Online, and may want to delete it. This can happen if the user added
certain SharePoint objects to a project site. A project site is a SharePoint collaboration site that that can be created
when a project is created. SharePoint users who are not PWA users can be granted access to these collaboration
sites. When this happens, their account information is saved can be saved to PWA.. If an admin is deleting user
data in SharePoint Online, they should also look to see if they need to delete the users data in Project Online as
well if they notice any of the following in the SharePoint Online export data:
Issues associated with a project site
Risks associated with a project site
Documents associated with a project site
Deliverables associated with a project site
If the SharePoint Online user data shows any of the above, you can also delete the users account information from
the Project Online site by running the RedactProjectUser PowerShell script specifying the login account
information (since the user won't have a resource ID ):
.\Invoke-RedactProjectUser.ps1 -Url <PWASiteURL> -LoginName <logonName> -UpdateDisplayName "<newDisplayName>"

-RedactTimesheet $true
For example, from the SharePoint Online export data, you discovered that Eva Corets (account name of
evac@contoso.com), added issues and risks to a project site that was part of a specific PWA site
(https://contoso.sharepoint.com/sites/pwa1). Running the following will update all instance of her account name to
"Deleted User" on the specific PWA site.
.\Invoke-RedactProjectUser.ps1 -Url https://contoso.sharepoint.com/sites/pwa -LoginName

evac@contoso.onmicrosoft.com -UpdateDisplayName "Deleted User" -RedactTimesheet $true
Step 7 - Delete your user's data from the PWA site

Run the RedactProjectUser PowerShell script in the SharePoint Online Management Shell to remove user data
from the PWA site and to optionally update the display name of the user.
The RedactProjectUser PowerShell script is included with the Project Online User Content Export and Delete script
package.
NOTE
In order to run the RedactProjectUser script, you need be at least one of the following: > A site collection admin to the PWA
Site for which you are running the script. > If you are in Project permission mode, be assigned Manage Users and Groups
permissions on the Project Online instance. If you are in SharePoint permission mode, be in the Global admin or SharePoint
admin role.
In the SharePoint Online Management Shell, you will be using the Invoke cmdlet to run the RedactProjectUser
script:
Invoke-RedactProjectUser
The Invoke cmdlet uses the following paramaters:
PARAMETER DESCRIPTION NOTE
-URL URL of the Project Online instance. Required
-LoginName Login name of the user. Either LoginName or ResourceID is

required.
-ResourceId Resource GUID of the user. Either LoginName or ResourceID is

required.
-UpdateDisplayName New display name for the user If used, RedactTimesheet is also
required.
-RedactTimesheet Apply changes to timesheets? ( $true or

$false )
-Region This optional parameter specifies the

Office 365 environment you are using.
The values you can use for this
parameter include:
Default - Project Public Cloud.
China - Gallatin.
Germany - BlackForest .
ITAR - Office 365 United States
Government.
If the parameter is not used, the default
value is used ( Default ).
You can use the Invoke cmdlet and parameters in the following ways:
Scenario 1: Delete user's information from a Project Online instance except for the display name
Using this command will remove the user's data from the PWA site, except for the display name. Your organization
may want to leave the user's display name for a later review in case it's in a shared item, like a task owner in a
project or an entry in a timesheet.
Note that you can specify the user either by logon name or Resource ID.
Use the logon name
Use the cmdlet the following way if you are specifying the user by logon name:
.\Invoke-RedactProjectUser.ps1 -Url <PWASiteURL> -LoginName <loginName>

For example, the following remove all data for the user * evac@@contoso.onmicrosoft.com * throughout the
https://contoso.sharepoint.com/sites/pwa site, except for the user's display name

evac@@contoso.onmicrosoft.com
When running this command, a message will display asking you to confirm if you want to proceed.
After you confirm and the script successfully completes, a message will display stating: All data for resource
<user's display name> has been removed, except the name of the resource.
Use the Resource ID
Use the cmdlet the following way if you are specifying the user by Resource ID:
.\Invoke-RedactProjectUser.ps1 -Url <PWASiteURL> -ResourceID <ResourceID>
For example, the following removes all user data for the user with a resource ID of 0c7cd3fb -a0be-e111 -9fte-
00155d022d022681 throughout the https://contoso.sharepoint.com/sites/pwa site , except for the user's display
name
.\Invoke-RedactProjectUser.ps1 -Url https://contoso.sharepoint.com/sites/pwa -ResourceId 0c7cd3fb-a0be-e111-

9fte-00155d022d022681
<user's resource ID> has been removed, except the name of the resource.
Scenario 2: Delete user's information from a Project Online instance, but update the display name everywhere
Using this command will remove the user data of a user from the Project Online instance, and will change the
user's display name to something of their choosing, and this will also occur in timesheet records. Your organization
may want to change the user's display name to something that will make the user's identity anonymous, such as
"Deleted User".
Use the logon name

-RedactTimesheet $true
For example, the following will remove all user data for *evac@contoso.onmicrosoft.com* and will change his
display name to " Deleted User " throughout the https://contoso.sharepoint.com/sites/pwa site.

evac@contoso.onmicrosoft.com -UpdateDisplayName "Deleted User" -RedactTimesheet $true
<user's login name> has been removed and the name of the resource has been changed to <updated display
name> everywhere including timesheet records.
Use the Resource ID
.\Invoke-RedactProjectUser.ps1 -Url <PWASiteURL> -ResourceID <ResourceID> -UpdateDisplayName "

<newDisplayName>" -RedactTimesheet $true
For example, the following will remove all user data for the user with a resource ID of 0c7cd3fb -a0be-e111 -9fte-
00155d022d022681 and will change the display name to " Deleted User " throughout the
https://contoso.sharepoint.com/sites/pwa site.

9fte-00155d022d022681 -UpdateDisplayName "Deleted User" -RedactTimesheet $true
<user's Resource ID> has been removed and the name of the resource has been changed to <updated display
name> everywhere including timesheet records.
Scenario 3: Delete user's information from a Project Web App site, but change the display name everywhere
except for timesheet records
Using this command will remove the user's data from the Project Web App site, and will change the user's display
name to something you specify, but this will not occur in timesheet records. Your organization may want to
later analyze if they have a business reason to retain the users display name in their timesheet records.
Use the logon name

-RedactTimesheet $false
For example, the following will remove all data for *evac@contoso.onmicrosoft.com* and will change his display
name to " Deleted User " throughout the https://contoso.sharepoint.com/sites/pwa site, except in timesheet records.

evac@contoso.onmicrosoft.com -UpdateDisplayName "Deleted User" -RedactTimesheet $false
After you confirm and the script successfully completes, a message will display stating: After you confirm and the
script successfully completes, a message will display stating: All data for resource <user's Resource ID> has been
removed and the name of the resource has been changed to <updated display name> everywhere except for
timesheet records.
Use the Resource ID
.\Invoke-RedactProjectUser.ps1 -Url <PWASiteURL> -ResourceID <ResourceID> -UpdateDisplayName "

<newDisplayName>" -RedactTimesheet $false
For example, the following will remove all personal data for the user with a resource ID of 0c7cd3fb-a0be-e111-
9fte-00155d022d022681 and will change the display name to "Deleted User" throughout the
https://contoso.sharepoint.com/sites/pwa site, except in timesheet records.
9fte-00155d022d022681 -UpdateDisplayName "Deleted User" -RedactTimesheet $false
<user's login name> has been removed and the name of the resource has been changed to <updated display
name> everywhere except for timesheet records.
Step 8 - Clear the cache for Project client users connecting to the PWA
site
On all devices on which Project Professional or the Project Online Desktop Client connected to the Project Online
instance, an IT admin needs to clear the cache. Clearing the cache will prevent projects in which user information
was deleted from being updated from cached data that remains on the system. You also need to make sure that
none of the user's projects are open on the client before clearing the cache.
To clear the cache in Project Professional 2016 and the Project Online Desktop Client:
1. Select the File menu, and then click Options.
2. On the Project Options page, select Save.
3. In the Cache section, select Clean Up Cache.
See Also
Project Online export json object definitions
Your organization can export a specific user's content from your Project Online environment. To export this
content, an Office 365 global administrator can follow these steps:
Step 1 - Download the export script files
Step 2 - Find all Project Web App sites in your Office 365 environment
Step 3 - Find the user's Resource ID in each PWA site (optional)
Step 4 - Export your user's data from the PWA site
Step 5 - Review your exported content
Step 6 - Find and save custom views, custom filters, attachments, and macros
Considerations for master and inserted projects
Considerations for Project Home favorite and recently viewed projects
Work with your Project Admins
Depending on your company, your Office 365 global admin might be knowledgeable about managing Office 365
administrative tasks, but may know little about Project Online administration. If this is the case, we recommend
that the Office 365 global admin work collaboratively with their PWA site admins to accomplish these tasks. For
example, a Office 365 global admin would probably be best suited to run the PowerShell script to find all PWA
sites, but would probably need to work collaboratively with the PWA admin to accomplish the remaining steps
and for help regarding business rules and configuration of each PWA site.
Step 1 - Download the export script files

You will need the use of several PowerShell script files for the procedures in this article. The script files referenced
in this article are contained in the Project Online User Content Export and Delete script package. Download and
unzip the files to a location you can reference.
Some of the files included in this package are used to delete user data in Project Online and will not be needed
for this article.
Unblock your files
You will need to "unblock" the files you downloaded in the Project Online User Content Export and Delete script
package in order to user them in PowerShell. This is because by default, executing scripts downloaded from the
Internet is not allowed. Do the following to unblock your files:
1. In File Explorer, go to the location where you saved the zip file.
2. Right click on the zip file, and click Properties.
3. On the General tab, select Unblock.
4. Click OK.
All files contained in the zip file should now be Unblocked. You can verify this in the individual files by checking to
see if the Unblocked checkbox option no longer appears in the General tab of the file's Properties page.
NOTE
If you only have access to unzipped files, you can also unblock each file individually.
Step 2 - Find all Project Web App sites in your Office 365 environment
Global admins will need to use the SharePoint Online Management Shell to connect to their SharePoint Online
Admin Center and run the Get-SPOSite PowerShell cmdlet to get a listing of URLs for each PWA site in their
Office 365 environment.
NOTE
To run the Get-SPOSite PowerShell cmdlet, you need to be either in a Global admin or SharePoint admin role.
1. In the SharePoint Online Management Shell module, connect to your SharePoint Online Admin Center with
the Connect-SPOService cmdlet:
Connect-SPOService -URL <AdminSiteURL>
For example:
Connect-SPOService -URL http://contoso-admin.sharepoint.com
2. After connecting to your SharePoint Online Admin Center, use the Get-SPOSite PowerShell cmdlet to find all
Get-SPOSite | ?{$_.PWAEnabled -eq "Enabled"} | ft -a Url,Owner
After successfully running, a list of all PWA sites and site owners in your Office 365 environment will display.
Step 3 - Find the user's Resource ID in each PWA site (optional)

NOTE
If you have the user's login account, this step is optional. You will need either the user's login account or Resource ID for
each PWA site in order to run the export script.
If you want to find the user's resource ID, PWA site admins can to do the following on each PWA site that you
found in the previous step:
1. In the Project Online Server Settings, in the Enterprise Data section, click Resource Center.
2. On the Resource Center page, in the ** Resource Name ** column, locate the user's name then look in
that row to see if you can find a value in the Unique ID column. This value is the user's Resource ID. For
example, in the graphic below, you can see Aaron Painter's Resource ID value listed in the Unique ID
column.
In some cases, your table may be customized so that the Unique ID column is not available. If so, select the
checkbox to the left of the user name and then click Edit located in the Resources tab in the ribbon, and
then go to the next step.
3. On the Edit Resource page for the specific user, go to the System Identification Data section and find
the value listed for the GUID. The GUID is the users resource ID for this PWA site.
NOTE
If you have multiple PWA sites, each PWA site will have a different Resource ID for the same user. Make sure to pair the
Resource ID your find for the user with the specific PWA site URL.
Step 4 - Export your user's data from the PWA site

Next, you will need to run the ** ExportProjectUserContent ** PowerShell script in order to export your user's
data from each PWA site in your Office 365 environment. In order to run the script, you need to make sure you
and your environment meet the prerequisites, and then you can run the script.
The ExportProjectUserContent PowerShell script is included with the Project Online User Content Export and
Delete script package.
Prerequisites
License for Project Online: You need to be assigned a Project Online Premium or Project Online
Professional license.
Project Online Desktop Client: You will need the Project Online Desktop Client and be connected to the
Project Online instance. The Project Online Desktop Client is included with a Project Online Premium or
Project Online Professional license.
To connect your Project client to your Project Online instance:
1. Click the File tab to open the Backstage view. Click Info, and then click Manage Accounts.
2. In the Project Web App Accounts dialog box, click Add.
3. In the Account Properties dialog box, type a name for this account in the Account Name box.
4. Enter the URL of the PWA site you are connecting to in the Project Server URL box.
5. Click OK.
6. In the Project Web App Accounts dialog box, select Set as Default, and then click OK.
7. Restart Project, and log on to the PWA site.
Permissions: In order to have the required permissions to run the script, you need to do at least one of the
following:
Add yourself as a site collection admin to the PWA Site for which you are running the script.
If you are in Project permission mode, be assigned Manage Users and Groups and the Access
Project Server Reporting Service permissions on the Project Online instance. If you are in
SharePoint permission mode, be in the Global admin or SharePoint admin role.
Run the ExportProjectUserContent script
Use the ExportProjectUserContent.ps1 PowerShell script to export your user's data.
1. In the SharePoint Online Management Shell, run the ExportProjectUserContent script. You will need to
configure the following parameters when running the script:
Parameter Description
-URL URL of the PWA site
-ResourceID Resource ID of the user.
-LoginName Login name of the user.
-OutputDirectory Location to store the export files.
-Region This optional parameter specifies the Office 365 environment

you are using. The values you can use for this parameter
include:
Default - Project Public Cloud.
China - Gallatin.
Germany - BlackForest.
ITAR - Office 365 United States Government.
If the parameter is not used, the default value is used (
Default ).
You can chose to run the script either by specifying the user's Resource ID or login name.
To run the ExportProjectUser script using the users Resource ID
You would use the following command in PowerShell with the parameters listed above:
.\ExportProjectUserContent.ps1 -Url <PwaSiteURL> -ResourceUid <UsersResourceID> -OutputDirectory
<LocationToStoreOutput>
For example, if you want to export user data from the Costoso PWA1 site (site URL of
https://contoso/sites/pwa1) for a user with a Resource ID of cb5c91cf-fd6b-e711-80d0-00155da4a406, and have
the export files save to c:\pwa1siteOutput, you would enter:
.\ExportProjectUserContent.ps1 -Url https://contoso/sites/pwa1 -ResourceUid cb5c91cf-fd6b-e711-80d0-

00155da4a406 -OutputDirectory c:\pwa1siteOutput
To run the ExportProjectUser script using the users Login Name

You would use the following command in Powershell with the paramaters listed above:
.\ExportProjectUserContent.ps1 -Url <PwaSiteURL> -LoginName <UsersLoginName> -OutputDirectory

<LocationToStoreOutput>
For example, if you want to export user data from the Costoso PWA1 site (site URL of
https://contoso/sites/pwa1) for a user with a Login Name of AdamB@contoso.onmicrosoft.com, and have the
export files save to c:\pwa1siteOutput, you would enter:
.\ExportProjectUserContent.ps1 -Url https://contoso/sites/pwa1 -LoginName AdamB@contoso.onmicrosoft.com -

OutputDirectory c:\pwa1siteOutput
After the script runs successfully, all exported data will be stored in the -OutputDirectory you specified.
Select specific feature -related user data files to export
Some of the exported user content you receive will include a number of json formatted files that includes feature-
specific user information. For example, the Security.json file contains data about the user's security groups,
categories, and permissions settings. These feature-related json files are described in more detail in the next
section. By default, you will receive all 27 feature-related json files when you run the ExportProjectUserContent
script. However, you can use the -Options parameter to select specific json files to download. These include the
following:
-OPTIONS VALUES JSON FILES YOU RECEIVE
All All feature-related json files, all project-specific json files, and
all project-list files.
Timesheets Timesheets_Reporting.json, Timesheets_page#.json

For the Timesheets_page#.json, you will get file per page.
TaskStatus Rules.json, TaskStatus_AssignmentsHistory_page#.json,

TaskStatus_AssignmentsSaved.json,
TaskStatus_AssignmentsSubmitted.json
Security Security.json
Portfolio BusinessDrivers.json, DriverPrioritizations.json,

PortfolioAnalyses.json
StatusReports StatusReports.json
-OPTIONS VALUES JSON FILES YOU RECEIVE
Engagements Engagements_page#.json
ResourcePlans ResourcePlans_page#.json, ReportingResourcePlans.json
Projects DraftProjectList.xml , PublishedProjectList.xml.

ReportingProjectList
You will also receive one of each of the following for each
project that the user was a part of:
Project_projName_draft.json, Project_projName_draft.mpp,
Project_projName_draft.xml,
Project_projName_published.json, Project_projName_
published.mpp, Project_projName_ published.xml,
Project_projName_reporting.json,
Project_projName_reporting_Tasks,
Project_projName_reporting_Assignments,
Project_projName_reporting_Resources,
Project_projName_reporting_Baselines,
Project_projName_reporting_TaskTimephased,
Project_projName_reporting_AssignmentTimephased,
Project_projName_reporting_TaskBaselineTimephased,
Project_projName_reporting_ AssignmentBaselineTimephased
UserViewSettings UserViewSettings.json
Using the -Options parameter can be helpful if you want to export user data from the PWA site for specific
features. For example, if you are only concerned with your user's data in the Portfolio Analysis feature, you can
run the -Options parameter with the value of Portfolio:
.\ExportProjectUserContent.ps1 -Url https://contoso/sites/pwa1 -ResourceUid cb5c91cf-fd6b-e711-80d0-

00155da4a406 -OutputDirectory c:\pwa1siteOutput -Options Portfolio
This will allow you to export the three json files that contain your user's data that pertains to the Portfolio
Analysis feature (BusinessDrivers.json, DriverPrioritizations.json, PortfolioAnalyses.json).
Step 5 - Review your exported content

After you run the ExportProjectUserContent PowerShell script successfully, you will have the following output in
the output directory you specified when running the command:
Project list files - You will receive three .xml files that provide a list of projects contained in the Project
Draft and Published schemas in which the user was a part of. This means the user was involved in the
project as at least one of the following:
Was the project owner.
Has a task assigned to him or her in the project.
Is an assignment owner of a task in the project.
Is the status manager of a task in the project.
These three .xml files are:
Name Description
DraftProjectList.xml List of projects from the Draft schema that corresponds to
the conditions above.
PublishedProjectList.xml List of projects from the Published schema that corresponds

to the conditions above.
ReportingProjectList.xml List of projects from the Reporting schema that corresponds

to the conditions above.
The list of projects may differ slightly for each of the three .xml files. For example, a user can save the project but
not publish, meaning that it will appear in the DraftProjectList.xml file, but not the PublishedProjectList.xml or
ReportingProjectList.xml files.
A project admin can use the Project list .xml files to give them information about which project-specific export
files they be interested in analyzing to decide how much of the exported content should be shared with the user.
All three of the ProjectList.xml files will have the following properties for each project listed:
Property Description
SiteId The unique identifier for the PWA site in which the project
exists.
Proj_UID The unique identifier for the project.
Proj_Name Name of the project.
Feature-related files - For each PWA site that the user is part of, the following feature-specific .json files
will be exported to the specified output directory. The feature-specific files will contain user data as it
pertains to the feature use throughout the PWA site. For example, the Drivers.json file will include data
about Portfolio Analysis business drivers the user created or owned. If the user has no data relating to the
feature on the specific PWA site, the file will contain no data.
The feature-specific .json files include:
NAME DESCRIPTION
AdminAudit Project Web App server settings change data.
BusinessDrivers Portfolio analysis business drivers data.
Calendars Enterprise calendar data.
CustomFields Custom field data.
Delegations Delegation data.
DriverPrioritizations Business driver prioritizations data.
Engagements Resource engagement data.

NAME DESCRIPTION
LookupTables Lookup table data.
PortfolioAnalysis Portfolio analyses data.
QueueJobs Data about user jobs process through the Queue Service.
ReminderEmails Reminder email data.
ReportingResource Resource reporting data.
Resource Resource data.
ResourcePlans Resource plan data.
Rules Rules data.
Security Data about security groups, categories, and permissions.
StatusReports Status report data.
SubscribedReminders Subscribed reminders data.
TaskStatus_AssignmentsHistory Statusing assignments history data.
TaskStatus_AssignmentsSaved Statusing assignments save data.
TaskStatus_AssignmentsSubmitted Statusing assignments submit data.
Timesheets Data about timesheets.
Timesheets_Reporting Reporting data about timesheets.
UnsubscribedAlerts Unsubscribed alerts data.
UserViewSettings User view settings data.
Workflow Project workflow data.
WorkspaceItems Data about SharePoint items from project sites.
Certain feature-specific json files have the possibility of being large, so to improve performance, the following
json files will spawn across multiple files:
Engagements.json
ResourcePlans.json
Timesheets.json
TaskStatus_AssignmentHistory.json
NOTE
To learn more about the objects contained in each of the feature-specific .json files, see the Feature-specific data
section of Project Online export json object definitions.
Project-specific files - If the user is part of any project, then for each of those projects, several individual
files will be exported to the output directory. This will happen if the user is part of the specific project as
one of the following:
The project owner
Has a task assigned to him or her in the project
Is an assignment owner of a task in the project
Is the status manager of a task in the project
Project-specific data differs from the Feature-related data in that the data is specific to a single
project. Feature-related data can include user data across many projects in the PWA site that the
user was a part of, but pertaining to a single feature.
NOTE
For all project-specific files you receive, they will be prefixed with the specific project's Project Name. For
example, if a project has a Project Name of Project1, all project-specific files we describe in this section will
be prefixed with Project1.
For each project the user is a part of, you will received the following three sets of files:
- An .xml file for the project from the draft and published databases:
Name Description
<projectName>_draft.xml The project file from the draft schema saved as .xml format.
<projectName>_published.xml The project file from the published schema saved as .xml
format.
NOTE
See the Project XML Data Interchange Scheme Reference to understand the Project XML data contained in these files.
- An .mpp file for the project from the draft and published databases:
Name Description
<projectName>_draft.mpp The project file from the draft schema saved as a Project .mpp
file.
<projectName>_published.mpp The project file from the published schema saved as a Project
.mpp file.
NOTE
You can open the .mpp file with Project Professional 2019, Project Professional 2016, or the Project Online Desktop client.
- Eight .json files for the project from the reporting schema:
NAME DESCRIPTION
Reporting_AssignmentBaselineTimephased Assignment Baseline Timephase data for the project from the
reporting schema.
Reporting_AssignmentTimephased Assignment Timephase data for the project from the

reporting schema.
Reporting_ProjectBaseline Project Baseline data for the project from the reporting
schema.
Reporting_Tasks Project tasks data for the project from the reporting schema.
Reporting_Assignments Assignment resources data for the project from the reporting
schema.
Reporting_Resources Resources data for the project from the reporting schema.
Reporting_TaskBaselineTimephased Task baseline timephased data for the project from the
reporting schema.
Reporting_TaskTimephased Task timephased data for the project from the reporting
schema.
NOTE
To learn more about the objects contained in each of the .json files, see the Project-specific user data from the reporting
data section of Project Online export json object definitions.
- Three .json files with the project's metadata from the draft, published, and reporting schemas:
Name Description
<projectName>_draft.json Project metadata file from the Draft schema
<projectName>_published.json Project metadata file from the Published schema
<projectName>_reporting.json Project metadata file from the Reporting schema
NOTE
To learn more about the objects contained in each of the .json files, see the Project-specific Metadata files section of Project
Online export json object definitions.
Step 6 - Find and save custom views, custom filters, attachments, and
macros
After receiving the exported user content, you can use your data to find the user's custom views, custom filters,
custom tables, attachments, and macros. To find these, you will need to have the MPP and XML file for each
project in which you want to search. For more information on how to do this, see Find customized user items in
Project Online and Project Server user export data.
Considerations for master and inserted projects

As noted earlier, the export script will only export projects that the user was a part of as an owner, has an
assigned task, is an assignment owner of a task, or is the status manager of a task. When the user is part of an
inserted project, but not the master project, only the inserted project will be exported. Similarly, if the user is only
part of a master project and not any of the inserted projects, only the master project will be exported.
When saving a master project that a user was a part of, you will not need to save any associated inserted projects
if you are prompted.
Considerations for Project Home favorite and recently viewed projects

Data for a user's favorite and recently viewed projects in Project Home can only be accessed directly in-app. The
user needs to log in with their Office 365 account credentials to access their Project Home page and see the
projects that are listed.
1. Log in to Office 365.
2. In your browser, navigate to the URL project.microsoft.com to open your Project Home page.
3. On the Project Home page, take a screenshot of the projects listed in the Favorites and Recent sections.
See Also
Project Online export json object definitions
Find customized user items in Project Online and
Project Server user export data
This article describes how to search for a specific users customized items (views, filters, attachments, tables, and
macros) in a project when you do an export of the users data in Project Online or Project Server. This includes:
To find and save customized views
To find and save customized filters
To find and save attachments
To find and save customized tables
To find and save user macros
The procedures in this article require you to have the following:
The MPP file for the project
The XML file for the project
For Project Online, both files were provided to you when you exported the user data through the procedures in
Export user data from Project Online.
For Project Server, you will need to save the specific project file to XML format to create the XML file.
NOTE
When saving a project file to XML format with Project Professional, make sure that you have applied the latest updates.
To find and save customized views

1. Open the specific project's XML file in a text editor.
2. In the text, search for <Views> to find a list of user views for the project.
3. In the list of Views, look for any views that have the IsCustomized property set to true. For example, the
following means a View named Active Tasks has been customized from the global/default template:
<View>
<Name>Task Sheet</Name>
<IsCustomized>true</IsCustomized>
</View>
4. Now open the project's MPP file in the Project Online Desktop Client or Project Professional 2016.
5. Click the View menu to open the ribbon, and in the ribbon select the ** Other View ** dropdown menu, and
then click More Views.
6. In the ** More Views ** window, in the Views list, select the view you are looking for, and then click Apply.
7. The selected view will display. Take a screenshot of the view and save it.
8. Use the same procedure for all remaining custom views you found in the XML file.
You can repeat this procedure on each project in which you want to search for your user's customized views.
To find and save customized filters

2. In the text, search for <Filters> to find a list of user filters for the project.
3. In the list of Filters, look for all filters that have the IsCustomized property set to true. For example, the
following means a filter named Active Tasks has been customized from the global/default template:
<Filters>
<Name>Active Tasks</Name>
</Filter>
4. To save the view, open the project's MPP file in the Project Online Desktop Client or Project Professional
2016.
5. Click the View menu, and in the ** Filters ** dropdown menu, select More Filters.
6. In the ** More Filters ** menu, select the filter you are looking for, and then click ** Edit **.
7. The filter definition for the selected filter will display. You can take a screenshot of the filter definition and
save it.
8. Use the same procedure for all remaining custom filters you found in the XML file.
You can repeat this procedure on each project in which you want to search for your user's customize filters.
To find and save attachments

2. In the text, search for <Tasks> to find a list of user tasks for the project.
3. In the list of tasks, look for all tasks that have the NoteContainsObjects property set to true. For example,
the following means that task 18 contains an attachment:
<Task>
<UID>18</UID>
<NoteContainsObjects>true</NoteContainsObjects>
</Task>
4. To save the attachment, open the project's MPP file in the Project Online Desktop Client or Project
Professional 2016.
5. Click the Tasks menu, and open the task associated with the attachment (for example, task #18).
6. In the Task Information screen, select the Notes tab. You should see the attachment item listed.
7. Open the attachment item and save it.
8. Use the same procedure for all remaining attachments you found in the XML file.
You can repeat this procedure on each project in which you want to search for your user's attachments.
To find and save customized tables

2. In the text, search for <Tables> to find the tables in the project.
3. In the list of tables, look for any tables that have the IsCustomized property set to true. For example, the
following means the Entry table has been customized from the global/default template:
<Tables>
<Table>Entry</Name>
</Table>
4. Now open the project's MPP file in the Project Online Desktop Client or Project Professional 2016.
5. Click the View menu to open the ribbon, and in the ribbon select the Tables dropdown menu, and then
click More Tables.
6. In the ** More Tables ** window, in the Tables list, select the table you are looking for, and then click Edit.
7. The Table definition will display for the selected table. Take a screenshot of all the information in the
definition window and save it.
8. Use the same procedure for all remaining customized tables you found in the XML file.
You can repeat this procedure on each project in which you want to search for your user's customized tables.
To find and save user macros
NOTE
A project's XML files will not flag if it contains VBA macros. You will need to manually open the user's projects to verify if it
contains a VBA macro.
1. Open the project's MPP file in the Project Online Desktop Client or Project Professional 2016.
2. Click the View menu to open the ribbon, and in the ribbon select the Macros dropdown menu, and then
click View Macros.
3. On the Macros page, select Visual Basic to open the Visual Basic Editor.
4. In the Visual Basic editor, you can save each of the users custom VBA files.
You can repeat this procedure on each project in which you want to search for your user's customize macros.
See also
Export user data from Project Server
Project Online and Project Server export data
definitions
This technical reference article describes the data objects and properties contained in the output files you receive
when using the user data export method described in Export user data from Project Online and in Export user
data from Project Server . This article will include short descriptions of the objects and properties you will find in
the output data.
We can group the user data output your receive from both Project Online and Project Server into the following:
Project lists: A list of projects that the user was a part of in the Project Web App (PWA) site.
Feature-specific data: Feature in the PWA site in which the user might have data.
Project-specific user data from the reporting data: Detailed data about a user's project in the PWA site.
Project-specific Metadata files: Project metadata about a user's project in the PWA site.
Project lists
You will receive three lists of projects contained in the Project Draft, Published, and Reporting schemas. All the
projects in the lists were projects the user was a part of. This means the user was involved in the project as at least
one of the following:
Was the project owner.
Has a task assigned to him or her in the project.
Is an assignment owner of a task in the project.
Is the status manager of a task in the project.
This data includes:
List of projects from the Draft schema that corresponds to the conditions above.
List of projects from the Published schema that corresponds to the conditions above.
List of projects from the Reporting schema that corresponds to the conditions above.
The list of projects may differ slightly for each of the three files. For example, a user can save the project and not
publish, meaning that it will appear in the Draft projects list, but not the Published or Reporting projects lists.
A project admin can use the Project list files to give them information about which project-specific export files
they may be interested in analyzing to decide how much of the exported content should be shared with the user.
All three of the ProjectList files will have the following properties for each project listed:
SiteId The unique identifier for the PWA site in which the project
exists.
Proj_UID The unique identifier for the project.
Proj_Name Name of the project.
Feature-specific data
The export method defined in Export user data from Project Online creates the following feature-related .json files
that checks for a specific user's data in features used in Project Online. If no data is found for the user in that
feature, the corresponding .json file will be empty.
The export method defined in Export user data from Project Server queries for feature-related data through SQL
scripts run against the Project Server databases.
The feature areas for both Project Online and Project Server include the following. Click on the feature name in
the table to see brief definitions of the objects and properties you may see in the data you export data you receive
about the user.
NAME DESCRIPTION
AdminAudit Project Web App server settings change data.
BusinessDrivers Portfolio analysis business drivers data.
Calendars Enterprise calendar data.
CustomFields Custom field data.
Delegations Delegation data.
DriverPrioritizations Business driver prioritizations data.
Engagements Resource engagement data.
LookupTables Lookup table data.
QueueJobs Data about user jobs process through the Queue Service.
ReminderEmails Reminder email data.
ReportingResource Resource reporting data.
ReportingResourcePlan Resource plan reporting data.
Resource Resource data.
ResourcePlans Resource plan data.

NAME DESCRIPTION
Rules Rules data.
Security Data about security groups, categories, and permissions.
StatusReports Status report data.
SubscribedReminders Subscribed reminders data.
TaskStatus_AssignmentsHistory Statusing assignments history data.
TaskStatus_AssignmentsSaved Statusing assignments save data.
TaskStatus_AssignmentsSubmitted Statusing assignments submit data.
Timesheets Data about timesheets.
Timesheets_Reporting Reporting data about timesheets.
UnsubscribedAlerts Unsubscribed alerts data.
UserViewSettings User view settings data.
Workflow Project workflow data.
WorkspaceItems Data about SharePoint items from project sites.
AdminAudit
AdminAudit contains data about Project Web App server settings that the user changed. Each AdminAuditData
object will have the following properties:
SiteId Unique identifier for the PWA site.
ServerSettingName Name of the PWA server setting.
SettingOldValue Previous value for the setting.
SettingNewValue New value for the setting.
ChangedDate Time and date the setting was changed.
ResourceUid Unique identifier for the resource that made the setting
change.
ResourceName Name for the resource that made the setting change.
BusinessDrivers
BusinessDrivers contains data about Portfolio Analysis business drivers that the user created or modified. Each
Drivers object will have the following properties:
PROPERTY DESCRIPTION
DriverID Unique identifier of the business driver.
DriverDescription Description of the business driver.
BusinessDriverIsActive Is the business driver active (true/false).
CreatedByResourceID Unique identifier of the resource that created the driver.
CreatedByResourceName Display name of the resource that created the driver.
ModifiedByResourceID Unique identifier of the resource that modified the driver.
ModifiedByResourceName Display name of the resource that modified the driver.
ImpactDescriptionNone Description of what is considered to be no impact for the

driver.
ImpactDescriptionLow Description of what is considered to be low impact for the

driver.
ImpactDescriptionModerate Description of what is considered to be moderate impact for

the driver.
ImpactDescriptionStrong Description of what is considered to be strong impact for the

driver.
ImpactDescriptionExtreme Description of what is considered to be extreme impact for

the driver.
CreatedDate Date and timestamp of when the driver was created.
ModifiedDate Date and timestamp of when the driver was last modified.
Each Drivers object can have Department objects, which have the following properties.
DriverId Unique identifier for the business driver.
DepartmentId Unique identifier for the department.
DepartmentName Name of the department.
Calendars
Calendars contains data about enterprise calendars that are currently checked out by the user. Each
CalendarData object will have the following properties:
Id Unique identifier for the calendar.
Name Name of the calendar.
CheckedOutDate Date and time the calendar was checked out.
CustomFields
CustomFields contains data about custom fields that are currently checked out by the user. Each
CustomFieldData object will have the following properties:
ID Unique identifier for the custom field.
Name Name of the custom field.
CheckOutDate Time and date the custom field was last checked out.
Delegations
Delegations contains data about delegations that the user is involved in. The user can either be the delegate or the
person who requests for the delegation. Each DelegationData object will have the following properties:
Id Unique identifier for the delegation.
ResourceId Unique identifier for the resource that requested the

delegation.
ResourceName Name of the resource that requested the delegation.
DelegateResourceId Unique identifier for the delegate.
DelegateName Name of the delegate.
StartDate Start date for the delegation period.
FinishDate End date for the delegation period.
DriverPrioritizations
DriverPrioritizations contains data about business driver prioritizations that the user created or modified. Each
Prioritizations object may have the following properties:
PrioritizationId Unique identifier of the portfolio analysis prioritization.
PrioritizationName Name of the portfolio analysis prioritization.
PrioritizationDescription Description of the portfolio analysis prioritization.
ConsistencyRatio The prioritization consistency ratio.
PrioritizationIsManual True if a portfolio analysis prioritization is manual. If False, it is

calculated.
CreatedByResourceId Unique identifier of the resource that created the

prioritization.
CreatedByResourceName Name of the resource that created the prioritization.
ModifiedByResourceID Unique identifier of the resource that last updated the

prioritization.
ModifiedByResourceName Display name of the resource that last updated the

prioritization.
CreatedDate Date and time when the prioritization was created.
ModifiedDate Date and time when the prioritization was last updated.
For BusinessDrivers, you will see the following properties:
PrioritizationId Unique identifier for the prioritization.
BusinessDriverId Unique identifier for the business driver.
BusinessDriverName Name of the business driver.
BusinessDriverPriorityPercentage Priority percentage assigned to the business driver.
For the DriverRankings, you will see the following properties:
PrioritizationId Unique identifier for the prioritization.

BusinessDriver1Id Unique identifier for the first business driver in the
prioritization.
BusinessDriver1Name Name of the first business driver in the prioritization.
RelationValue Relationship value assigned to this business driver in

comparison to another business driver.
BusinessDriver2Id Unique identifier for the second business driver in the

prioritization.
BusinessDriver2Name Name of the second business driver in the prioritization.
Engagements
Engagements contains data about resource engagements that the user created or modified, or was requested as a
resource. Each Engagement object will have the following properties:
EngagementUID Unique identifier for the engagement.
ProjectID Unique identifier for the project for which the engagement
was requested.
ResourceUID Unique identifier for the resource requested.
ResourceName Display name of the resource.
EngagementName Name of the engagement.
CreatedDate Date the engagement was created.
SubmittedDate Date the engagement was submitted for approval.
ReviewedDate Date the engagement was reviewed.
LastModifiedDate Date the engagement was last modified.
SubmitterResourceUID Unique identifier for the resource that submitted the

engagement.
SumitterResourceName Resource name of the submitter.
ReviewerResourceUID Unique identifier for the resource that reviewed the

engagement.
ReviewerResourceName Display name of the resource that reviewed the engagement

request.
LastModifiedByResourceUID Unique identifier of the resource that last modified the
engagement request.
LastModifiedByResourceName Display name of the resource that last modified the

engagement request.
EngagementStatus Status of the engagement request:

0- Committed
1- Proposed
2- Draft
3- Rejected
Each Engagements object can contain multiple EngagementSegments, which may have the following
properties:
EngagementUID Unique identifier for the engagement that contains the

EngagementSegment.
SegmentType 0- Committed
1- Proposed
2- Draft
3- Rejected
SegmentStartDate The proposed start date. Depending on the SegmentType,

this is proposed/draft/committed start date for the segment.
SegmentFinishDate The proposed end date. Depending on the SegmentType, this

is proposed/draft/committed end date for the segment.
SegmentMaxUnits Maximum number of units representing capacity.
SegmentWork Number of work units for a work day.
Each Engagements object can contain EngagementComments, which may have the following properties:
CommentUID Unique identifier for the comment.
EngagementUID Unique identifier for the engagement that contains the

EngagementSegment.
CommentCreatedDate Date the comment was created.
CommentMessage Comment details.
CommentAuthorResourceUID Resource UID of the author of the comment.
CommentAuthorResourceName Resource name of the author of the comment.

LookupTables
LookupTables contains data about lookup tables that are currently checked out by the user. Each
LookupTableData object may have the following properties:
ID Unique identifier for the lookup table.
Name Name of the lookup table.
CheckOutDate Time and date the lookup table was last checked out.
PortfolioAnalysis
PortfolioAnalysis contains data about Portfolio Analyses that the user created or modified. Each Analyses object
will have the following properties:
AnalysisID Unique identifier for the analysis.
AnalysisName Name of the analysis.
AnalysisDescription Description of the analysis.
AnalysisType Type of analysis.
PrioritizationType Prioritization type for the analysis (Business driver or Custom

fields).
PrioritizationID Unique identifier for the prioritization.
PrioritizationName Name of the prioritization.
HardConstraintCustomFieldID Unique identifier for the custom field selected as the primary
cost constraint.
HardConstraintCustomFieldName Name of the custom field selected as the primary cost

constraint.
TimeScale The time scale selected for the analysis:

0- Days
1- Weeks
2- Months
3- Quarters
4- Years
BookingType Specifies whether a resource is considered committed or

proposed.
ModifiedByResourceID Unique identifier for the resource that last modified the
analysis.
ModifiedByResourceName Name of the resource that last modified the analysis.
CreatedByResourceId Unique identifier for the resource that created the analysis.
CreatedByResourceName Name of the resource that created the analysis.
FilterResourcesByDepartment True if resources are filtered by department.
FilterResourcesByRBS True if are resources filtered by resource breakdown structure.
FilterResourcesByRBSValueId The identifier of the RBS value being used for filtering.
FilterResourcesByRBSValueText The actual text of the RBS value being used for filtering.
UseAlternateProjectDatesForResourcePlans True if alternate project dates are used for resource plans.
AlternateProjectStartDateCustomFieldId The GUID for a custom field that contains an alternate start
date for a portfolio analysis.
AlternateProjectStartDateCustomFieldName The name of a custom field that contains an alternate start

date for a portfolio analysis.
AlternateProjectEndDateCustomFieldId The GUID for a custom field that contains an alternate end
date and time for a portfolio analysis.
AlternateProjectEndDateCustomFieldName The name of a custom field that contains an alternate end

date and time for a portfolio analysis.
ForcedInAliasLookupTableId Identifier of the internal lookup table used for forcing in

projects.
ForcedInAliasLookupTableName Name of the internal lookup table used for forcing in projects
ForcedOutAliasLookupTableId Identifier of the internal lookup table used for forcing out
projects.
ForcedOutAliasLookupTableName Name of the internal lookup table used for forcing out
projects
CreatedDate Date the analysis was created.
ModifiedDate Date the analysis was last modified.
ProjectData Dataset link for more information about the project on which
the analysis was done.
Each Analyses object can have ProjectData properties, which include:

ProjectId Unique identifier for the project.
ProjectName Name of the project.
AnalysisPriority Project priority.
AbsolutePriority Normalized project priority.
OriginalStartDate Original start date of the project.
OriginalEndDate Original end date of the project.
StartDate Start date of the project.
Duration Duration of the project.
StartNoEarlierThan Project starts no earlier than specified date.
FinishNoLaterThan Project starts no later than specified date.
Locked True if project is locked.
For Optimizer Solutions, CostConstraintProject objects can have the following properties:
ScenarioId Identifier of the cost constraint scenario.
ScenarioName Name of the cost constraint scenario.
ProjectId Identifier of the project included in the cost constraint

scenario.
ProjectName Name of the project included in the cost constraint scenario.
ProjectStatus Status of the project.
ForceStatus Force status of the project (whether it is forced in or forced

out).
ForceAliasLookupTableId Identifier of the internal lookup table used for forcing in

projects.
ForceAliasLookupTableName Name of the internal lookup table used for forcing in projects.
ProjectPriority Priority of the project.
HardConstraintValue Value of the project for the custom field select as a hard
constraint.
For Optimizer Solutions, CostConstraintScenario objects can have the following properties:
ScenarioDescription Description of the cost constraint scenario.
UseDependencies Specify whether or not the cost constraint scenario uses

dependencies.
CreatedByResourceId Identifier for the resource that created the cost constraint
scenario.
CreatedByResourceName Name for the resource that created the cost constraint
scenario.
ModifiedByResourceId Identifier for the resource that modified the cost constraint
scenario.
ModifiedByResourceName Name of the resource that modified the cost constraint

scenario.
CreatedDate Date when cost constraint scenario was created.
ModifiedDate Date when cost constraint scenario was last modified.
SelectedProjectsCost Cost of the selected project.
SelectedProjectsPriority Priority of the selected project.
UnselectedProjectsCost Cost of the unselected project.
UnselectedProjectsPriority Priority of the unselected project.
For Planner Solutions, ResourceConstraintProject objects can have the following properties:
CostConstraintScenarioId Unique identifier for the portfolio analysis cost constraint

scenario.
CostConstraintScenarioName The name of a portfolio analysis cost constraint scenario.
ProjectId Identifier of the project included in the cost constraint

scenario.
ProjectName Name of the project included in the cost constraint scenario.
NewStartDate The new start date of the project.
ForceStatus Force status of the project (whether it is forced in or forced

out).
ProjectStatus The status of the project.
ResourceWork The amount of work that is performed by a resource on a

project.
ResourceCost The cost of a resource on a project.
ForceAliasLookupTableId Identifier of the internal lookup table used for forcing in

projects.
ForceAliasLookupTableName Name of the internal lookup table used for forcing in projects.
ProjectPriority Priority of the project.
HardConstraintValue Value of the project for the custom field select as a hard
constraint.
For Planner Solutions, ResourceConstraintScenario objects can have the following properties:

ScenarioDescription Description of the cost constraint scenario.
CostConstraintScenarioId Unique identifier for the portfolio analysis cost constraint

scenario.
CostConstraintScenarioName The name of a portfolio analysis cost constraint scenario.
ConstraintType The type of restriction or constraint.
ConstraintValue A value that indicates the limit of a constraint.
AllocationThreshold The percentage number between 0 and 100 that specifies the
minimum threshold that is required for a resource to be
allocated to a project.
RateTable The cost rate table used for the resource.
EnforceProjectDependencies A flag that indicates whether project dependencies are

enforced.
EnforceSchedulingConstraints A flag that indicates whether scheduling constraints are

enforced.
HiringType The internal or external hiring type.
CreatedByResourceId Identifier for the resource that created the cost constraint
scenario.
CreatedByResourceName Name for the resource that created the cost constraint
scenario.
ModifiedByResourceId Identifier for the resource that modified the cost constraint
scenario.
ModifiedByResourceName Name of the resource that modified the cost constraint

scenario.
CreatedDate Date when cost constraint scenario was created.
ModifiedDate Date when cost constraint scenario was last modified.
QueueJobs
QueueJobs contains data about jobs that were created by the user through the Queuing service. Each
QueueData object may have the following properties:
CorrelationId Unique identifier for jobs that are part of a correlation with
other jobs.
QueueState Queue state the job is currently in:

0- Unknown
1- ReadyForProcessing
2- SendIncomplete
3- Processing
4- Success
5- Failed
6- FailedNotBlocking
7-ProcessingDeferred
8- CorrelationBlocked
9- Cancelled
10- OnHold
11- Sleeping
12- ReadyForLaunch
MessageType Queue job type (see the corresponding QueueStateLabel

value).
ErrorInfo Error details about the queue job.
JobId Unique identifier for the queue job.
PercentComplete Current percentage completed of processing the job through

the Queue service.
CreatedDate Date and time the queue job was created.
ProcessingDate Date and time the queue job began processing through the
Queue service.
CompletedDate Date and time the queue job was processed through the
Queue service.
ReadyForProcessingDate Date and time the queue job was ready to be picked up for
processed through the Queue service.
MessageTypeLabel Job type (associated with the MessageType value).
QueueStateLabel Current queue state of the job (see the corresponding

QueueStateValue).
ReminderEmails
ReminderEmails contains data about email reminder notifications for the user. Each ReminderEmailData object
will have the following properties:
SessionId The unique identifier for the reminder emails.

EmailType The type of emails: Task, StatusReport, Timesheet, or
Engagement.
RowIsReady If the email is ready to be sent out.
ReportingResource
ReportingResource contains data about reporting resources. Each ReportingResourceData object may have the
following properties:
ResourceUID Unique identifier for the resource.
ResourceNTAccount The Windows account name for a resource.
UserClaimsAccount Login name for the user.
ResourceEmailAddress The email address of a resource.
ResourceCanLevel True if resource leveling can be done.
ResourceEarliestAvailableFrom The earliest date that a resource is available for work on a

particular task.
ResourceLatestAvailableTo The last date that a resource is available.
ResourceStandardRate The standard rate of pay for a resource.
ResourceOvertimeRate The rate of overtime pay for a resource.
ResourceMaxUnits The maximum capacity (percentage or units) that a resource is

available to accomplish tasks during the current time period.
ResourceBaseCalendar The base calendar for a resource.
ResourceHyperlinkFriendlyName Shows the title or explanatory text for a hyperlink associated

with a resource.
ResourceHyperlinkHref The text that is displayed for a resource hyperlink, as specified

in the Edit User page of Project Web Access.
ResourceInitials The initials of a resource.
ResourceType The type of a resource (for example, Enterprise, Local, Project

Server, Material, or Generic). See ResourceType Enumerations
for values.
ResourceBookingType The resource booking type: proposed or committed.

ResourceCostPerUse The cost that accrues each time a work resource is used.
ResourceGroup The group to which resource belongs.
ResourceCode Contains any code, abbreviation, or number you want to

enter as part of a resource's information.
ResourceTimesheetManagerUID The unique identifier of a timesheet manager.
ResourceName(OR ResourceName1) Display name of the resource.
ResourceWorkgroup A number value that represents a team collaboration method

for a resource.
ResourceCostCenter A user-defined code for resource cost accounting.
ResourceIsTeam True if a resource is a team resource.
ResourceRequiresEngagements True if the resource can only be requested through an

engagement request.
ResourceCreatedDate The date and time that a resource was created in the project.
ResourceModifiedDate The date that information about a resource was last modified.
Each Customfields object may have the following properties:
CustomFieldValueUID Unique identifier for the custom field value.
CustomFieldTypeUID Unique identifier for the custom field type.
CustomFieldName Name of the custom field.
EntityUID(OR ResourceUID) Unique identifier for the resource.
CFValue Custom field value.
Each ResourceCapacityData object may have the following properties:
TimeByDay A primary key that identifies the day along a timeline. The
granularity is in days only.
BaseCapacity The maximum work capacity that is determined by the

resource calendar. Also known as baseline capacity.
Capacity The amount of work that can be done by a resource.

ReportingResourcePlan
ReportingResourcePlan contains data about reporting resource plans. It may have the following properties:
AssignmentId Unique identifier for the assignment.
TaskId Unique identifier for the task.
ResourceOwnerId Resource ID of the resource owner.
AssignmentCost The total scheduled (or projected) cost for an assignment.
AssignmentOvertimeCost The sum of the actual and remaining overtime cost of the
assignment.
AssignmentActualCost The costs incurred for work that has already been performed
on an assignment, along with any other associated costs.
AssignmentActualOvertimeCost The costs incurred for overtime work that has already been
performed on an assignment.
AssignmentWork The total amount of time, such as person-hours or days, that

is scheduled for an assignment.
AssignmentOvertimeWork The total overtime work for an assignment, including

overtime work that has already been performed, in addition
to remaining overtime work.
AssignmentActualWork The amount of work that has already been performed on an

assignment.
AssignmentActualOvertimeWork The actual amount of overtime work that has already been
AssignmentMaterialWork The total work time scheduled for a material resource.
AssignmentMaterialActualWork The actual amount of work that has already been performed
with the use of a material resource, usually expressed as a
percentage of the scheduled amount of material resource
work.
AssignmentPercentWorkCompleted Percentage of work that has been completed.
AssignmentStartDate Date a resource is scheduled to begin an assignment.
AssignmentFinishDate Assignment finish date.

AssignmentDelay Amount of time a resource is to wait before starting to work
on an assignment.
AssignmentStartVariance Variance at the start of the assignment.
AssignmentFinishVariance Variance at the assignment finish.
AssignmentACWP Actual cost of work performed for the assignment.
AssignmentBCWP Budgeted cost of work performed for the assignment (earned

value).
AssignmentBCWS Budgeted cost of work scheduled for the assignment (planned

value).
AssignmentBookingID Assignment booking GUID.
AssignmentType Type of assignment. NormalAssignment=0,

WorkOnlyAssignment=1, FixedCostAssignment=2,
FixedCostWorkOnlyAssignment=3, EmptyAssignment=4,
FixedCostGeneratedAssignment=100 (generated during RDS
transfer), ResourcePlanAssignment=101.
AssignmentResourceType The type of resource that is associated with an assignment.

See Type enumeration.
IsPublic True if the item was published, so a team member can see it.
AssignmentIsPublished True if assignment is published.
AssignmentWorkVariance The variance of assignment work from the baseline work as

minutes x 1000.
AssignmentCostVariance The difference between the cost and baseline cost for a
resource.
AssignmentCV Earned value cost variance.
AssignmentSV Earned value schedule variance.
AssignmentVAC Variance at completion.
AssignmentIsOverallocated True if any assigned resources are overallocated.
AssignmentPeakUnits Maximum number of units that a resource is assignmed for a

task.
AssignmentCreatedDate Date and time the assignment was created.
AssignmentModifiedDate Date and time the assignment was last updated.
AssignmentBudgetCost The total projected cost of an assignment.

AssignmentBudgetWork The total projected amount of work that is planned for an
assignment.
AssignmentBudgetMaterialsWork The total projected amount of use on the assignment of

material resources.
AssignmentResourcePlanWork The total time that is scheduled for an assignment in the

resource plan.
TaskIsActive True if the task for the assignment timephased data is active.
TimesheetClassUid GUID of the timesheet class.
Resource
Resource contains data about the resource. Each ResourceData object may have the following properties:
ResourceID ID of the resource within the list of resources.
ResourceAccount User's account.
UserClaimsAccount User's claims account (same as the Office 365 account when
using Project Online).
ResourceEmailLanguage Language code used for the resources email.
ResourceIsOffline True if the resource is offline. This feature is deprecated.
ResourceLastConnectDate The last time the resource connected. This feature is

deprecated.
ResourcePhonetics The phonetic spelling of the resource name. For use with
Japanese only.
ResourceHasNotes Whether the resource has notes (value of 2)
ResourceCanBeLeveled True if resource leveling can be done.
ResourceAccrueAt How cost is accrued against the resource. (1=Start, 2=End,

3=Prorated, 4=Invalid).
ResourceAvailableFrom The starting date that a resource is available for work at the
units specified for the current time period.
ResourceAvailableTo The end date that a resource is available for work at the units
specified for the current time period.

ResourceHyperlinkFriendlyName Shows the title or explanatory text for a hyperlink associated

with a resource.
ResourceHyperlinkHref Contains the combination, or concatenation, of the Hyperlink

Address and Hyperlink SubAddress fields associated with a
resource..
ResourceInitials The initials of a resource.
ResourceType The type of a resource. See ResourceType Enumerations for

values.
ResourceGroup The name of the group that a resource belongs to.

DefaultAssignmentOwner Default assignment owner for the resource.
DefaultAssignmentOwnerDisplayName Display name of the default assignment owner.
ResourceTimesheetManagerUID Timesheet manager for the given resource.
ResourceTimesheetManagerDisplayName Display name of the timesheet manager.
ResourceCostCenter The cost center for the resource.
ResourceRequiresEngagements True if the resource can only be requested through an

engagement request.
ResourceCreatedDate The date and time that a resource was created.
CheckedOutDate Time and date the resource was last checked out.
CheckedOutBy The user that checked out the resource.
DefaultAssignmentOwnerResources Resources for which the resource is the default assignment

owner.
Each ResourceData object may have a collection of DefaultAssignmentOwnerResources. Each

DefaultAssignmentOwnerResources object may have the following properties:
ResourceID The ID of the resource within the list of resources.
ResourceUID Unique identifier for the resource for which the user is the
default assignment owner.
ResourceName Name of the resource.

for values.
DefaultAssignmentOwner Default assignment owner for the resource.
Each ResourceData object may also have a collection of CustomFields. Each CustomFields object may contain
the following properties:
CustomFieldUid Unique identifier for the custom field.
CustomFieldValue Value properties for the custom field.
ResourcePlans
ResourcePlans contains data about resource plans the user created, modified, or was a part. For each
ResourcePlans object, you will see the following properties:

ResourcePlanUtilizationType Value that represents the utilization type of a resource plan.
ResourcePlanUtilizationDate The start date and time for use of the resource plan.
ResourceId Unique identifier of the resource.
ResourcePlanCheckedOutById Resource ID of the user that checked out the resource plan.
ResourcePlanCheckedOutByName Name of the user that checked out the resource plan.
ResourcePlanCheckedOutDate Date the resource plan was checked out.
ResourcePlanPublishStatus Internal property describing publish status.
ProjectCurrentRevCounter Internal property describing number of revisions.
ProjectCurrentRevRank Internal property describing number of revisions.
ResourcePlanCreationDate Date and time the resource plan was created.
ResourcePlanModDate Date and time the resource plan was last updated.
ResourcePlanCreatedRevCounter Internal property describing number of revisions.
ResourcePlanModRevCounter Internal property describing number of revisions.
ResourcePlanStartDate Date and time the resource plan began.
ResourcePlanFinishDate Date and time the resource plan ended.
ResourcePlanModRevCounter Internal property describing number of revisions.
ResourcePlanCreatedRevCounter Internal property describing number of revisions.
ResourcePlanAssignments Assignments associated with the resource plan.
A ResourcePlan object can have a collection of ResourcePlanAssignments. Each ResourcePlanAssignments

object may have the following properties:
ReservedData Used to temporarily store calculated values.

AssignmentActualFinish The actual finish date of the assignment.
AssignmentActualStart The actual start date of the assignment.

AssignmentIsOverAllocated Indicates whether a resource is assigned to more work on a

specific task than can be done within the resource's normal
working capacity.
AssignmentWorkContour The work contour of the assignment. Values are: 0=Flat,

1=Back Loaded, 2=Front Loaded, 3=Double Peak, 4=Early
Peak, 5=Late Peak, 6=Bell, 7=Turtle, 8=Contoured.
AssignmentStartVariance The variance of the assignment start date from the baseline
start date.
AssignmentFinishVariance The variance of the assignment finish date from the baseline
finish date.
AssignmentUpdateNeeded Indicates whether a TeamUpdate message should be sent to

the resource assigned to a task because of changes to the
start date, finish date, or resource reassignments.
AssignmentHasLinkedFields Indicates that the assignment has linked fields.
AssignmentIsConfirmed Indicates whether a resource assigned to a task has accepted

or rejected the task assignment.
AssignmentResponsePending Indicates whether an answer has been received from a

message sent to a resource assigned to a task notifying the
resource of the assignment.
AssignmentHasNotes There are notes about the assignment.
AssignmentTeamStatusPending Indicates whether a status message has been received in

response to a TeamStatus message sent to a resource
assigned to a task.
ResourceId Unique identifier of the resource.
AssignmentStartDate The date and time that an assigned resource is scheduled to

begin working on a task.
AssignmentFinishDate The date and time that an assigned resource is scheduled to

stop working on a task.
AssignmentDelay The amount of time a resource is to wait after the task start
date before starting work on an assignment.
AssignmentDelayFMT The format for expressing the duration of the delay. Values
are: 3=m, 4=em, 5=h, 6=eh, 7=d, 8=ed, 9=w, 10=ew,
11=mo, 12=emo, 19=%, 20=e%, 21=null, 35=m, 36=em,
37=h, 38=eh, 39=d, 40=ed, 41=w, 42=ew, 43=mo, 44=emo,
51=%, 52=e% and 53=null.
AssignmentLevelingDelay The amount of time that an assignment is to be delayed from

the scheduled start date as a result of resource leveling.
AssignmentCostRateTable Indicates which cost rate table to use for a resource on an

assignment.
AssignmentMaterialRateFMT Indicates the units in which the bid is expressed in the project.
AssignmentUnits The number of units for which a resource is assigned to a

task, expressed as a percentage.
AssignmentWork The total amount of work scheduled to be performed by a

resource on a task.
AssignmentActualWork The amount of work that has already been done by a

resource on a task.
AssignmentRegularWork The total amount of non-overtime work scheduled to be

performed by a resource assigned to a task.
AssignmentRemainingWork The amount of time required by a resource assigned to a task

to complete an assignment.
AssignmentCost The total scheduled (or projected) cost for an assignment.
AssignmentActualCost The cost incurred for work already performed by a resource

on a task.
AssignmentRemainingCost The costs associated with completing all remaining scheduled

work by any resources on a specific task.
AssignmentOvertimeWork The amount of overtime to be performed by a resource on a

task; charged at the resource's overtime rate.
AssignmentActualOvertimeWork The actual amount of overtime work already performed by a

resource on an assigned task.
AssignmentRemainingOvertimeWork The amount of overtime work that remains on an

assignment.
AssignmentActualOvertimeCost The cost incurred for overtime work already performed by a

resource on a task.
AssignmentRTFNotes Notes that are associated with the specified assignment, and
that are stored in Rich Text Format.
AssignmentRemainingOvertimeCost The remaining scheduled overtime expense for an

assignment.
AssignmentBookingType Specifies the booking type of the assignment (committed or
proposed).
AssignmentTDModeDate Internal property describing last modified date on timephased

data.
AssignmentTDModCounter Internal property describing number of revisions.
AssignmentOvertimeCost The total overtime cost for a resource assignment.
AssignmentStopDate The date the assignment was stopped.
AssignmentResumeDate The date the assignment was resumed.
CreatedDate The date that the assignment was created.
ModDate The date that the assignment was last updated.
CreatedRevCounter Internal property describing number of revisions.
ModRevCounter Internal property describing number of revisions.
A ResourcePlanAssignments object can have a collection of Assignments. Each Assignments object may
contain the following properties:
ResourceUID Unique identifier for the resource for the assignment.
ProjectId Unique identifier for the project for the assignment.
MDProjectUID Internal user only.
CustomFieldName Name of the resource.
CustomFieldValue Values for the custom field.
CreationDate Date the custom field was created.
ModDate Date the custom field was last updated.
ResourceName Name of the resource for the assignment.
Start Date and time the assignment work began.
End Date and time the assignment work ended.

Work The total amount of work scheduled to be performed by a
resource on a task.
Rules
Rules contains data about approval rules defined by status manager to approve certain task updates. Each
RulesData object can have the following properties:
RuleUid Unique identifier for the rule.
RuleManagerUid Unique identifier for the Status Manager Owner of the rule.
RuleManagerName The name of the Status Manager Owner.
RuleName Name of the rule.
IsAutomatic True if status updates are automatically approved if they meet

criteria defined in this rule, false otherwise.
AutoPublish True if projects are published after the updates are

automatically applied.
RuleTypeNewTaskAndAssignments True if this rule is applying to updates of type new task or

new assignments, false otherwise.
RuleTypeDelegations True if this this rule is applying to updates of type

Delegation(Reassign), false otherwise.
RuleTypeUpdateTasks True if this rule is applying to updates made to the task

assignments, false otherwise.
RuleTypeDeletes True if this rule is applying to updates of type delete

assignment, false otherwise.
RuleConditionType If extra filtering is done in this rule this filed will have one of
the values: None, Compare with fix string, or Compare with
Database Column.
Field1 The left side of the filter
Field2 The right side of the filter
Operator Operator (can be Equal, Not Equal, Less Than, Greater Than,
Less Than or Equal, Greater Than, or Equal).
ValueType Type of right side of the filter (can be string, int, double, date,
bool).
IntValue Value to compare with if ValueType is Int .

DateValue Value to compare with if ValueType is Date .
DecimalValue Value to compare with if ValueType is Decimal .
StringValue Value to compare with if ValueType is String .
IncludesAllProjects True if this rule applies to updates made in all projects, false
otherwise.
IncludesAllResources True if this rule applies to updates made by all resources, false
otherwise.
IncludesAllDelegatee True if this rule applies to updates of type delegation

regardless of delegatee, false otherwise.
RuleDescription Description for the rule.
CreatedDate Date the rule was created.
ModifiedDate Date the rule was last updated.
RuleDetailsData Object with details about projects/resources this rule will

applied for. This object will be populated with data only if
IncludesAllProjects or IncludesAllResources or
IncludesAllDelegatee is false.
Each RulesDetailsData object will have the following properties:
RuleUid Unique identifier for the rule.
RuleListItemUid Unique identifier for project/resource/delagatee.
RuleListItemType Type of the item, can be project, resource or delegate.
RuleListItemName RuleListItemName Name of the item (can be name of the

project/ resource/delegatee depending on the
ruleListItemType).
CreatedDate Date the rule was created.
ModDate Date the rule was last updated.
Security
Security provides security data about your user. It will only include data about your user if the PWA site is using
Project Server permissions mode.
It includes:
SecurityData: Account information about the user.
GroupData: Project security groups in that the user was associated with.
CategoryData: Security categories that the user was associated with.
PermissionData: Global permission settings for your user.
A ResourceData object may have the following properties:
Properties Description
EncodedClaim Claims account of the resource.
ResourceUID Unique identifier of resource.
GroupData Security group objects data.
CategoryData Security category objects data.
Under ResourceData, a GroupData object may have the following properties:
GroupUID Unique identifier of the security group.
GroupName Name of the security group.
GroupDecription Description of the security group.
Under ResourceData, a CategoryData object may have the following properties:
CategoryUID Unique identifier of the category.
CategoryName Name of the category.
CategoryDescription Description of the category.
Under ResourceData, a ParentPermissionData object may have the following properties:

PermissionUID Unique identifier of the parent permission.
PermissionName Name of the parent permission.
PermissionData Permission objects under the parent permission.
Under ParentPermissionData, a PermissionData object may have the following properties:
PermissionUID Unique identifier of the permission.
PermissionParentUID Internal unique identifier of the parent permission name.
AllowOption If True, Allow was selected for permission for the user.
DenyOption If True, Deny was selected for permission for the user.
PermissionName Name of the permission.
StatusReports
StatusReports contains data about status reports that the user created or received as a status report manager. For
each StatusReports object, you will see the following properties:
PROPERTIES DESCRIPTION
StatusReportId Unique identifier of the status report.
StatusReportName Name of the status report.
ManagerId Unique identifier of the status report manager.
ManagerName Name of the status report manager.
IsEnabled Indicates whether it's a active or archived status report.
IsRequested Indicates whether it's a Requested or Misc status report.
Sections Sections of the status report.
CreatedDate Date the status report was created.
ModifiedDate Date the status report was last updated.
Each StatusReportRequests object may have the following properties:

RequesterId Unique identifier of the requestor.
RequesterName Name of the requestor.
DueDate Date when the status report is due
IsNewRequest Indicates whether it's a active or archived status report.
IsEnabled Indicates whether it's a Requested or Misc status report.
CreatedDate Date and time when the request was created.
ModifiedDate Date and time when the request was last updated.
Each StatusReportResponses object may have the following properties:
ResponseId Unique identifier of the response.
ResponderId Unique identifier of the responder.
ResponderName Name of the responder.
ResponsePeriodStartDate Start date of the response period.
ResponsePeriodFinishDate End date of the response period.
ResponseSubmittedStatus The status of the submitted response.
ResponseSubmittedDate Date the response was submitted.
ResponseSectionsCount The number of sections included in the status response.
IsMatchingResponse True if the response matches the status report period.
IsNewResponse True if the response is new versus updated.
ResponseSendId Identifier of the status report response.
CreatedDate Date and time when the response was created.
ModifiedDate Date and time when the response was last updated.
Each StatusReportSections object may have the following properties:

SectionId Unique identifier of the section.
SectionText Actual text of a status report section.
SectionIndex Identifier of the status report section.
SectionName Name of the section.
SectionDescription Description of the section.
CreatedDate Date the section was created.
ModifiedDate Date the section was last updated.
Each StatusReportFrequencies object may have the following properties:
FrequencyType Indicates the status report is due by week,month, or year.
FrequencyPart1 Due weeks for the status report.
FrequencyPart2 Due days or day of the month, or day of the week, or week of
the month for the status report.
FrequencyPart3 Due month or day of the week for the status report.
FrequencyPart4 Due week of the month for the status report.
FrequencyPart5 Due day of the week for the status report.
FrequencyPart6 Due month of the status report.
FrequencyYearlyDate Date of yearly frequency for the status report.
CreatedDate Date the frequency was created.
ModifiedDate Date the frequency was last updated.
Each StatusReportDistribution object may have the following properties:

ResponderId Unique identifier of the responder.
ResponderName Name of the responder.
CreatedDate Date the distribution was created.
ModifiedDate Date the distribution was last updated.
Each WorkDetails object may have the following properties:
StartDate Start date of the status report.
CreatedDate Date and time when the request was created.
ModifiedDate Date and time when the request was last updated.
DueWeek Indicates the Due week number of the status report.
DueDays Due date of the status report.
SubscribedReminders
SubscribedReminders contains data about reminders subscribed to by the user. For each
SubscribedReminderData object, you will see the following properties:
Id The unique identifier of the reminder.
ReminderName The name of the reminder.
RecipientType Can be either: OnlyToManager, OnlyToTeamMember, or

ToBothManagerAndTeamMember.
FrequencyPeriod Can be: Daily, Weekly, or Monthly.
FrequencyValue The value of the frequency to send the reminder, combined

with the frequency period. For example, the value is "2" and
the FrequencyPeriod is "Monthly", so the reminder will be
sent every 2 months.
NextRun The time the next reminder will be sent.

TaskStatus_AssignmentsHistory
TaskStatus_AssignmentsHistory contains data about status updates where user is the submitter, assignment
owner, status manager or delagatee. Each Transactions object, you may see the following properties:
TransactionUid Unique identifier of the transaction.
State State of the transaction.
UpdateType Type of update: new assignment, status update, delete

assignment, reassignment, or new task.
ApprovalType The action taken by the status manager regarding the status
update: Approve or Reject.
ErrorStatus In case the status update couldn't be applied to the plan this
will tell you the error encountered.
DelegateeUid Unique identifier of the delegatee.
DelegateeName Name of the delegatee.
SubmitterUid Unique identifier of the submitter.
SubmitterName Name of the submitter.
ApproverUid Unique identifier of the approver.
ApproverName Name of the approver.
UpdateDate Date the status update last modified by the submitter or

approver.
SubmittedDate When this status update was submitted.
CreatedDate Creation date for the status update.
ModifiedDate Last modified date for the status update.
AssignmentUid Unique identifier of the assignment.
StatusAssignmentTaskUid Unique identifier of the status assignment task.
ProjectUid Unique identifier of the project.
TaskUid Unique identifier of the task.
TaskName Name of the task.

Changes The object containing the changes made by the submitter in

the status update.
Each Changes object may have the following properties:
EntityUid Task UID or Assignment UID depending if the change was

made for the task or for the assignment.
PropertyName Name of the property that was changed.
PeriodStart The start of the period.
PeriodEnd The end of the period.
Value Value the property was changed to.
Each TransactionsComments object may have the following properties:
CommentUid Unique identifier of the comment.
CommentType Type of comment (Submitted or Approved).
AuthorUid Unique identifier of the comment author.
AuthorName Name of the comment author.
Comment Comment details.
DateEntered Date and time the comment was created.
CommentCreatedDate Date and time the comment was created.
CommentModifiedDate Date and time the comment was last updated.
TaskStatus_AssignmentsSaved
TaskStatus_AssignmentsSaved contains data about status reports that the user created or received as a status
report manager. This file will contain a collection of Tasks objects, which may have the following properties:

TaskPublishedUid Name of the status report.
ProjectUid Unique identifier of the project in which the task exists.
ProjectName Name of the project in which the task exists.
TaskParentUid Unique identifier of the parent task.
TaskACWP The actual cost of work performed on the task to date.
TaskBCWP The budgeted cost of work performed on the task to date.
TaskBCWS The budgeted cost of work scheduled for the task.
TaskDurationVariance The difference between the baseline duration of a task and

the total duration.
TaskFinishVariance The variance of the task finish date from the baseline finish
date as minutes x 1000.
TaskOutlineNumber The outline number of the task.
TaskStartVariance The difference between the baseline start and the actual start.
TaskIsOverallocated True if the task is overallocated.
TaskOvertimeWork The amount of overtime work scheduled for the task
TaskVAC The task variance at completion of the task.
TaskRegularWork The amount of time scheduled for a task that is charged at

the resource's standard rate.
TaskTotalSlack The amount of total slack.
TaskHasLinkedFields True if the task has linked fields.
TaskIsMilestone True if the task is a milestone.
TaskIsCritical True if the task is in the critical chain.
TaskIsSummary True if the task is a summary task.
TaskIsSubproject True if the task is an inserted project.
TaskIsMarked Indicates whether a task is marked for further action or

identification of some kind.
TaskIgnoresResourceCalendar True if the task ignores the resource calendar.

TaskIsRolledUp True if the task is rolled up
TaskIsSubprojectScheduledFromFinish Gets a value that indicates whether a subproject for this task
is set to schedule from finish.
TaskBarIsHidden True if the GANTT bar of the task is hidden when displayed in
Microsoft Office Project.
TaskIsRecurring True if the task is recurring.
TaskIsRecurringSummary True if the task is a recurring summary task.
TaskIsExternal True if the task is external.
TaskIsEffortDriven True if the task is effort driven.
TaskIsCollapsed True if task is displayed collapsed in Project client.
TaskHasNotes True if text notes are associated with the task.
TaskIsSubprojectReadOnly Gets a value that indicates whether a subproject for this task
is read-only.
TaskLevelingCanSplit True if leveling can split the task.
TaskCanSplit Indicates whether the resource leveling function can cause

splits on remaining work on this task. If this field is set to Yes,
then leveling can interrupt this task. If this field is set to No,
leveling cannot split the task.
TaskDurationIsEstimated Indicates whether the task's duration is flagged as an

estimate.
TaskEarlyFinish The early finish date of the task.
TaskLateStart The late start date of the task.
TaskStopDate The date that the task was stopped.
TaskFreeSlack The amount of free slack.
TaskResumeDate The date that the task was resumed.
TaskCompletedDate The date argument for the task constraint type.
TaskOutlineLevel The outline level of the task.
TaskScheduledDuration The scheduled duration of the task.
TaskScheduledDurationFormat Gets the total span of active working time for the task as
entered or as calculated based on the start date, the finish
date, calendars, and other scheduling factors.
TaskActualDuration The actual duration of the task.
TaskRemainingDuration The amount of time required to complete the unfinished

portion of the task.
TaskConstraintType The constraint on the start or finish date of the task. Values
are: 0=As Soon As Possible, 1=As Late As Possible, 2=Must
Start On, 3=Must Finish On, 4=Start No Earlier Than, 5=Start
No Later Than, 6=Finish No Earlier Than and 7=Finish No
Later Than.
TaskLevelingDelay The delay caused by leveling the task.
TaskLevelingDelayFormat The format for expressing the duration of the delay. Values
11=mo, 12=emo, 19=%, 20=e%, 21=null, 35=m, 36=em,
37=h, 38=eh, 39=d, 40=ed, 41=w, 42=ew, 43=mo, 44=emo,
51=%, 52=e% and 53=null.
TaskScheduledStart The scheduled start date of the task.
TaskScheduledFinish The scheduled finish date of the task.
TaskActualStart The actual start date of the task.
TaskActualFinish The actual finish date of the task.
TaskConstraintDate The date associated with the constraint type.
TaskPriority The priority of the task from 0 to 1000.
TaskPercentComplete The percentage of the task duration completed.
TaskWorkPercentComplete The percentage of the task work completed.
TaskType The type of task. Values are: 0=Fixed Units, 1=Fixed Duration,
2=Fixed Work.
TaskFixedCostAccrual How the fixed cost is accrued against the task. Values are:
1=Start, 2=Prorated and 3=End.
TaskPreleveledStart Contains the start date of a task as it was before resource

leveling was done.
TaskPreleveledFinish Contains the end date of a task as it was before resource

leveling was done.
TaskEarlyStart The early start date of the task.
TaskLateFinish The late finish date of the task.
TaskCalendarUid The unique identifier of the calendar associated with a task.

TaskDeadline The final desired point in a task's time length that the task
must be completed by.
TaskWork The amount of scheduled work for the task.
TaskActualWork The actual work for the task.
TaskRemainingWork The remaining work scheduled to complete the task
TaskCost The projected or scheduled cost of the task.
TaskFixedCost The fixed cost of the task.
TaskActualCost The actual cost of the task.
TaskRemainingCost The remaining projected cost of completing the task.
TaskActualOvertimeWork The actual overtime work for the task.
TaskRemainingOvertimeWork The remaining overtime work scheduled to finish the task.
TaskOvertimeCost The sum of the actual and remaining overtime cost of the
task.
TaskActualOvertimeCost The actual overtime cost of the task.
TaskRemainingOvertimeCost The remaining overtime cost projected to finish the task.
TaskWBS The work breakdown structure (WBS) code of the task.
TaskName The name of the task.
TaskHierarchy The hierarchy of the task.
TaskRightMostLevel Used in leveling.
TaskRTFNotes Notes that are associated with the specified task, and that are
stored in Rich Text Format.
TaskPhysicalPercentCompleted The percentage complete value entered by the Project

Manager.
TaskEAC The EAC (estimate at completion) field shows theexpected

total cost of a task based on performance up to the status
date. EAC is also called forecast at completion (FAC).
TaskEarnedValueMethod The method for calculating earned value. Values are:

0=Percent Complete, 1=Physical Percent Complete.
TaskTDModifyDate Last datetime when task's timephased data was modified.

TaskOptIndex Gets the Item ID of the task in the task list.
TaskIsNull Specifies whether the task has no values set.
TaskIsDeletedInProject Indicates if the task was deleted from the project.
TaskCostIsValid Gets or sets a Boolean value that indicates whether the

current field is the associated cost for the task.
TaskDeletedFlag Indicates if the task was deleted.
TaskUpdatesConflict True if the Project Manager updated this task and the
updates might conflict with updates made by a team member.
TASK_IS_ROLLUP_ASSN Indicates whether the task has rollup data for the assignment.
TASK_LOCKDOWN_BY_MANAGER True if this task will not accept updates from team members.
TASK_EXT_TASK_UID Specifies cross project tasks links.
TASK_EXT_PROJ_UID Specifies cross project links.
TaskContact Contact information for the task.
TaskCPI The CPI (cost performance index) fields show the ratio of
budgeted (or baseline) costs of work performed to actual
costs of work performed.
TaskCV Task cost variance.
TaskHyperLinkFriendlyName Shows the title or explanatory text for a hyperlink associated

with a task.
TaskHyperLinkAddress The URL or UNC path of a document.
TaskHyperLinkSubAddress Contains the specific location in a document within a

hyperlink associated with a task.
TaskNotes Notes for the task.
TaskSPI Often used to estimate the project completion date.
TaskSV The cost difference between the current progress and the
baseline plan of a task.
TaskTCPI The TCPI (to complete performance index) field shows the
ratio of the work remaining to be done to funds remaining to
be spent, as of the status date.
TaskWorkVariance The variance of task work from the baseline task work as
minutes x 1000.
TaskCostVariance Gets the difference in cost terms between the current

progress and the baseline planned progress for a resource on
the task.
TaskFinishSlack Amount of finish slack.
TaskBudgetWork The scheduled work for a task.
TaskBudgetCost Gets the budget costs for budget cost resources.
TaskWinprojUniqueId Indicates the unique identifier for the task used in Project
client.
TaskStartSlack Amount of start slack.
TaskCommitmentType Specifies whether the task has an associated deliverable or a

dependency on an associated deliverable. Values are: 0=The
task has no deliverable or dependency on a deliverable,
1=The task has an associated deliverable, 2=The task has a
dependency on an associated deliverable.
TaskCommitmentUid Unique identifier for the commitment.
TaskCommitmentStart Start date for the commitment.
TaskCommitmentFinish End date for the commitment.
TaskIsActive True if the task is active.
TaskDispSumary The value of the property should be false. Reserved for future
use.
TaskIsManual True if the task is manual.
TaskDuration The planned duration of the task
TaskDurationFormat The format for expressing the duration of the task. Values are:
3=m, 4=em, 5=h, 6=eh, 7=d, 8=ed, 9=w, 10=ew, 11=mo,
12=emo, 19=%, 20=e%, 21=null, 35=m, 36=em, 37=h,
38=eh, 39=d, 40=ed, 41=w, 42=ew, 43=mo, 44=emo,
51=%, 52=e% and 53=null.
TaskStartDate The scheduled start date of the task.
TaskFinishDate The scheduled finish date of the task.
TaskDurationString String used for task duration.
TaskStartString String used for task finish.
TaskFinishString String used for task start.

TaskCreatedDate Date the task was created.
TaskModifiedDate The date the task was last updated.
Assignments The collection of assignments that make up the project.
Each Tasks object may have a collection of Assignments objects, which may have the following properties:
Object Description
AssignmentUID Unique identifier of the assignment.
TaskUID Unique identifier of the task for the

assignment.
TaskName Name of the task for the assignment.
ProjectUid Unique identifier of the project for the

the task.
ResourceUid Unique identifier of the resource

assigned to the assignment.
ResourceName Name of the resource assigned to the

assignment.
AssignmentActualFinish The actual finish date of the

assignment.
AssignmentActualCostOfWorkPerforme Gets the actual cost of work performed

d (ACWP) for the assignment to date.
AssignmentEarnedValue Specifies the assignment's budgeted

cost of work performed (BCWP).
AssignmentBCWS The budgeted cost of work on the

assignment.
AssignmentResourceType The type of resource that is associated

with an assignment. See Type
enumeration.
AssignmentIsOverallocated Whether the assignment is

overallocated.
AssignmentWorkContour The work contour of the assignment.

Values are: 0=Flat, 1=Back Loaded,
2=Front Loaded, 3=Double Peak,
4=Early Peak, 5=Late Peak, 6=Bell,
7=Turtle, 8=Contoured.
AssignmentStartVariance The variance of the assignment start
date from the baseline start date.
AssignmentFinishVariance The variance of the assignment finish

date from the baseline finish date.
AssignmentUpdateNeeded True if the resource assigned to a task

needs to be updated as to the status of
the task.
AssignmentHasLinkedFields Whether the project is linked to

another OLE object.
AssignmentIsPendingResponse True if a response has not been

received for a TeamAssign message.
AssignmentHasNotes Has text notes associated with the

assignment.
AssignmentTeamStatusPending Indicates whether a status message has

been received in response to a
TeamStatus message sent to a resource
assigned to a task.
AssignmentsStartDate The scheduled start date of the

assignment.
AssignmentFinishDate The scheduled finish date of the

assignment.
AssignmentDelay The amount that the assignment is

delayed
AssignmentDelayFormat The format for expressing the duration

of the delay. Values are: 3=m, 4=em,
5=h, 6=eh, 7=d, 8=ed, 9=w, 10=ew,
11=mo, 12=emo, 19=%, 20=e%,
21=null, 35=m, 36=em, 37=h, 38=eh,
39=d, 40=ed, 41=w, 42=ew, 43=mo,
44=emo, 51=%, 52=e% and 53=null.
AssignmentLevelingDelay The delay caused by leveling.
AssignmentCostRateTable The cost rate table used for the

assignment.
AssignmentMaterialRateFormat Indicates the units in which the bid is

expressed in the project.
AssignmentUnits The number of units for the

assignment.
AssignmentWork The amount of scheduled work for the

assignment.
AssignmentActualWork The actual amount of work incurred on
the assignment.
AssignmentRegularWork The amount of non-overtime work

scheduled for the assignment.
AssignmentRemainingWork The remaining work scheduled to

complete the assignment.
AssignmentCost The projected or scheduled cost of the

assignment.
AssignmentActualCost The actual cost incurred on the

assignment.
AssignmentRemainingCost The remaining projected cost of

completing the assignment.
AssignmentOvertimeWork The scheduled overtime work for the

assignment.
AssignmentActualOvertimeWork The actual amount of overtime work

incurred on the assignment.
AssignmentRemainingOvertimeWork The remaining overtime work

scheduled to complete the assignment.
AssignmentOvertimeCost The sum of the actual and remaining

overtime cost of the assignment.
AssignmentRemainingOvertimeCost The remaining projected overtime cost

of completing the assignment.
AssignmentRTFNotes Represents notes that are associated

with the specified assignment, and that
are stored in Rich Text Format.
AssignmentBookingType Specifies the booking type of the

assignment. 1=Commited,
2=Proposed.
AssignmentParentId Unique identifier of the primary

assignment.
AssignmentRemovedByResource True if team member removed this

resource.
StatusManagerUid Unique identifier for the status

manager.
StatusManagerName Name of the status manager.
DefaultAssignmentOwnerUid Unique identifier for the default

assignment owner.
DefaultAssignmentOwnerName Name of the default assignment owner.
AssignmentLastWork The scheduled work from the last

update from Project.
AssignmentsComments The user's comments about the

assignment.
AssignmentNoteStatus Indicates whether a note has been

entered for the assignment.
TaskIsSummary Specifies whether the task is a

summary task.
AssignmentIsConfirmed Whether the Resource has accepted all

of his or her assignments.
AssignmentUpdatedByManager True if the assignment was updated by

Project Manager.
AssignmentLockeByManager True if this assignment doesn't accept

update from team member anymore.
AssignmentCreatedByResourceId Resource ID of the assignment creator.
CreatorName Name of the assignment creator.
AssignmentCurrentTrackingMode Indicates the current method used to

track projects.
0 - None (default)
1 - Timephased actuals
2 - Percent complete tracking
3 - Total actual work and remaining
work tracking
AssignmentUpdatedTrackingMode Indicates the updated method used to

track projects:
0 - None (default)
3 - Total actual work and remaining
work tracking
AssignmentNeedUpdatesSubmitted True if there are saved update from

team members for assignment.
AssignmentDeletedInProject True if assignment was deleted from

project.
AssignmentUpdatesByResource True if the assignment was updated by

team member.
AssignmentRequestsUpdates Indicates whether a team resource has

submitted actuals.
AssignmentUpdatesAccepted True is status updates made for
assignment where accepted.
AssignmentActualsPending True if accepted updates are pending to

be applied to the plan.
AssignmentIsDelegated True if assignment was created by a

reassign operation.
AssignmentIsNew True if assignment is newly created for

team member.
AssignmentUpdateStatus Indicates the status of an assignment.

0 - Not edited by resource.
1 - Edited by resource but not updated
to the project manager yet.
AssignmentPercentWorkCompleted The amount of work completed on the

assignment.
AssignmentAssignedToExisting Indicates whether a new assignment

has been created by a resource using
the assign self to task feature.
AssignmentTDModifyDate Last modified date for assignment

timephased data
AssignmentResumeDate The date that the assignment resumed.
AssignmentStopDate The date that the assignment was

stopped.
AssignmentIsPublished True if assignment was published.
AssignmentDemandRequire Indicates how to assign resources when

using the resource substitution wizard.
AssignmentIsCostValid Indicates whether or not the cost

associated with the assignment has
been approved.
AssignmentCostIsEdited Indicates if the cost associated with this

assignment was edited.
AssignmentOtherType Indicates the type of assignment:

0 - Regular
1 - TaskOnlyWork
2 - FixedCosts
3 - FixedCostsAndTaskOnly
4 - RegularUnassigned
AssignmentUpdatesConflict True if there are conflicting updates for

assignment
DeletedFlag Indicates if the assignment was deleted.

AssignmentVAC The difference between baseline cost
and total cost.
AssignmentSV Earned value schedule variance,

through the project status date.
AssignmentWorkVariance The variance of assignment work from

the baseline work as minutes x 1000.
AssignmentCostVariance The difference between the cost and

baseline cost for a resource.
AssignmentBudgetWork The budgeted work amount for work or

material resources on this assignment.
AssignmentBudgetCost The budgeted amount for cost

resources on this assignment.
AssignmentTaskManagementFlags Internal use only.
AssignmentIgnoreResourceCalendar Indicates whether the resource calendar

intersects with the task calendar.
AssignmentWinProjUniqueId Indicates a unique identifier for the

assignment used in Project client.
AssignmentRemovedFromTS Indicates if the assignment was

removed from the timesheet.
AssignmentCreatedDate The date that the assignment was

created.
AssignmentModifiedDate The date that the assignment was last

updated.
AssignmentSendUpdatesDate The date and time that an assignment

update was sent by the resource to a
manager.
AssignmentSummaryProgress Shows progress on a summary task

based on progress on its subtasks and
where these subtasks have been
scheduled.
TeamLeadUid Unique identifier for the team lead.
TeamLeadName Name of the team lead.
ReservedData1 Used to temporarily store calculated

values.

values.
values.
AssignmentHyperlinkFriendlyName The title or explanatory text for a

hyperlink associated with an
assignment.
AssignmentHyperlinkAddress The URL or UNC path of a document.
AssignmentHyperlinkSubAddress The specific location in a document

within a hyperlink associated with a
assignment.
AssignmentNotes The notes that are entered in the

assignment details dialog box.
AssignmentVAC The difference between baseline cost

and total cost.
Each Assignments object may have a collection of Timephased objects, which may have the following
properties:
AssignmentUID Unique identifier for the assignement.
Date Date the work started.
Work Units of work scheduled for the assignment.
OvertimeWork Units of overtime work scheduled for the assignment.
ActualWork Actual units of work completed for the assignment.
ActualOvertimeWork Actual units of overtime work completed for the assignment.
Each Assignments object may have a collection of CustomFields objects, which may have the following
properties:
AssignmentUid Unique identifier for the assignment.
Type Type of the custom field (can be number, text, cost, duration,
date, fals, finish date, start date, etc.).

DurationFormat Specifies the display format for the value if type is "duration".
LookupTableUid Unique identifier for the lookup table.
IndicatorValue Specifies the value of the custom field if the type of custom
field is "indicator".
TaskStatus_AssignmentsSubmitted
TaskStatus_AssignmentsSubmitted contains data about status reports that the user. This file will contain a
collection of Tasks objects, which may have the following properties:
TaskPublishedUid Name of the status report.
ProjectUid Unique identifier of the project in which the task exists.
ProjectName Name of the project in which the task exists.
TaskParentUid Unique identifier of the parent task.
TaskDurationVariance Difference between the baseline duration and the total

duration (current estimate) of a task.
TaskStartVariance Task start variance is the difference between a baseline start

date and the currently scheduled start date.
TaskIsOverallocated True if the task is overallocated.
TaskOvertimeWork The amount of overtime work scheduled for the task
TaskVAC Variance at completion.
TaskRegularWork Total amount of non-overtime work scheduled for a task.

TaskHasLinkedFields True if the task has linked fields.
TaskIsMilestone True if the task is a milestone.
TaskIsCritical True if the task is in the critical chain.
TaskIsSummary True if the task is a summary task.
TaskIsSubproject True if the task is an inserted project.
TaskIsMarked Indicates whether a task is marked for further action or

identification of some kind.
TaskIgnoresResourceCalendar True if the task ignores the resource calendar.
TaskIsRolledUp True if the task is rolled up
TaskIsSubprojectScheduledFromFinish Gets a value that indicates whether a subproject for this task
is set to schedule from finish.
TaskBarIsHidden True if the GANTT bar of the task is hidden when displayed in
Microsoft Office Project.
TaskIsRecurring True if the task is recurring.
TaskIsRecurringSummary True if the task is a recurring summary task.
TaskIsExternal True if the task is external.
TaskIsEffortDriven True if the task is effort driven.
TaskIsCollapsed True if task is displayed collapsed in Project client.
TaskHasNotes True if text notes are associated with the task.
TaskIsSubprojectReadOnly Gets a value that indicates whether a subproject for this task
is read-only.
TaskLevelingCanSplit True if leveling can split the task.
TaskCanSplit Indicates whether the resource leveling function can cause

splits on remaining work on this task. If this field is set to Yes,
then leveling can interrupt this task. If this field is set to No,
leveling cannot split the task .
TaskDurationIsEstimated Indicates whether the task's duration is flagged as an

estimate.

TaskStopDate The date that the task was stopped.
TaskResumeDate The date that the task was resumed.
TaskCompletedDate The date argument for the task constraint type.
TaskScheduledDuration The scheduled duration of the task.
TaskScheduledDurationFormat Gets the total span of active working time for the task as
entered or as calculated based on the start date, the finish
date, calendars, and other scheduling factors.
TaskRemainingDuration The amount of time required to complete the unfinished

portion of the task.
TaskConstraintType The constraint on the start or finish date of the task. Values
are: 0=As Soon As Possible, 1=As Late As Possible, 2=Must
Start On, 3=Must Finish On, 4=Start No Earlier Than, 5=Start
No Later Than, 6=Finish No Earlier Than and 7=Finish No
Later Than.
TaskLevelingDelayFormat The format for expressing the duration of the delay. Values
11=mo, 12=emo, 19=%, 20=e%, 21=null, 35=m, 36=em,
37=h, 38=eh, 39=d, 40=ed, 41=w, 42=ew, 43=mo, 44=emo,
51=%, 52=e% and 53=null.
TaskScheduledStart The scheduled start date of the task.
TaskScheduledFinish The scheduled finish date of the task.
TaskActualStart The actual start date of the task.
TaskActualFinish The actual finish date of the task.
TaskConstraintDate The date associated with the constraint type.
TaskPercentComplete The percentage of the task duration completed.
TaskWorkPercentComplete The percentage of the task work completed.

TaskType The type of task. Values are: 0=Fixed Units, 1=Fixed Duration,
2=Fixed Work.
TaskFixedCostAccrual How the fixed cost is accrued against the task. Values are:
1=Start, 2=Prorated and 3=End.
TaskPreleveledStart Contains the start date of a task as it was before resource

leveling was done.
TaskPreleveledFinish Contains the end date of a task as it was before resource

leveling was done.
TaskCalendarUid The unique identifier of the calendar associated with a task.
TaskDeadline The final desired point in a task's time length that the task
must be completed by.
TaskRemainingWork The remaining work scheduled to complete the task
TaskRemainingCost The remaining projected cost of completing the task.
TaskRemainingOvertimeWork The remaining overtime work scheduled to finish the task.
task.
TaskRemainifOvertimeCost The remaining overtime cost projected to finish the task.
TaskName The name of the task.
TaskHierarchy The hierarchy of the task.

TaskRightMostLevel Used in leveling.
TaskRTFNotes Notes that are associated with the specified task, and that are
stored in Rich Text Format.

Manager.
TaskEAC Shows the expected total cost of a task based on performance

up to the status date. EAC is also called forecast at
completion (FAC).
TaskEarnedValueMethod The method for calculating earned value. Values are:

0=Percent Complete, 1=Physical Percent Complete.
TaskTDModifyDate Last datetime when task's timephased data was modified.
TaskTDModifyCounter Counter for modifying timephased data.
TaskStartOffset Offset for the task start.
TaskReservedData Used to temporarily store calculated values.
TaskOptIndex Gets the Item ID of the task in the task list.
TaskSummaryProgressDate Internal user only.
TaskIsNull Specifies whether the task has no values set.
TaskIsDeletedInProject Indicates if the task was deleted from the project.
TaskCostIsValid Gets or sets a Boolean value that indicates whether the

current field is the associated cost for the task.
TaskDeletedFlag Indicates if the task was deleted.
TaskUpdatesConflict True if the ProjectManager updated this task and the updates
might conflict with updates made by a team member.
TASK_IS_ROLLUP_ASSN Indicates whether the task has rollup data for the assignment.
TASK_LOCKDOWN_BY_MANAGER True if this task will not accept updates from team members.
TASK_EXT_TASK_UID Specifies cross project tasks links.
TASK_EXT_PROJ_UID Specifies cross project links.
TaskContact Contact for the task.
TaskCPI The CPI (cost performance index) fields show the ratio of
budgeted (or baseline) costs of work performed to actual
costs of work performed.
TaskCV Task cost variance.

with a task.
TaskHyperLinkAddress The URL or UNC path of a document.
TaskHyperLinkSubAddress Contains the specific location in a document within a

hyperlink associated with a task.
TaskNotes Notes for the task.
TaskSPI SPI is often used to estimate the project completion date.
TaskTCPI The TCPI (to complete performance index) field shows the
ratio of the work remaining to be done to funds remaining to
be spent, as of the status date.
minutes x 1000.

the task.
TaskFinishSlack Amount of finish slack.
TaskBudgetWork The scheduled work.
TaskBudgetCost Gets the budget costs for budget cost resources.
TaskWinprojUniqueId Indicates the unique identifier for the task used in Project
client.
TaskStartSlack Amount of start slack.
TaskCommitmentType Specifies whether the task has an associated deliverable or a

dependency on an associated deliverable. Values are: 0=The
task has no deliverable or dependency on a deliverable,
1=The task has an associated deliverable, 2=The task has a
dependency on an associated deliverable.
TaskCommitmentUid Unique identifier for the commitment.
TaskCommitmentStart Start date for the commitment.
TaskCommitmentFinish End date for the commitment.

TaskDispSumary The value of the property should be false. Reserved for future
use.
TaskIsManual True if the task is manual.
TaskDuration The planned duration of the task
TaskDurationFormat The format for expressing the duration of the task. Values are:
3=m, 4=em, 5=h, 6=eh, 7=d, 8=ed, 9=w, 10=ew, 11=mo,
12=emo, 19=%, 20=e%, 21=null, 35=m, 36=em, 37=h,
38=eh, 39=d, 40=ed, 41=w, 42=ew, 43=mo, 44=emo,
51=%, 52=e% and 53=null.
TaskDurationString String used for task duration.
TaskStartString String used for task finish.
TaskFinishString String used for task start.
TaskCreatedDate The date the task was created.
TaskModifiedDate The date the task was last updated.
Assignments The collection of assignments that make up the project.
Each Tasks object may have a collection of Assignments objects, which may have the following properties:
Object Description
TaskUID Unique identifier of the task for the assignment.
TaskName Name of the task for the assignment.
ProjectUid Unique identifier of the project for the task.
ResourceUid Unique identifier of the resource assigned to the assignment.
ResourceName Name of the resource assigned to the assignment.
ReservedData Used to temporarily store calculated values.
ProjectSummaryAssignmentID Unique identifier of the project summary assignment.
AssignmentActualFinish The actual finish date of the assignment.

AssignmentActualCostOfWorkPerformed Gets the actual cost of work performed (ACWP) for the
assignment to date.
AssignmentEarnedValue Specifies the assignment's budgeted cost of work performed

(BCWP).
AssignmentBCWS The budgeted cost of work on the assignment.

AssignmentIsOverallocated Whether the assignment is overallocated.
AssignmentWorkContour The work contour of the assignment. Values are: 0=Flat,

1=Back Loaded, 2=Front Loaded, 3=Double Peak, 4=Early
Peak, 5=Late Peak, 6=Bell, 7=Turtle, 8=Contoured.
AssignmentStartVariance The variance of the assignment start date from the baseline
start date.
AssignmentFinishVariance The variance of the assignment finish date from the baseline
finish date.
AssignmentUpdateNeeded True if the resource assigned to a task needs to be updated as

to the status of the task.
AssignmentHasLinkedFields Whether the project is linked to another OLE object.
AssignmentIsConfirmed Yes if the value is con
AssignmentIsPendingResponse True if a response has not been received for a TeamAssign

message.
AssignmentHasNotes Has text notes associated with the assignment.
AssignmentTeamStatusPending Indicates whether a status message has been received in

response to a TeamStatus message sent to a resource
assigned to a task.
AssignmentsStartDate The scheduled start date of the assignment.
AssignmentFinishDate The scheduled finish date of the assignment.
AssignmentDelay The amount that the assignment is delayed
AssignmentDelayFormat The format for expressing the duration of the delay. Values
11=mo, 12=emo, 19=%, 20=e%, 21=null, 35=m, 36=em,
37=h, 38=eh, 39=d, 40=ed, 41=w, 42=ew, 43=mo, 44=emo,
51=%, 52=e% and 53=null.
AssignmentLevelingDelay The delay caused by leveling.

AssignmentCostRateTable The cost rate table used for the assignment.
AssignmentMaterialRateFormat Indicates the units in which the bid was expressed in the
project.
AssignmentUnits The number of units for the assignment.
AssignmentWork The amount of scheduled work for the assignment.
AssignmentActualWork The actual amount of work incurred on the assignment.
AssignmentRegularWork The amount of non-overtime work scheduled for the

assignment.
AssignmentRemainingWork The remaining work scheduled to complete the assignment.
AssignmentCost The projected or scheduled cost of the assignment.
AssignmentActualCost The actual cost incurred on the assignment.
AssignmentRemainingCost The remaining projected cost of completing the assignment.
AssignmentOvertimeWork The scheduled overtime work for the assignment.
AssignmentActualOvertimeWork The actual amount of overtime work incurred on the

assignment.
AssignmentRemainingOvertimeWork The remaining overtime work scheduled to complete the

assignment.
AssignmentOvertimeCost The sum of the actual and remaining overtime cost of the
assignment.
AssignmentRemainingOvertimeCost The remaining projected overtime cost of completing the

assignment.
AssignmentRTFNotes Represents notes that are associated with the specified

assignment, and that are stored in Rich Text Format.
AssignmentBookingType Specifies the booking type of the assignment. 1=Commited,

2=Proposed.
AssignmentParentId Unique identifier of the primary assignment.
AssignmentRemovedByResource True if team member removed this resource.
StatusManagerUid Unique identifier for the status manager.
StatusManagerName Name of the status manager.

DefaultAssignmentOwnerUid Unique identifier for the default assignment owner.
DefaultAssignmentOwnerName Name of the default assignment owner.
AssignmentLastWork The scheduled work from the last update from Project.
AssignmentsComments The user's comments about the assignment.
HistoryNotes
AssignmentNoteStatus Indicates whether a note has been entered for the

assignment.
TaskIsSummary Specifies whether the task is a summary task.
AssignmentIsConfirmed Whether the Resource has accepted all of his or her

assignments.
AssignmentUpdatedByManager True if the assignment was updated by Project Manager.
AssignmentLockeByManager True if this assignment doesn't accept update from team

member anymore.
AssignmentCreatedByResourceId Resource ID of the assignment creator.
CreatorName Name of the assignment creator.
AssignmentCurrentTrackingMode Indicates the current method used to track projects:

0 - None (default)
3 - Total actual work and remaining work tracking
AssignmentUpdatedTrackingMode Indicates the updated method used to track projects:

0 - None (default)
3 - Total actual work and remaining work tracking
AssignmentNeedUpdatesSubmitted True if there are saved update from team members for this
assignment.
AssignmentDeletedInProject True if assignment was deleted from project.
AssignmentUpdatesByResource True if the assignment was updated by team member.
AssignmentRequestsUpdates Indicates whether a team resource has submitted actuals.
AssignmentUpdatesAccepted True is status updates made for assignment where accepted.
AssignmentActualsPending True if accepted updates are pending to be applied to the

plan.
AssignmentDeletePending True if delete for assignment is pending to be applied.
AssignmentIsDelegated True if assignment was created by a reassign operation.
AssignmentIsNew True if assignment is newly created for team member.
AssignmentUpdateStatus Indicates the status of an assignment: 0 - Not edited by

resource. 1 - Edited by resource but not updated to the
project manager yet.
AssignmentLastDelegationId The last delegation performed on this assignment.
AssignmentPercentWorkCompleted The amount of work completed on the assignment.
AssignmentSendUpdatesDate The date and time that an assignment update was sent by
the resource to a manager.
AssignmentSummaryProgress Shows progress on a summary task based on progress on its

subtasks and where these subtasks have been scheduled.
TeamLeadUid Unique identifier of the team lead.
TeamLeadName Name of the team lead.
WNWRK_UID Internal use only.
WNWORK_ENTRY_UID Internal use only.
AssignmentAssignedToExisting Indicates whether a new assignment has been created by a

resource using the assign self to task feature.
ReservedData1 Used to temporarily store calculated values.
AssignmentTDModifyDate Last modified date for assignment timephased data.
AssignmentResumeDate The date that the assignment resumed.
AssignmentStopDate The date that the assignment was stopped.
AssignmentDemandRequire Indicates how to assign resources when using the resource

substitution wizard.
AssignmentIsCostValid Indicates whether or not the cost associated with the

assignment has been approved.
AssignmentCostIsEdited Indicates if the cost associated with this assignment was
edited.
AssignmentOtherType Indicates the type of assignment:

0 - Regular
1 - TaskOnlyWork
2 - FixedCosts
3 - FixedCostsAndTaskOnly
4 - RegularUnassigned
AssignmentUpdatesConflict True if there are conflicting updates for assignment
DeletedFlag Indicates if the assignment was deleted.
AssignmentHyperlinkFriendlyName The title or explanatory text for a hyperlink associated with an

assignment.
AssignmentHyperlinkAddress The URL or UNC path of a document.
AssignmentHyperlinkSubAddress The specific location in a document within a hyperlink

associated with a assignment.
AssignmentNotes The notes that are entered in the assignment details dialog
box.
AssignmentVAC The difference between baseline cost and total cost.
AssignmentSV Earned value schedule variance, through the project status

date.
AssignmentWorkVariance The variance of assignment work from the baseline work as

minutes x 1000.
AssignmentCostVariance The difference between the cost and baseline cost for a
resource.
AssignmentBudgetWork The budgeted work amount for work or material resources on

this assignment.
AssignmentBudgetCost The budgeted amount for cost resources on this assignment.
AssignmentTaskManagementFlags Internal use only.
AssignmentIgnoreResourceCalendar Indicates whether the resource calendar intersects with the

task calendar.
AssignmentWinProjUniqueId Indicates a unique identifier for the assignment used in

Project client.
AssignmentRemovedFromTS Indicates if the assignment was removed from the timesheet.
AssignmentCreatedDate The date that the assignment was created.

AssignmentModifiedDate The date that the assignment was last updated.
Each Assignments object may have a collection of CustomFields objects, which may have the following
properties:
AssignmentUid Unique identifier for the assignment.
Type Type of the custom field (can be number, text, cost, duration,
date, fals, finish date, start date, etc.).
DurationFormat Specifies the display format for the value if type is "duration".
LookupTableUid Unique identifier for the lookup table.
IndicatorValue Specifies the value of the custom field if the type of custom
field is "indicator".
Timesheets
Timesheets contains data about timesheets the user owns or is a part of. For each timesheet, you will see the
following objects:
Object Description
TimesheetUID Unique identifier for the timesheet.
TimesheetName Name of the timesheet.
TimesheetOwnerID The unique identifier for the owner of the timesheet.
TimesheetOwner The owner of the timesheet.
StatusID The value associated with the timesheet status (see Status).
Status The status of the timesheet.
PeriodName The name of the timesheet period.
StartDate The start date and time of the timesheet.

EndDate The end date and time for the timesheet.
PeriodUID The unique identifier for the timesheet period.
PeriodStatusID The status identifier of the timesheet period (open, closed, or

all periods).
PeriodStatus The status of the timesheet period.
ModifiedDate The date and time that the timesheet was last modified.
CreatedDate The date and time that the timesheet was created.
A Timesheets object can have a collection of Lines objects, which may have the following properties:
TimesheetLineId Unique identifier for the timesheet line item.
AssignmentUID Unique identifier for the assignment.
LastSavedWork Amount of Actual Work for the timesheet line item.
CreatedDate Time and date of when the line item was created.
ModifiedDate Time and date of when the line item was last modified.
ProjectId Unique identifier of the project.
TimesheetApproverResourceID Name of the Timesheet Approver.
TimesheetApproverResourceName Resource ID of the Timesheet Approver.
TimesheetClassDescription The description of the timesheet class (for example, to

describe its purpose as the recording of sick time or vacation
time).
TimesheetClassId Unique identifier of the timesheet line class.
TimesheetClassName The name of the timesheet line class.

TimesheetClassType The type of the timesheet class (for example, sick time or
vacation time).
TimesheetLineComment The text comment for the timesheet line.
TimesheetLineStatus The status of the timesheet line.
TimesheetLineStatusId Unique identifier for the timesheet line status (see the
corresponding TimesheetLineStatus value).
Each Lines object can have a collection of Actuals objects. Each Actuals object may have the following
properties:
TimesheetLineId Unique identifier for the timesheet line.
ActualOvertimeWorkBillable The actual billable overtime work that has already been
performed by resources assigned to tasks.
ActualOvertimeWorkNonBillable The actual non-billable overtime work that has already been
ActualWorkBillable The actual billable amount of regular, non-overtime work that

has already been performed by resources assigned to tasks.
ActualWorkNonBillable The actual non-billable amount of regular, non-overtime work

that has already been performed by resources assigned to
tasks.
CreatedDate The date and time that the timesheet actual was created.
PlannedWork The estimated amount of work.
StartDate Start date of the period.
EndDate End date of the period.
TimesheetLineModifiedDate Time and date the line was last updated.
A Lines object can have a collection of CustomFields objects, which may have the following properties:
TimeSheetLineID Unique identifier for the timesheet line.

CustomFieldUID Unique identifier for the custom field value.
Timesheets_Reporting
Timesheets_Reporting contains timesheet data for the user from the reporting schema. For each Timesheets
object, you will see the following properties:
TimesheetName Name of the timesheet.
TimesheetOwnerId Unique identifier for the timesheet owner.
TimesheetOwner Name of the timesheet owner.
StatusDescription Status of the timesheet.
PeriodName Name of the period.
StartDate Start date of the period.
EndDate End date of the period.
PeriodUID Unique identifier for the period.
PeriodStatusID Unique identifier for the period status.
PeriodStatus The status of the timesheet period.
ModifiedDate Time and date the timesheet was last modified.
Each Timesheets object can have a collection of Line objects. Each Line object may have the following
properties:



tasks.
LastSavedWork Unique identifier for the workflow stage.
CreatedDate Time and date of when the line item was created.
ModifiedDate Time and date of when the line item was last modified.
ProjectId Unique identifier of the project.
TaskHierarchy The hierarchical list of tasks for a project.
TimesheetApproverResourceId Resource ID of the timesheet approver.
TimesheetApproverResourceName Name of the timesheet approver.
TimesheetClassDescription The description of the timesheet class (for example, to

describe its purpose as the recording of sick time or vacation
time).
TimesheetClassId Unique identifier of the timesheet class.
TimesheetClassName The name of the timesheet class.
TimesheetClassType The type of the timesheet class (for example, sick time or
vacation time).
TimesheetLineComment The text comment for the timesheet line.
TimesheetLineStatus The status of the timesheet line.

TimesheetLineStatusId Unique identifier for the timesheet line status (see the
corresponding TimesheetLineStatus value).
Each Timesheets object can have a collection of Actuals objects. Each Actuals object may have the following
properties:
TimesheetLineId Unique identifier for the timesheet line.


tasks.
AdjustmentIndex The timesheet actual adjustment index.
CreatedDate The date and time that the timesheet line was created.
LastChangedResourceName Name of the resource that last modified the line.
TimeByDay Date and time for the data, for example, 2013-03-29
00:00:00.000.
TimeByDay_DayOfMonth Day of the month (1 - 31) for time by day calculation.
TimeByDay_DayOfWeek Day of the week (1 - 7) for time by day calculation.
TimesheetLineModifiedDate Time and date the line was last updated.
Each Actuals object can have a collection of CustomFields objects. Each CustomFields object may have the
following properties:
CustomFieldId Unique identifier for the custom field.

UnsubscribedAlerts
UnsubscribedAlerts contains data about alert notifications unsubscribed by the user. For each
UnsubscribedAlertData object, you will see the following properties:
Id Unique identifier for the alert.
AlertName Name of the alert.
UserViewSettings
NOTE
The information in this section applies to Project Server 2016, Project Server 2013, and Project Online. For Project Server
2010, see the UserViewSettings for Project Server 2010.
UserViewSettings contains data about custom view settings that the user created. You can see properties for the
following objects:
WebControlSettings: User settings for web controls in different pages.
WebControlResourcePlanEngagementSettings:: User settings for web controls in the resource plan
engagement pages.
ViewSettings: User settings in different views across the product.
LastPDPViewed: Information about the last Project Detail Page that was viewed for a particular project.
UserSettings: Settings customized by the user.
OptimizerPlannerPlannerReqPages: Settings customized on the Optimizer, Planner and Planner
Request pages.
PlannerDefPlannerResPlannerAvailPages: Settings customized on the Planner Deficit, Planner
Resource, Planner Availability pages.
PortfolioAnalysisGridSettings: Settings customized on the Portfolio Analysis Grid.
OtherWebSettings: Other settings customized on web pages.
WebControlSettings objects can have the following following properties:
WebControl Web control type (for example, resourcecenter).
PropertyName Name of the property.
PropertyValue Value of the property.
WebControlResourcePlanEngagementSettings objects can have the following properties:
WebControl Web control type (for example, resourcecenter).
ViewSettings objects can have following properties:
ViewId The unique identifier for the view.
ViewName Name of the view.
LastPDPViewed objects can have the following properties:
ProjectId The unique identifier for the project.
PropertyString String representing value of the property
PropertyData The binary representation of the property string
UserSettings objects can have the following properties:

ProjectId The unique identifier for the project.
SettingKey Key of the user setting stored in the database.
PropertyString String representing value of the property
OptimizerPlannerPlannerReqPages objects can have the following properties:
PageName Name of the page.
AnalysisUid Unique identifier of the analysis.
ViewUid Unique identifier of the view
ViewName Name of the view.
For each PlannerDefPlannerResPlannerAvailPages object, you will see the following properties:
PageName Name of the page.
AnalysisUid Unique identifier of the analysis.
AnalysisName The name of the analysis.
PortfolioAnalysisGridSettings objects can have the following properties:

PageUrl URL of the page.
AnalysisId The unique identifier of the analysis.
AnalysisName The name of the analysis.
OtherWebSettings objects can have the following properties:
SettingKey Unique key that describes the user setting data being stored.
PropertyName and PropertyValue properties

You may see the following properties for the above objects for the PropertyName and corresponding
PropertyValue properties:
JSGridWidth Width of the displayed grid (value in pixels).
SelectedResourceIds Unique identifiers of resources selected last on the grid.
SelectedResources Unique identifiers of resources selected last on the grid.
TimeStampUID A sequential guid that updates every time the view is

initialized.
Duration Selected value of duration for display on the grid. Values are:
-1 -Invalid, -2 -The duration is an estimate, 1 -Seconds, 2 -
Elapsed seconds, 3 -Minutes, 4 -Elapsed minutes, 5 -Hours, 6
-Elapsed Hours, 7 -Days, 8 -Elapsed days, 9 -Weeks, 10 -
Elapsed Weeks, 11 -Months, 12 -Elapsed Months, 13 -
Quarters, 14 -Elapsed Quarters, 15 -Years, 16 -Elapsed Years,
17 -Decades, 18 -Elapsed Decades, 19 -Percent, 20 -Elapsed
Percent, 21 -No Units, 22 -Material Usage
Date The date format used. Values are:
1 - ShortDate, 2 - ShortTime, 3 - ShortDateTime, 4 -
LongDate, 5 - LongDateTime, 6 - WeekDayMonth, 7 -
MonthDay, 8 - YearMonth, 9 - Sortable, 10 -
SmartShortDateTime, 10 - GeneralLongDateTime
ProjectTeamJsGridFields Contains key value pairs of the fields on the grid.
ExpandSubProjects If true, subprojects are expanded in the UI.
GanttZoomLevel Level to which Gantt is zoomed in for display. Goes from most
zoomed in to most zoomed out: 0 - Minute, 1 - Hour
longdate, 2 - Hour shortdate, 3 - Day with the shortest day
name, 4 - Day with the day Year Month listed, 5 - Day with
the day year month listed, 6 - Month, 7 - Month, 8 - Quarter,
9 - Half year
PredefinedFilter Value of current filtering. Values are: 0 - All, 1 - Overdue, 2 -

Newly Assigned, 3- Completed, 4 - Incomplete, 5 - Custom
DefaultLayout Default layout of the page. Values are: 0- None, 1- Gantt, 2-

Timephased
ZoomLevel Zoom level from most zoomed in to most zoomed out : 0-

Minute, 1 - Hour longdate, 2- Hour shortdate, 3 - Day with
the shortest day name, 4 - Day with the day Year Month
listed, 5 - Day with the day year month listed, 6 - Month, 7 -
Month, 8 - Quarter, 9 - Half year
DividerPosition Position of JsGrid splitter in pixels.
GroupBy0 Field to group by.
SortBy Field to sort by.
SortByOrder 0 - Ascending, 1 - Descending
ViewOutlineLevel If value is -1, expand all, except for subprojects. If value is any
other number, set that outline level expanded.
FilterBy Column to filter by.
SelectedFilterId Field selected to filter.
JSGridFields Contains key-value pairs describing the settings used to

display the Grid in the user interface.
ShowTimeWithDates If true, time is displayed with dates. If false, they are not.
PrincipalColumnWidth Width of principal column in pixels.

CategoryColumnWidth Width of category column in pixels.
IsSidebarHidden Set to true if sidebar is hidden, false if not.
IsViewBubbleChart If true, cost constraint analysis chart is displayed. If false, the

grid is displayed.
IsViewSBAChart If true, Strategic Business Alignment Chart is displayed. If

false, Efficient Frontier chart is displayed.
IsHighlightDeficit If true, the Highlight Deficit option is checked. If false, it is not.
ProjUid Unique identifier of project.
IncludeProposedBookings True to include proposed bookings in the data displayed on

grid, false otherwise.
WorkUnits Determine work units for the grid. Values are: 0- Hours, 1 -
Days, 2- Full Time Equivalent
TimeScale Determines time scale for the grid. Values are: 3 - Days, 4-
Weeks, 5- Months, 6- Quarters, 7 - Years
SelectedViewType Determines the view type. Values are: 0 -

AssignmentsByResource, 1 - AssignmentsByProject, 2-
Availability, 3 - Work, 4 - HeatMapCapacityEngagement
DateEarliestSerialized Represents start date of the view on Capacity Planning page.
DateLatestSerialized Represents the end date of the view on Capacity Planning

page.
UpperThreshold Value of upper threshold on Capacity Planning page.
LowerThreshold Value of lower threshold on Capacity Planning page.
FromDate Start date of the view in the grid.
ToDate End date of the view in grid.
IncludeProposed If true, Include Proposed booking is checked. If false, it is not.
TabExpanded If true, the filter tab is expanded on the Timesheet History

page.
DateFilterChecked If true, the date filter is checked on the Timesheet page.
ResourceFilterChecked If true, the Resource Filter option is checked on the Timesheet

page.
StartDate Date when view starts.
FinishDate Date when view ends.

FilterMode Determines which timesheets are displayed. Values are: 1 -
Show unsubmitted timesheets, 2- Show approved timesheets,
3- Show all timesheets
CustomFilterSelected If true, a custom filter is selected.
SelectedResource Numeric identifier of the resource selected last on the grid.
SelectedFiscalPeriod Index of the fiscal period selected from the Fiscal Period
dropdown menu.
ShowTimeWithDate If true, time is displayed with dates.
ShowInsertedProjects If true, inserted projects will display.
ShowRollups If true, rollups will display.
ShowGanttChart If true, Gantt chart will display.
ShowProjectSummaryTask If true, project summary task will display on grid.
ViewSelection Whether the view displays

InProgressAndFailedJobsInThePastWeek/AllInProgressAndFa
iledJobs/SuccessfulJobsInThePastWeek/AllSuccessfulJobs/All
JobsInThePastWeek/AllJobs TimePhasedPane. .
TimePhasedPane If true, the Timephased pane will display.
IncludeSummaryTasks If true, summary tasks will display.
ShowOvertimeWork If true, overtime work will display.
ShowScheduledWork If true, scheduled work will display.
ShowSelectedList If true, selected resources list will display.
Timephased If true, the Timephased grid will be visible.
Proposed If true, the proposed values will display.
Planned If true, planned work will display.
Overtime If true, overtime work will display.
NonBillable If true, non-billable work will display.
CommentOnSubmit If true, comment dialog will display on submit of timesheet.
ShowTotals If true, total work will display.
TimephasedStart ECMA Date representation of the start date of timephased

data.
TimephasedEnd ECMA Date representation of the end date of timephased
data.
showPlanned If true, planned work will display.
showOvt If true, overtime work will display.
showNonBill If true, non-billable work will display.
dateFormat The format of date values: 1 - ShortDate, 2 - ShortTime, 3 -

ShortDateTime, 4 -LongDate, 5 - LongDateTime, 6 -
WeekdayDayMonth, 7 - MonthDay, 8 - YearMonth, 9 -
Sortable, 10 - SmartShortDateTime, 11 - General
LongDateTime
durationFormat -1 - Invalid, -2 - SwitchToEstimatedDuration , 1 - Seconds, 2 -

ElapsedSeconds, 3 - Minutes, 4 - ElapsedMinutes, 5 - Hours,
6 - ElapsedHours, 7 - Days, 8 - ElapsedDays, 9 - Weeks, 10 -
ElapsedWeeks, 11 - Months, 12 - ElapsedMonths, 13 -
Quarters, 14 - ElapsedQuarters, 15 - Years, 16 - ElapsedYears,
17 - Decades, 18 - ElapsedDecades, 19 - Percent, 20 -
ElapsedPercent, 21 - None, 22 - Material
workFormat -1 - Invalid, -2 - None , 0 - Seconds, 1 - Minutes, 2 - Hours, 3

- Days, 4 - Weeks, 5 - Months, 6 - Quarters, 7 - Years, 8 -
Decades, 9 - Material
filterType 0 - All, Overdue - 1, NewlyAssigned - 2, Completed - 3,

Incomplete - 4
projUids List of projects selected for the resource constraint filter.
roleUids List of roles selected for the resource constraint filter.
UseDate If true, the Filter By Date checkbox is checked on the Manage

Delegations page.
UseResource If true, the Filter By Users checkbox is checked on the

Manage Delegations page.
UseWeek If true, the Only show delegates covering this week option is
checked.
UseSelfDelegates If true, the Only show delegates acting on my behalf

checkbox is checked.
UseNamedDelegate If true, the Delegate name checkbox is checked.
UseActingFor If true, the Delegate name who is acting for option is

checked.
UseDateRange If true, the Date range checkbox is checked.

DelegateUid Unique identifier that represents the currently filtered
delegate.
ActingForUid Unique identifier of the user that the delegation is on behalf

of.
ActingForName Name of delegatee.
FilterVisible If true, the filter options will display.
GridTimeScaleUnits 0- Hours, 1 - Days, 2- Full Time Equivalent
DateRangeFrom Start date of data displayed in the view.
DateRangeTo End date of data displayed in the view.
DateRangeUnits Units used for date range display on grid. Values are: 0-
seconds, 1- minutes, 2- hours, 3- days, 4- weeks, 5 - months,
6- quarters, 7 - years
UserViewSettings for Project Server 2010
NOTE
This section include information about UserViewSettings data in Project Server 2010. For information about Project Server
2016, Project Server 2013, or Project Online, see the previous section (UserViewSettings).
UserViewSettings contains data about custom view settings that the user created. Objects can have the following
properties:
The custom view objects include the following:

WebControlSettings: These are user settings for web controls in different pages. These web controls include
the following:
NAME WEB CONTROL
teambuilderhometab Team Builder
teambuilderjsgridcontrol Team Builder
effectiverightsgrid Effective Rights

NAME WEB CONTROL
eptjsgridcontrol Enterprise Project Types
projectcenterjsgridcontrol Project Center
projectdrilldownjsgridcontrol Schedule Page
resourceassignmentsjsgridcontrol Resource Assignments
resourcecenterjsgridcontrol Resource Center
resourcerequestsjsgridcontrol Resource Requests
reviewtsdetailpartjsgridcontrol Review Timesheet
selecttasksfortlgrid Select tasks for Timeline
statusapprovalshistorypage Status Approval History
approvalcenterjsgridcontrol Approvals
statusapprovalspreviewjsgridcontrol Status Approvals Review
mytasksjsgridcontrol My Tasks
teamtasksjsgridcontrol Team Assignments
timesheetpartjsgridcontrol Timesheets
In the export data for Project Server 2010, WebControlSettings data will display the name of the web control
after the actual property for the control. For example, the following is a Date property for the
MyTasksJSGridControl, which has a value of 1.
{
"PropertyName": "DateMyTasksJSGridControl",
"PropertyValue": "1"
},
WebControlResourcePlanEngagementSettings:: These are user settings for web controls in the

resource plan engagement pages. If the PropertyName contains ResPlanGrid or ProjectEngagementsGrid,
then the GUID in the PropertyName is the Project Unique Identifier (PROJ_UID ). You can retrieve the
corresponding project name from the MSP_PROJECTS table in the Project Server 2010 Published
database.
ViewSettings: These are user settings in different views across the product. If the PropertyName looks
like it contains just one GUID, then that GUID is the View Identifier (WVIEW_UID ) from the
MSP_WEB_VIEW_REPORTS table in the Project Server 2010 Published database, and the corresponding
view name is stored in the WVIEW_NAME.
The actual property name will display before the GUID value.
In the following example, the View unique identifier is 000010fc-7b06 -45a9 -9bd2 -1cbfc2f64ce4 and the
property name is DividerPosition .
{
"PropertyName": "DividerPosition000010fc-7b06-45a9-9bd2-1cbfc2f64ce4",
"PropertyValue": "0"
},
LastPDPViewed: This provides information about the last Project Detail Page that was viewed for a
particular project. The unique identifier of the corresponding project (PROJ_UID ) is displayed after the
string PDPPages_LastViewed_PDP_For . Also, the project name (PROJ_NAME ) can be obtained from the
MSP_PROJECTS table in the Project Server 2010 Published database. In the following example, the project
has a unique identifier of 051f3a1e-02f5 -4e45 -bea7 -30bfbf8df67f , and the last viewed Project Detail Page
has unique identifier 1e26f08d -2757 -46d9 -b726 -16cae3614c56 . You could find the project name by
checking the MSP_PROJECTS table for the PROJ_NAME associated with 051f3a1e-02f5 -4e45 -bea7 -
30bfbf8df67f.
{
"PropertyName": "PDPPages_LastViewed_PDP_For_051f3a1e-02f5-4e45-bea7-30bfbf8df67f",
"PropertyValue": "1e26f08d-2757-46d9-b726-16cae3614c56"
},
OptimizerPlannerPlannerReqPages: This provides settings the user customized on the Optimizer,

Planner and Planner Request pages. If the PropertyName contains {Optimizer } , {Planner } or {PlannerReq }
, two unique identifiers will follow it. The first is the unique identifier of the view, and the second is the
unique identifier for the analysis. You can find the corresponding view name (WVIEW_NAME ) in the
MSP_WEB_VIEW_REPORTS table from the view id (WVIEW_UID ) in the Project Server 2010 Published
database. The corresponding analysis name (ANALYSIS_NAME ) can be obtained from the
MSP_ANALYSIS table from the view ID (ANALYSIS_UID ) column in the Project Server 2010 Published
database.
PlannerDefPlannerResPlannerAvailPages: This provides settings the user customized on the Planner
Deficit, Planner Resource, Planner Availability pages. If the PropertyName contains {PlannerDef } ,
{PlannerRes} or {PlannerAvail} , then the GUID that follows it is the unique identifier of the analysis. The
corresponding analysis name (ANALYSIS_NAME ) can be obtained from the MSP_ANALYSIS table from
the view ID (ANALYSIS_UID ) in the Project Server 2010 Published database.
PropertyName and PropertyValue properties
You may see the following properties for the above objects for the PropertyName and corresponding
PropertyValue properties:
JSGridWidth Width of the displayed grid (value in pixels).
SelectedResourceIds Unique identifiers of resources selected last on the grid.
SelectedResources Unique identifiers of resources selected last on the grid.

TimeStampUID A sequential guid that updates every time the view is
initialized.
Duration Selected value of duration for display on the grid. Values are:
-1 -Invalid, -2 -The duration is an estimate, 1 -Seconds, 2 -
Elapsed seconds, 3 -Minutes, 4 -Elapsed minutes, 5 -Hours, 6
-Elapsed Hours, 7 -Days, 8 -Elapsed days, 9 -Weeks, 10 -
Elapsed Weeks, 11 -Months, 12 -Elapsed Months, 13 -
Quarters, 14 -Elapsed Quarters, 15 -Years, 16 -Elapsed Years,
17 -Decades, 18 -Elapsed Decades, 19 -Percent, 20 -Elapsed
Percent, 21 -No Units, 22 -Material Usage
Date The date format used. Values are:

1 - ShortDate, 2 - ShortTime, 3 - ShortDateTime, 4 -
LongDate, 5 - LongDateTime, 6 - WeekDayMonth, 7 -
MonthDay, 8 - YearMonth, 9 - Sortable, 10 -
SmartShortDateTime, 10 - GeneralLongDateTime
ProjectTeamJsGridFields Contains key value pairs of the fields on the grid.
ExpandSubProjects If true, subprojects are expanded in the UI.
GanttZoomLevel Level to which Gantt is zoomed in for display. Goes from most
zoomed in to most zoomed out: 0 - Minute, 1 - Hour
longdate, 2 - Hour shortdate, 3 - Day with the shortest day
name, 4 - Day with the day Year Month listed, 5 - Day with
the day year month listed, 6 - Month, 7 - Month, 8 - Quarter,
9 - Half year
PredefinedFilter Value of current filtering. Values are: 0 - All, 1 - Overdue, 2 -

Newly Assigned, 3- Completed, 4 - Incomplete, 5 - Custom
DefaultLayout Default layout of the page. Values are: 0- None, 1- Gantt, 2-

Timephased
ZoomLevel Zoom level from most zoomed in to most zoomed out : 0-

Minute, 1 - Hour longdate, 2- Hour shortdate, 3 - Day with
the shortest day name, 4 - Day with the day Year Month
listed, 5 - Day with the day year month listed, 6 - Month, 7 -
Month, 8 - Quarter, 9 - Half year
DividerPosition Position of JsGrid splitter in pixels.
SortBy Field to sort by.
SortByOrder 0 - Ascending, 1 - Descending
ViewOutlineLevel If value is -1, expand all, except for subprojects. If value is any
other number, set that outline level expanded.
FilterBy Column to filter by.
SelectedFilterId Field selected to filter.
JSGridFields Contains key-value pairs describing the settings used to

display the Grid in the user interface.
ShowTimeWithDates If true, time is displayed with dates. If false, they are not.
PrincipalColumnWidth Width of principal column in pixels.
CategoryColumnWidth Width of category column in pixels.
IsSidebarHidden Set to true if sidebar is hidden, false if not.
IsViewBubbleChart If true, cost constraint analysis chart is displayed. If false, the

grid is displayed.
IsViewSBAChart If true, Strategic Business Alignment Chart is displayed. If

false, Efficient Frontier chart is displayed.
IsHighlightDeficit If true, the Highlight Deficit option is checked. If false, it is not.
ProjUid Unique identifier of project.
IncludeProposedBookings True to include proposed bookings in the data displayed on

grid, false otherwise.
WorkUnits Determine work units for the grid. Values are: 0- Hours, 1 -
Days, 2- Full Time Equivalent
TimeScale Determines time scale for the grid. Values are: 3 - Days, 4-
Weeks, 5- Months, 6- Quarters, 7 - Years
SelectedViewType Determines the view type. Values are: 0 -

AssignmentsByResource, 1 - AssignmentsByProject, 2-
Availability, 3 - Work, 4 - HeatMapCapacityEngagement
DateEarliestSerialized Represents start date of the view on Capacity Planning page.
DateLatestSerialized Represents the end date of the view on Capacity Planning

page.
UpperThreshold Value of upper threshold on Capacity Planning page.
LowerThreshold Value of lower threshold on Capacity Planning page.
FromDate Start date of the view in the grid.
ToDate End date of the view in grid.
IncludeProposed If true, Include Proposed booking is checked. If false, it is not.

TabExpanded If true, the filter tab is expanded on the Timesheet History
page.
DateFilterChecked If true, the date filter is checked on the Timesheet page.
ResourceFilterChecked If true, the Resource Filter option is checked on the Timesheet

page.
StartDate Date when view starts.
FinishDate Date when view ends.
FilterMode Determines which timesheets are displayed. Values are: 1 -

Show unsubmitted timesheets, 2- Show approved timesheets,
3- Show all timesheets
CustomFilterSelected If true, a custom filter is selected.
SelectedResource Numeric identifier of the resource selected last on the grid.
SelectedFiscalPeriod Index of the fiscal period selected from the Fiscal Period
dropdown menu.
ShowTimeWithDate If true, time is displayed with dates.
ShowInsertedProjects If true, inserted projects will display.
ShowRollups If true, rollups will display.
ShowGanttChart If true, Gantt chart will display.
ShowProjectSummaryTask If true, project summary task will display on grid.
ViewSelection Whether the view displays

InProgressAndFailedJobsInThePastWeek/AllInProgressAndFa
iledJobs/SuccessfulJobsInThePastWeek/AllSuccessfulJobs/All
JobsInThePastWeek/AllJobs TimePhasedPane. .
TimePhasedPane If true, the Timephased pane will display.
IncludeSummaryTasks If true, summary tasks will display.
ShowOvertimeWork If true, overtime work will display.
ShowScheduledWork If true, scheduled work will display.
ShowSelectedList If true, selected resources list will display.
Timephased If true, the Timephased grid will be visible.
Proposed If true, the proposed values will display.

Planned If true, planned work will display.
Overtime If true, overtime work will display.
NonBillable If true, non-billable work will display.
CommentOnSubmit If true, comment dialog will display on submit of timesheet.
ShowTotals If true, total work will display.
TimephasedStart ECMA Date representation of the start date of timephased

data.
TimephasedEnd ECMA Date representation of the end date of timephased

data.
showPlanned If true, planned work will display.
showOvt If true, overtime work will display.
showNonBill If true, non-billable work will display.
dateFormat The format of date values: 1 - ShortDate, 2 - ShortTime, 3 -

ShortDateTime, 4 -LongDate, 5 - LongDateTime, 6 -
WeekdayDayMonth, 7 - MonthDay, 8 - YearMonth, 9 -
Sortable, 10 - SmartShortDateTime, 11 - General
LongDateTime
durationFormat -1 - Invalid, -2 - SwitchToEstimatedDuration , 1 - Seconds, 2 -

ElapsedSeconds, 3 - Minutes, 4 - ElapsedMinutes, 5 - Hours,
6 - ElapsedHours, 7 - Days, 8 - ElapsedDays, 9 - Weeks, 10 -
ElapsedWeeks, 11 - Months, 12 - ElapsedMonths, 13 -
Quarters, 14 - ElapsedQuarters, 15 - Years, 16 - ElapsedYears,
17 - Decades, 18 - ElapsedDecades, 19 - Percent, 20 -
ElapsedPercent, 21 - None, 22 - Material
workFormat -1 - Invalid, -2 - None , 0 - Seconds, 1 - Minutes, 2 - Hours, 3

- Days, 4 - Weeks, 5 - Months, 6 - Quarters, 7 - Years, 8 -
Decades, 9 - Material
filterType 0 - All, Overdue - 1, NewlyAssigned - 2, Completed - 3,

Incomplete - 4
projUids List of projects selected for the resource constraint filter.
roleUids List of roles selected for the resource constraint filter.
UseDate If true, the Filter By Date checkbox is checked on the Manage

Delegations page.
UseResource If true, the Filter By Users checkbox is checked on the

Manage Delegations page.
UseWeek If true, the Only show delegates covering this week option is
checked.
UseSelfDelegates If true, the Only show delegates acting on my behalf

checkbox is checked.
UseNamedDelegate If true, the Delegate name checkbox is checked.
UseActingFor If true, the Delegate name who is acting for option is

checked.
UseDateRange If true, the Date range checkbox is checked.
DelegateUid Unique identifier that represents the currently filtered

delegate.
ActingForUid Unique identifier of the user that the delegation is on behalf

of.
ActingForName Name of delegatee.
FilterVisible If true, the filter options will display.
GridTimeScaleUnits 0- Hours, 1 - Days, 2- Full Time Equivalent
DateRangeFrom Start date of data displayed in the view.
DateRangeTo End date of data displayed in the view.
DateRangeUnits Units used for date range display on grid. Values are: 0-
seconds, 1- minutes, 2- hours, 3- days, 4- weeks, 5 - months,
6- quarters, 7 - years
Workflow
This file contains data about Project workflows in which the user was an owner. For each WorkflowInstances
object, you may see the following objects:
Object Description
SiteID Unique identifier for the PWA site in which the workflow is
used.
ProjectID Unique identifier of the project utilizing the workflow.
ProjectName Name of the project utilizing the workflow.
WorkflowInstanceId Unique identifier of the workflow instance.

WorkflowError Instance failed with this error string.
WorkflowErrorResponseCode Instance failed with this error code.
WorkflowCreatedDate Date the workflow instance for the project was created.
EnterpriseProjectTypeUid Unique identifier for the enterprise project type using the
workflow.
EnterpriseProjectTypeName Name the enterprise project type using the workflow.
WorkflowStatus Status of the workflow.
For each WorkflowStatus object, you may see the following properties:
WorkflowInstanceId Unique identifier for the workflow instance.
PhaseId Unique identifier for the workflow phase.
PhaseName Name of the workflow phase.
PhaseDescription Description of the workflow phase.
StageId Unique identifier for the workflow stage.
StageName Name of the workflow stage.
StageDescription Description of the workflow stage.
StageInformation Actual stage information that was updated through the

workflow.
StageOrder The order of a stage in a workflow.
StageStatus The status of a workflow stage.
StageStateDescription The description of the state of a workflow stage.
StageEntryDate The date and time that a workflow stage begins.
StageLastSubmitted Date when project was last submitted.
StageCompletionDate Date the stage was completed.
LastModifiedDate Time/Date the workflow instance was last modified.
WorkspaceItems
WorkspaceItems described data about SharePoint items that are used in Project Server and Project Online, such
as Issues, Risks, and deliverables. This can include collections of:
Issues
Risks
Deliverable
ListItemAssociations
There can be a collection of Issues objects that have the following properties:
IssueUniqueId Unique identifier for the issue.
IssueId The ID of the issue.
Title The title or name of the issue.
AssignedToResource WSS item assigned to field.
AssignedToUserClaimsAccount WSS item assigned to claims field.
NumberOfAttachments The number of attachments for the issue.
DueDate Date the issue is due to complete.
Category The category of the issue.
Status The status of the issue.
Priority The priority of the issue.
Owner Name of the issue owner.
OwnerUserClaimsAccount Claims account of the owner.
Discussion The text field for the issue discussion.
Resolution The resolution of the issue.
IsFolder True if the issue is a folder in the SharePoint list.
ItemRelativeUrlPath The relative URL of the issue.
CreatedByResource The resource that created the issue.

CreatedByUserClaimsAccount Claims account of the user that created the issue.
CreatedDate The date and time the issue was created.
ModifiedByResource The user who last modified the issue.
ModifiedByUserClaimsAccount Claims account of the user that last modified the issue.
ModifiedDate The date and time that the issue was last updated.
There can be a collection of Risk objects that have the following properties:
ProjectId Unique identifier for the project with the risk.
ProjectName Name of the project with the risk.
RiskUniqueId The unique identifier of the risk.
RiskId The ID of a risk.
Title The title or name of a risk.
AssignedToResource WSS item assigned to field.
AssignedToUserClaimsAccount WSS item assigned to claims field.
NumberOfAttachments The number of attachments for a risk.
DueDate Date the risk is due.
Probability The percent probability that a risk will happen.
Impact The magnitude of the impact if a risk happens.
Exposure The overall threat of a risk, calculated by multiplying the risk

probability by the impact.
Cost The total projected cost for a risk.
CostExposure The overall threat of risk, calculated by multiplying the cost by

the risk probability.
Category The risk category.
Status The status of a risk.
Owner Name of the risk owner.

R.OwnerUserClaimsAccount Claims account of the risk owner.
Description The text field for a risk description.
MitigationPlan A plan for handling problems that are related to risk factors.
ContingencyPlan The contingency plan for a risk.
TriggerTask The condition that triggers the contingency plan (for example,
date, exposure over threshold, tasks not completed, or other
user-assigned values).
TriggerDescription The description of the trigger that causes a risk.
NumberOfAttachments The number of attachments for the risk.
IsFolder True if the risk is a folder in the SharePoint list.
ItemRelativeUrlPath The relative URL of the risk.
CreatedByResource The resource that created a risk.
CreatedByUserClaimsAccount Claims account of the user that created the risk.
CreatedDate The date and time when a risk was created.
ModifiedByResource The user who modified a risk.
ModifiedByUserClaimsAccount Claims account of the user that last modified the risk.
ModifiedDate The date and time when a risk was modified.
There can be a collection of Deliverables objects that have the following properties:
ProjectId Unique identifier for the project for the deliverable.
ProjectName Name of the project for the deliverable.
DeliverableUniqueId Unique identifier for the deliverable.
DeliverableId The ID of the deliverable.
Title The title of the deliverable.
Description Description of the deliverable.
StartDate The start date and time of the deliverable.

FinishDate The finish date of the deliverable.
IsFolder True if the deliverable is a folder in the SharePoint list.
ItemRelativeUrlPath The relative URL of the deliverable.
CreatedByResource The resource that created the deliverable.
CreatedByUserClaimsAccount The Claims account of the user who created the deliverable
CreatedDate The date and time that the deliverable was created.
ModifiedByResource The resource that last changed the deliverable.
ModifiedByUserClaimsAccount The Claims account of the user who last modified the
deliverable.
ModifiedDate The date and time that the deliverable was modified.
There can be a collection of ListItemAssociations objects that have the following properties:
ListItemId Unique identifier for the list item.
ListItemName Name of the list item.
RelatedProjectId Unique identifier for the related project.
RelatedProjectName Name of the related project.
RelatedItemId Name of the item that is related to the list item
RelatedItemTitle Title of the item that is related to the list item
RelationshipTypeId Identifier of the relationship type
RelationshipDescription Description of the relationship between list item and related

item.
Project-specific user data from the reporting data

The export method defined in Export user data from Project Online will also create eight files for each project in
which the user was a part from the Reporting schema.
Similarly, the queries for project-specific reporting data defined in Export user data from Project Server will
provide you similar output.
This data includes:
NAME DESCRIPTION
Reporting_AssignmentBaselineTimephased Assignment Baseline Timephased data for the project from

the reporting schema.
Reporting_AssignmentTimephased Assignment Timephased data for the project from the

reporting schema.
Reporting_ProjectBaseline Project Baseline data for the project from the reporting
schema.
Reporting_Tasks Project tasks data for the project from the reporting schema.
Reporting_Assignments Assignment resources data for the project from the reporting
schema.
Reporting_Resources Resources data for the project from the reporting schema.
Reporting_TaskBaselineTimephased Task baseline timephased data for the project from the
reporting schema.
Reporting_TaskTimephased Task timephased data for the project from the reporting
schema.
When you are exporting from Project Online, your will receive the information in json file format. The name for
each file will be prefixed with the project name and project ID for the specific project. For example, if a project has
the project name of Project1 and a project ID of fffa21a1 -baac-e711 -9ee6 -00166dac9e0b , the first file in the
table above will be named Project1_fffa21a1 -baac-e711 -9ee6 -00166dac9e0b_draft.xml .
Reporting_AssignmentBaselineTimephased
Reporting_AssignmentBaselineTimephased contains the properties that define the reporting data for assignment
baseline timephased data in the ProjectData service. It has the following properties:
Object Description
BaselineNumber An integer number that identifies a baseline in a project.
TimeByDay A primary key that identifies a day along a timeline. The

ProjectUID The GUID of the project that is associated with the

assignment baseline timephased data.
TaskUID The GUID of the task that is associated with the assignment
baseline timephased data.
AssignmentBaselineCost The planned cost of the assignment.
AssignmentBaselineWork The total planned person-hours scheduled for an assignment.
AssignmentBaselineMaterialWork The planned number of units of supplies or other consumable

items that are to be used to complete an assignment.
AssignmentBaselineBudgetCost The planned cost of an assignment.
AssignmentBaselineBudgetWork The planned total amount of time that is needed to complete

an assignment.
AssignmentBaselineBudgetMaterialWork The planned number of units of the supplies or other

consumable items that are to be used to complete an
assignment.
AssignmentBaselineModifiedDate Date and time the assignment baseline was last modified.
FiscalPeriodUID Unique identifier for the fiscal period.
ResourceId Unique identifier for the resource.
Reporting_AssignmentTimephased
Reporting_AssignmentTimephased contains the properties that define the reporting data for assignment
timephased data in the ProjectData service. It has the following properties:
Object Description

ProjectUID Unique identifier for the project for the assignment

timephased data.
TaskUID Unique identifier for the task for the assignment timephased
data.
ResourceId Unique identifier for the resource.

AssignmentRegularCost The total cost for regular, nonovertime assignment work that
has already been performed, in addition to remaining
nonovertime work.
AssignmentRegularWork The total amount of non-overtime work scheduled to be

performed by a resource assigned to a task.
AssignmentRemainingCost The costs associated with completing all remaining scheduled

work by any resources on a specific task.
AssignmentRemainingOvertimeCost The remaining scheduled overtime expense for an

assignment.
AssignmentRemainingOvertimeWork The amount of overtime work that remains on an

assignment.
AssignmentRemainingRegularCost The expense that will be incurred by completing the

remaining regular, nonovertime work for an assignment.
AssignmentRemainingRegularWork The amount of time, such as person-hours or days, that is still

required to complete the regular, nonovertime work for an
assignment.
AssignmentRemainingWork The amount of time required by a resource assigned to a task

to complete an assignment.
AssignmentCombinedWork The work for the assignment, from both the project plan and
the resource plan.
AssignmentActualRegularCost The cost of the nonovertime work that has already been
AssignmentActualRegularWork The actual amount of regular, nonovertime work that has

already been performed on an assignment.
AssignmentCost The total cost for an assignment, based on costs already

incurred, in addition to costs that are planned for the
remaining work.
AssignmentOvertimeCost The total overtime cost for an assignment, including costs for
to remaining overtime costs.


assignment.
work.

assignment.
AssignmentBudgetMaterialWork The total projected amount of use on the assignment of

material resources.

resource plan.
Reporting_ProjectBaseline
Reporting_ProjectBaseline contains the properties that define the reporting data for project baseline data in the
ProjectData service. It has the following properties:
Object Description
BaselineNumber A number that identifies a project baseline.
ProjectUID Unique identifier for the project.
TaskUID Unique identifier for the task.
TaskBaselineCost The total planned cost for the task.
TaskBaselineFixedCost A set task cost that is projected in the baseline and that
remains constant regardless of the task duration or the work
performed by a resource.
TaskBaselineWork The total hours that are scheduled in the baseline projection
for a task.
TaskBaselineBudgetCost The cost of the budgeted amount of work as projected in the

baseline.
TaskBaselineBudgetWork The budgeted amount of work as projected in the baseline.
TaskBaselineStartDate The projected task start date and time.
TaskBaselineFinishDate The projected completion date of a task.
TaskBaselineDeliverableStartDate The published deliverable start date and time for a task.
TaskBaselineDeliverableFinishDate The published deliverable finish date and time for a task as
projected in the baseline.
TaskBaselineDuration The amount of time estimated to complete a task.
TaskBaselineStartDateString A string that contains the projected task start date and time.
TaskBaselineFinishDateString A string that contains the projected task finish date and time.
TaskBaselineDurationString A string that contains the projected task duration.
TaskBaselineModifiedDate The date and time the task was last updated.
Reporting_Tasks
Reporting_ProjectTasks contains the properties that define the reporting data for project tasks data in the
TaskUID The unique identifier of the task.
TaskParentUID The unique identifier of the parent task.
ProjectUID The unique identifier of the project to which the task belongs.
FixedCostAssignmentUID The PWA instance site ID.
TaskName The unique identifier of the task.
TaskIndex Number of the task in the local project.
TaskIsProjectSummary Whether the task is a project summary task.

TaskIsOverallocated Gets a value that indicates whether the task is overallocated.
TaskIsMilestone Whether the task is a milestone.
TaskIsCritical Gets a value that indicates whether the timing for the task is
critical or whether there can be any slack in the timing.
TaskIsSummary Whether the task is a summary task.
TaskStatusManagerUID The unique identifier of the task status manager.
TaskActualFixedCost The actual fixed cost of the task.
task.
TaskOvertimeWork The amount of overtime work scheduled for the task.
TaskDurationVariance The difference between the baseline duration of the task and
the total duration, or current estimated duration, of the task.
TaskStartVariance The variance of the task start date from the baseline start
TaskDuration The planned duration of the task.

TaskDeliverableStartDate The published deliverable start date and time for a task.
TaskDeliverableFinishDate The published deliverable finish date and time for a task.
TaskActualStartDate The date the task was started.
TaskActualFinishDate The date the task was completed.
TaskPercentCompleted The percentage of the task duration completed.
TaskPercentWorkCompleted The percentage of the task work completed.

Manager. This can be used as an alternative for calculating
the budgeted cost of work performed (BCWP).
TaskSPI Shows the ratio of the budgeted cost of work performed to

the budgeted cost of work scheduled (BCWP/BCWS).
TaskTCPI Ratio of the work remaining to be done to funds remaining to

be spent, as of the task status date (to complete performance
index).
TaskVAC Variance at completion.
TaskDeadline The target date and time for when a task should be
completed.
TaskDurationIsEstimated Whether the baseline duration of the task was estimated.
TaskEAC Task estimate at completion is the expected total cost of a

task based on performance up to the status date.
TaskIsEffortDriven Whether the task is effort-driven.
TaskIsExternal Whether the task is external.
TaskIsRecurring Whether the task is a recurring task.

the task.
TaskCV Earned value cost variance - show the difference between

how much it should have cost and how much it has actually
cost to achieve the current level of completion up to the
status date.
TaskCPI Show the ratio of budgeted (or baseline) costs of work

performed to actual costs of work performed, up to the
project status date.
minutes x 1000.
TaskIgnoresResourceCalendar Whether the task ignores the resource calendar.
TaskClientUniqueId Unique ID of the task as shown in Project Professional.
TaskIsMarked True if task is marked for identification or further action.
TaskCreatedDate The date that the task was created.
TaskModifiedDate The date that the task was last updated.
TaskBudgetCost Used to compare budgeted costs with the planned or actual

costs.
TaskResourcePlanWork Time scheduled on a task for all resouces in the resource plan.
This field is used to avoid double-counting if the scheduled
work is from a resource plan.

with a task.
TaskHyperLinkAddress A hyperlink that is associated with a task.

TaskHyperLinkSubAddress The subaddress of a task hyperlink.
TaskStartDateString The string value for a task start date and time.
TaskFinishDateString The string value of the task finish date and time.
TaskDurationString The string value for the duration of a task.
TaskIsManuallyScheduled The unique identifier of the project to which the task belongs.
TaskIsActive If the task is currently active.
CustomFields Custom fields used in the task.
If the task contains a CustomField object, it will have the following properties:
TaskId Unique identifier for the task in which the customer field is
used.
Reporting_Assignments
Reporting_Assignments contains the properties that define the reporting data for assignments in the ProjectData
service. It has the following properties:
Object Description
ProjectUID Unique identifier for the project for the assignment.
ResourceUID Unique identifier for the resource for the assignment.
TaskUID Unique identifier for the task for the assignment.
ResourceOwnerUID Unique identifier for the resource owner.
AssignmentCost The total cost for an assignment, based on costs already

incurred, in addition to costs that are planned for the
remaining work.
AssignmentOvertimeCost The total overtime cost for an assignment, including costs for
to remaining overtime costs.



assignment.
work.
AssignmentPercentWorkCompleted Percentage of work that has been completed.
AssignmentStartDate Date a resource is scheduled to begin an assignment.
AssignmentFinishDate Date a resource is scheduled to complete assignment.
AssignmentActualStartDate Date a resource is begins an assignment.
AssignmentActualFinishDate Date a resource is completes an assignment.
AssignmentDelay Amount of time a resource is to wait before starting to work

on an assignment.
AssignmentStartVariance Variance at the start of the assignment.
AssignmentFinishVariance Variance at the assignment finish.
AssignmentACWP Actual cost of work performed for the assignment.
AssignmentBCWP Budgeted cost of work performed for the assignment (earned

value).
AssignmentBCWS Budgeted cost of work scheduled for the assignment (planned

value).
AssignmentBookingID Assignment booking GUID.
AssignmentBookingName Assignment booking name (committed or proposed).
AssignmentType Type of assignment. NormalAssignment=0,

WorkOnlyAssignment=1, FixedCostAssignment=2,
FixedCostWorkOnlyAssignment=3, EmptyAssignment=4,
FixedCostGeneratedAssignment=100 (generated during RDS
transfer), ResourcePlanAssignment=101.
TypeName Name of the assignment type.

R.TypeName
IsPublic True if the item was published, so a team member can see it.
AssignmentCostVariance Difference between baseline cost and total cost.
AssignmentWorkVariance Difference between baseline work and currently scheduled

work.
AssignmentSV Earned value schedule variance.
AssignmentVAC Variance at completion.
AssignmentIsOverallocated True if any assigned resources are overallocated.
AssignmentPeakUnits Maximum number of units that a resource is assignmed for a

task.
AssignmentCreatedDate Date and time the assignment was created.

assignment.
AssignmentBudgetMaterialWork The total projected amount of use on the assignment of

material resources.
resource plan.
TimesheetClassUID GUID of the timesheet class.
If the task contains a CustomField object, it will have the following properties:
PrimaryCustomFieldId The ID of the primary custom field (either a Task or a

Resource type) that this custom field is a child of.
PrimaryCustomFieldName The name of the primary custom field (either a Task or a

Resource type) that this custom field is a child of.
AssignmentRolldown Does the value of this assignment rolls down from the
primary custom field. If it does,the value is the same os the
value of the corresponding primary custom field unless
ovverriden in the assignment custom field
AssignmentId The assignment id that this custom field belong to.
Reporting_Resources
Reporting_Resources contains the properties that define the reporting data for resources in the ProjectData
service. It has the following properties:
ResourceStatusUID GUID of the resource status.

ResourceStatusName Localized name of the resource status. Status includes
Unassigned Resource, Local Resource, Unknown Resource,
and Enterprise Resource. Most resources on a project have
the Enterprise Active status value.

ResourceInitials Initials of the resource.
ResourceMaterialLabel The Material Label field contains the unit of measurement you
enter for a material resource, for example, tons, boxes, or
cubic yards. This label is then used in conjunction with the
material resource's assignment units, for example, eight tons
or 22 boxes.

for values.
TypeName Name of the resource type.
ResourceGroup The Group field contains the name of the group that a
resource belongs to.

ResourceTimesheetManagerUID Timesheet manager for the given resource.
ResourceEarliestAvailableFrom The earliest date that a resource is available for work on a

particular task.
ResourceLatestAvailableTo The last date that a resource is available.
ResourceCanLevel True if resource leveling can be done.
ResourceHyperlink The URL that is specified for a resource in the Edit User page
of Project Web Access.
ResourceHyperlinkHref The text that is displayed for a resource hyperlink, as specified

in the Edit User page of Project Web Access.
ResourceNTAccount The Windows account name for a resource.
ResourceIsActive Specifies the project version that was active when the
resource was created. This field is for internal use by the
Project cache.
ResourceIsGeneric True if the resource is generic.
ResourceWorkgroup A number value that represents a team collaboration method

for a resource.
ResourceClientUniqueId Unique ID of the resource from a local project when opened

in Project Professional.
ResourceCostCenter A user-defined code for resource cost accounting.
ResourceCreatedRevisionCounter Specifies the project version that was active when the
resource was created. This field is for internal use by the
Project cache.
ResourceModifiedRevisionCounter Count of how many times resource was modified.
ResourceCreatedDate The date and time that a resource was created in the project.
ResourceRequiresEngagement True if the resource can only be requested through an

engagement request.
LCID Resource's Language Code ID.
UserClaimsAccount Login name for the user.
Reporting_TaskBaselineTimephased
Reporting_TaskBaselineTimephased contains the properties that define the reporting data for task baseline
timephased data in the ProjectData service. It has the following properties:
Object Description
BaselineNumber A number that identifies a project baseline.
TimeByDay A primary key that identifies the day along a timeline. The
TaskBaselineCost The total planned cost for a task. The baseline cost is also
known as budget at completion (BAC) for earned value.
TaskBaselineFixedCost A set task cost that is projected in the baseline and that
remains constant regardless of the task duration or the work
performed by a resource.
TaskBaselineWork The total planned hours that are scheduled for a task in the
baseline projection.
TaskBaselineBudgetCost The cost of the planned, budgeted amount of work on a task.
TaskBaselineBudgetWork The planned, budgeted amount of work on a task.
TaskBaselineModifiedDate The date and time the task was last updated.
Reporting_TaskTimephased
Reporting_TaskTimephased contains the properties that define the reporting data for task timephased data in the

T.FiscalPeriodUID The identifier of the fiscal period.
TaskIsProjectSummary True if the task is a project summary task.
TaskCost The total scheduled or projected cost for a task.
TaskActualCost The costs incurred for work that is already performed by all
resources on a task, along with any other recorded costs.
TaskWork The total time that is scheduled for a task for all assigned
resources.
TaskOvertimeWork The amount of overtime work that is scheduled to be

performed by all resources that are assigned to a task.
TaskActualWork The actual work that is already performed by resources on a
task, usually expressed as percent complete.
TaskBudgetCost The scheduled costs for a task.
TaskResourcePlanWork The total time that is scheduled for the task in the resource
plan.
TaskModifiedDate Date and time the task was last modified.
Project XML files

The method defined in Export user data from Project Online will give you two project-specific files for the each
user project, but saved to .xml format. You get two .xml files for each project:
<ProjectName>_<ProjectID>_draft.xml: The project file from the Draft schema saved in .XML format.
<ProjectName>_<ProjectID>_published.xml: The project file from the Published schema saved in
.XML format.
See the Project XML Data Interchange Schema Reference to understand the Project XML data contained in these
files.
Project-specific Metadata files

The method defined in Export user data from Project Online will also provide you three project-specific files that
give metadata about each individual project. You receive one from each of the following schemas:
Project metadata file from the Reporting schema
Project metadata file from the Draft schema
Project metadata file from the Published schema
Project metadata file from the Reporting schema
The Project metadata file for a project will have the following properties:
ProjectUID The unique identifier for the project.
ProjectAuthorName The name of the author of the project.
ProjectOwnerResourceUID Resource GUID of the project owner.

ProjectManagerName Name of the project manager.
ProjectType The enumerated value that represents the type of a project.
ProjectStartDate The project start date and time.
ProjectFinishDate The scheduled finish date and time of a project.
ProjectStatusDate The status date and time of a project.
ProjectWorkspaceInternalHRef The URL of the project site.
ProjectWbsIsStale True if the work breakdown structure (task outline hierarchy)

is not up to date.
ProjectEarnedValueIsStale True if earned value fields are out of date.
ProjectRollupsAreStale True if the summary task data is out of date.
ProjectHierarchyNotSynchronized The master - subproject hierarchy is not synchronized.
ProjectCalculationsAreStale True if project schedule calculations are not up to date.
ProjectGhostTaskAreStale True if ghost tasks are out of date. Ghost tasks are
placeholders for cross-project links.
ProjectCurrency The project currency character code.
ProjectCategoryName The name of a project category.
ProjectCompanyName The name of the company for a project.
ProjectKeywords The keywords for a project.
ProjectSubject The subject of a project.
ProjectTitle Name of the project.
ProjectVisibilityMode Is this created from SharePoint task list.
ResourcePlanUtilizationType Value that represents the utilization type of a resource plan.
ResourcePlanUtilizationDate The start date and time for use of the resource plan.
ProjectDescription Description of the project.
EnterpriseProjectTypeName The name of an enterprise project type.
ProjectCreatedDate The date that a project was created.
ProjectModifiedDate The date and time that a project was last modified.
ProjectCalendarDuration The total span of active working time for all tasks in a project,
based on the project calendar that is specified in the Project
Information dialog box.
ProjectIdentifier Human readable identifier for the project. This identifier is

configured in the EPT.
ProjectLastPublishedDate The date of last publish
The project can have a collection of CustomFields objects, with the following properties:
CustomFieldValueUID Unique identifier for the custom field value.
CustomFieldTypeUID Unique identifier for the custom field type.
CFValue Custom field value.
Project metadata file from the Draft schema

The Project metadata file for a project in the Draft schema will have the following properties:
ProjectActualCost The costs incurred for work that has already been performed
on a project.
ProjectCritcalSlackLimit The number of days past its end date that a task can go
before Project marks that task as a critical task.
ProjectCurrencyDigits The number of decimal digits in currency values.
ProjectCurrencyPosition The placement of the currency symbol in relation to the

currency value.
ProjectCurrencySymbol The project currency symbol.
ProjectCurrencyCode The currency code of the project, as defined in ISO 4217.
ProjectIsNewTasksEffortDriven Specifies whether new tasks are effort driven.
ProjectCurrentDate The current date for the project.
ProjectDefaultFinishTime The default finish time for all new tasks.
ProjectDefaultFixedCostAccrual A value that indicates which default fixed cost accrual method
to use on new tasks.
ProjectMinutesPerDay The default number of minutes per day.
ProjectMinutesPerWeek The default number of minutes per week.
ProjectDefaultOvertimeRate Default overtime rate for local resources.
ProjectDefaultStandardRate Default standard rate for local resources.
ProjectDefaultStartTime The default start time for all new tasks.
ProjectDefaultTaskType The default type for all tasks in the project.
ProjectDurationFormat The default format for work duration.
ProjectTasksHonorConstraints Indicates whether Project schedules tasks according to their

constraint date.
ProjectLastSavedDate The date the project was last saved.
ProjectManagerName The name of a project manager.
ProjectMultipleCriticalPaths Indicates whether Project calculates and displays a critical

path for each independent network of tasks within a project.
ProjectPoolAttachedTo The name of the project that shares resources with this
project.
ProjectIsResourcePool Indicates if the project is being used as resource pool.
ProjectScheduledFromStart Indicates whether a project is scheduled from Start Date or

Finish Date.
ProjectSplitTasksInProgress Indicated whether to Allow rescheding of remaining duration
and work when a task slips or reports progress ahead of
schedule.
ProjectSpreadActualCostsToStatusDate Indicates whether actual costs are spread to the status date.
ProjectSpreadPercentCompleteToStatus Indicates whether percent complete is spread to the status

date.
ProjectTitle The title of a project.
ProjectCalculateActualCosts Indicates whether Project should automatically calculate

actual costs.
ProjectWorkEntryFormat The default format for all work durations in the project.
ProjectCalculatesSubTasksAsSummary Indicates whether Project calculates sub-tasks as summary

tasks.
ProjectDaysPerMonth The default number of working days per month.
ProjectDefaultEstimatedDuration A value that indicates whether new tasks have estimated

durations.
ProjectShowEstimatedDurations A value that indicates whether a question mark is displayed

after an estimated duration for a task.
ProjectExpandTimephased Indicates whether Project saves timephased data in a readable

or binary format when saved to a database.
ProjectExternalEdited Indicates whether the project was edited externally.
ProjectReadCount Indicates the number of users who have one or more tables
open as read-only.
ProjectCheckedOutBy Name of the user who checked out the project.
ProjectCheckOutDate The project checked out date.
ProjectPath The project path.
ProjectActualsSyncProtectedActuals A value that indicates whether the project actuals are

synchronized with the protected actuals.
ProjectIsAdministrative Indicates whether the project is an administrative project.

ProjectTimestamp The timestamp on the project.
ProjectLocalPath The project local path.
ProjectWebPath The project web path.
ProjectOwnerUID The GUID of a project owner.
ProjectDataSourceNameID The identifier of the project data source name.
ProjectDelegateAllowed Indicates if project delegate is allowed.
ProjectIsNonWorking Indicates if project is non working.
ProjectScope The project scope.
ProjectIsConsolidatedProject Indicates if it's a consolidated project.
ProjectResourceCanDecline Indicates if resource can decline.
ProjectTrackingMode The default tracking method for all assignments in the project.
ProjectLastPublishedDate The date of last project publish.
LegacyProjectType The legacy project type.
ProjectOptionDefaultStartTime Default start time of a working day.
ProjectOptionDefaultFinishTime Default end time of a working day.
ProjectSiteName The name of the project site.
ProjectSiteServerUID The server ID of the project site..
IssueListName The name of the project issue list.
RiskListName The name of the project risk list.
TotalDocumentCount Count of documents for the project.
ProjectActiveIssueCount Count of active issues for the project.
ProjectActiveRiskCount Count of active risks for the project.
ProjectAdminRoleId The identifier for the project admin role.
ProjectManagerRoleId The identifier for the project manager role.
ProjectTeamMemberRoleId The identifier for the project team member role.

ProjectReaderRoleId The identifier for the project reader role.
ProjectProposalWorkflowInstanceId The identifier of the project workflow instance.
ProjectIsAdminProjectLegacy Indicates whether the project is an administrative project.
ProjectCalendarId The ID for the calendar used by the project.
ProjectClientVersionNumber The client version for the project.
ProjectVersion The version of the project.
ProjectProgramUID The identifier for the project program.
ProjectSessionUID The identifier for the project session.
ProjectSessionDescription The project session descriptor.
ProjectIsDeleted Indicates whether the project is deleted.
ProjectBaselineCalendarId The identifier of the project baseline calendar.
ProjectWBSPrefix The work breakdown structure prefix.
ProjectNewTasksStartOnCurrentDate A value that indicates whether new tasks start on current

date.
ProjectIsNewTasksManual A value that indicates whether new tasks are manually

scheduled.
ProjectSummaryTaskId The task Id of the project summary task.
SharepointIdeaListWebId The Ideas List SharePoint Web ID.
SharepointIdeaListId The Ideas List SharePoint List ID.
SharepointIdeaItemId The Ideas List SharePoint List Item ID.
ProjectVisibilityMode Specifies whether the project site was created from SharePoint
task list.
ProjectIsProjectSiteRemoved Specifies whether the project site was removed.
ProjectUtilizationType Value that represents the utilization type of a project.
ProjectUtilizationDate The start date and time for use of the project.

Project metadata file from the Published schema
The Project metadata file for a project in the Published schema will have the following properties:
ProjectActualCost The costs incurred for work that has already been performed
on a project.
ProjectCritcalSlackLimit The number of days past its end date that a task can go
before Project marks that task as a critical task.
ProjectCurrencyDigits The number of decimal digits in currency values.
ProjectCurrencyPosition The placement of the currency symbol in relation to the

currency value.
ProjectCurrencySymbol The project currency symbol.
ProjectCurrencyCode The currency code of the project, as defined in ISO 4217.
ProjectIsNewTasksEffortDriven Specifies whether new tasks are effort driven.
ProjectCurrentDate The current date for the project.
ProjectDefaultFinishTime The default finish time for all new tasks.
ProjectDefaultFixedCostAccrual A value that indicates which default fixed cost accrual method
to use on new tasks.
ProjectMinutesPerDay The default number of minutes per day.
ProjectMinutesPerWeek The default number of minutes per week.
ProjectDefaultOvertimeRate Default overtime rate for local resources.
ProjectDefaultStandardRate Default standard rate for local resources.
ProjectDefaultStartTime The default start time for all new tasks.
ProjectDefaultTaskType The default type for all tasks in the project.
ProjectDurationFormat The default format for work duration.

ProjectTasksHonorConstraints Indicates whether Project schedules tasks according to their

constraint date.
ProjectLastSavedDate The date the project was last saved.
ProjectManagerName The name of a project manager.
ProjectMultipleCriticalPaths Indicates whether Project calculates and displays a critical

path for each independent network of tasks within a project.
ProjectPoolAttachedTo The name of the project that shares resources with this
project.
ProjectIsResourcePool Indicates if the project is being used as resource pool.
ProjectScheduledFromStart Indicates whether a project is scheduled from Start Date or

Finish Date.
ProjectSplitTasksInProgress Indicated whether to Allow rescheding of remaining duration

and work when a task slips or reports progress ahead of
schedule.
ProjectSpreadActualCostsToStatusDate Indicates whether actual costs are spread to the status date.
ProjectSpreadPercentCompleteToStatus Indicates whether percent complete is spread to the status

date.
ProjectTitle The title of a project.
ProjectCalculateActualCosts Indicates whether Project should automatically calculate

actual costs.
ProjectWorkEntryFormat The default format for all work durations in the project.
ProjectCalculatesSubTasksAsSummary Indicates whether Project calculates sub-tasks as summary

tasks.
ProjectDaysPerMonth The default number of working days per month.

ProjectDefaultEstimatedDuration A value that indicates whether new tasks have estimated
durations.
ProjectShowEstimatedDurations A value that indicates whether a question mark is displayed

after an estimated duration for a task.
ProjectExpandTimephased Indicates whether Project saves timephased data in a readable

or binary format when saved to a database.
ProjectExternalEdited Indicates whether the project was edited externally.
ProjectReadCount Indicates the number of users who have one or more tables
open as read-only.
ProjectCheckedOutBy Name of the user who checked out the project.
ProjectCheckOutDate The project checked out date.
ProjectPath The project path.
ProjectActualsSyncProtectedActuals A value that indicates whether the project actuals are

synchronized with the protected actuals.
ProjectIsAdministrative Indicates whether the project is an administrative project.
ProjectTimestamp The timestamp on the project.
ProjectLocalPath The project local path.
ProjectWebPath The project web path.
ProjectOwnerUID The GUID of a project owner.
ProjectDataSourceNameID The identifier of the project data source name.
ProjectDelegateAllowed Indicates if project delegate is allowed.
ProjectIsNonWorking Indicates if project is non working.
ProjectScope The project scope.
ProjectIsConsolidatedProject Indicates if it's a consolidated project.
ProjectResourceCanDecline Indicates if resource can decline.
ProjectTrackingMode The default tracking method for all assignments in the project.
ProjectLastPublishedDate The date of last project publish.

LegacyProjectType The legacy project type.
ProjectOptionDefaultStartTime Default start time of a working day.
ProjectOptionDefaultFinishTime Default end time of a working day.
ProjectSiteName The name of the project site.
ProjectSiteServerUID The server ID of the project site..
IssueListName The name of the project issue list.
RiskListName The name of the project risk list.
TotalDocumentCount Count of documents for the project.
ProjectActiveIssueCount Count of active issues for the project.
ProjectActiveRiskCount Count of active risks for the project.
ProjectAdminRoleId The identifier for the project admin role.
ProjectManagerRoleId The identifier for the project manager role.
ProjectTeamMemberRoleId The identifier for the project team member role.
ProjectReaderRoleId The identifier for the project reader role.
ProjectProposalWorkflowInstanceId The identifier of the project workflow instance.
ProjectIsAdminProjectLegacy Indicates whether the project is an administrative project.
ProjectCalendarId The ID for the calendar used by the project.
ProjectClientVersionNumber The client version for the project.
ProjectVersion The version of the project.
ProjectProgramUID The identifier for the project program.
ProjectSessionUID The identifier for the project session.
ProjectSessionDescription The project session descriptor.
ProjectIsDeleted Indicates whether the project is deleted.
ProjectBaselineCalendarId The identifier of the project baseline calendar.
ProjectWBSPrefix The project work breakdown prefix.

ProjectNewTasksStartOnCurrentDate A value that indicates whether new tasks start on current
date.
ProjectIsNewTasksManual A value that indicates whether new tasks are manually

scheduled.
ProjectSummaryTaskId The task Id of the project summary task.
SharepointIdeaListWebId The Ideas List SharePoint Web ID.
SharepointIdeaListId The Ideas List SharePoint List ID.
SharepointIdeaItemId The Ideas List SharePoint List Item ID.
ProjectVisibilityMode Specifies whether the project site was created from SharePoint
task list.
ProjectIsProjectSiteRemoved Specifies whether the project site was removed.
ProjectUtilizationType Value that represents the utilization type of a resource plan.
ProjectUtilizationDate The start date and time for use of the project.

ProjectPublishedReportingTimephasedMode The sync mode for timephased data in reporting.
ProjectPublishedReportingTimephasedFirstDayOfWeek The first day of the week for timephased reporting.
ProjectPublishedReportingTimephasedFirstWeekOfYear The first week of the year for timephased reporting.
ProjectFiscalPeriodMaxModDate The fiscal period max modified date.

Important information for Project Online customers
about plan changes
The Project Online subscription plans have changed. As of August 15, 2016, the following subscription plans will
no longer be available and will be replaced by three new plans:
OLD PLANS WHAT HAPPENED TO IT
Project Lite Renamed to Project Online Essentials
Project for Office 365 (Project Pro for Office 365) Retired
Project Online Retired
Project Online with Project Pro for Office 365 Retired
NEW PLANS
Project Online Essentials
Project Online Professional
Project Online Premium
NOTE
For an overview of features and pricing for the new Project Online subscription plans, see Project cloud-based solutions plans
and pricing site. For more detailed information, see the Project Online Service Description.
How does this affect me?

If you currently have a Project Online subscription for one of the retired plans, the change won't affect you right
away. We want to give you enough time to prepare for the change in plans. With this in mind, the following
describes the different options available to you:
I am a new customer
If you are a new customer (do not currently have a Project Online subscription plan) you can sign up for the new
plans. The retired plans will no longer be available to you.
I am on a retired plan, but still want to use it for a while
If you are using one of the retired plans, you can continue to use it until your agreement expires. If your agreement
expires on or before December 31, 2016, you have the option to renew your current plan for an additional term.
For example, if you are using Project for Office 365 and your agreement expires on December 30, 2016, when you
renew, you can choose to use it for one more term. Or you can choose to move to a new plan if you want. It's up to
you.
While you are using a retired plan, you are free to add additional users on the retired plan.
NOTE
If your agreement expires after December 31, 2016 and you want to renew, you will need to select one of the new plans.
I am on a retired plan, but want to switch to a new plan right now

You don't have to wait until your plan expires to switch to one of the new subscription plans. Starting September 1,
2016, you can switch from a retired plan to a new plan at any time.
Which plan is right for my users?

While a detailed list of what each product can do is available in the Project Online Service Description, the three
new plans are targeted towards distinct roles:
PLAN TARGET USERS
Project Online Essentials Team members
Project Online Professional Project managers
Project Online Premium Portfolio managers, Resource managers
If your users are on a retired plan and you are planning to move them to a new plan, this makes it easier to
determine which new plan you might want to move them to, since the retired plans were also made with distinct
roles in mind.
IF YOU PREVIOUSLY USED THIS YOU MOST LIKELY WILL WANT THIS
Project Lite Project Online Essentials
Project for Office 365 (Project Pro for Office 365) Project Online Professional
Project Online Project Online Premium
Project Online with Project Pro for Office 365 Project Online Premium/Project Online Professional
The big difference between Project Online Professional and Project Online Premium is that the latter has
additional capabilities for portfolio planning, demand management, enterprise resource management, and out-of-
the-box portfolio reporting. You can learn more about the differences between plans in the Project Online Service
Description.
I'm on a retired plan - what do I need to do?

If you currently subscribe to one of the retired Project Online plans, for the most part you don't really need to take
action until you are ready to renew your licenses as you near your agreement expiration date. The following table
describes what you need to do upon renewal and the options that are available to you, depending on the existing
plan you are on.
WHAT TO DO UPON RENEWAL

WHAT YOU NEED TO DO (IF YOUR AGREEMENT ENDS WHAT TO DO UPON RENEWAL
DURING THE TERMS OF YOUR ON OR BEFORE DECEMBER 31, (IF YOUR AGREEMENT ENDS
IF YOU ARE ON THIS PLAN CURRENT AGREEMENT 2016) AFTER DECEMBER 31, 2016)
WHAT TO DO UPON RENEWAL
WHAT YOU NEED TO DO (IF YOUR AGREEMENT ENDS WHAT TO DO UPON RENEWAL
DURING THE TERMS OF YOUR ON OR BEFORE DECEMBER 31, (IF YOUR AGREEMENT ENDS
IF YOU ARE ON THIS PLAN CURRENT AGREEMENT 2016) AFTER DECEMBER 31, 2016)
Project Lite No action needed. Renew to Project Online Renew to Project Online
*Your current Project Lite Essentials Essentials
licenses will automatically be
renamed to Project Online
Essentials. *
Project for Office 365 No action needed. Renew to one of the Renew to Project Online
(previously known as Project following options: Professional
Pro for Office 365) Project for Office 365 (renew
to your old plan)
(renew to a new plan)
Project Online No action needed. Renew to one of the Renew to Project Online
*Your current Project Online following options: Premium
licenses will automatically be Project Online without
renamed to Project Online Project Client (renew to your
Premium without Project old plan)
Client. * Project Online Premium
Project Online with Project No action needed. Renew to one of the Renew to Project Online
for Office 365 following: Professional or Project
Project Online with Project Online Premium based on
for Office 365 (renew to what your user needs to do.
your old plan)
Project Online Premium
What do I need to do to assign my users to a new plan?

Switch to a different Office 365 for business plan is relatively easy to do. You will be able to switch plans either
manually or through the Switch Plans Wizard.
The Switch Plans Wizard leads you through the process of buying a plan that you can switch your current plan to,
reassigns all new user's licenses, and cancels your old plan. Note that you must be switching all of your Office 365
users to a new plan in order to use the Switch Plans Wizard.
If you are not able to use the Switch Plan Wizard, you can Switch Office 365 for business plans manually as well.
What happens to my data when I switch plans?

You users will not lose any of their data when they switch to a new plan. While your users may see a change in the
capabilities available to them by going to the new plan, their data will be untouched.
How will I know when I need to make a decision on my plan?

If you have access to the Office 365 admin portal, you'll see posts in the Message Center (part of the About the
admin center) with information on when you need to take action. In the meantime, you can renew your
subscription and add more licenses as usual.
How can I add additional licenses if I am still using a retired Project
plan?
If you are a customer with an existing Enterprise Agreement that is on a retired Project plan, you are allowed to
order and add more licenses if need within your current Enterprise Agreement enrollment period. You can do this
even though the retired plans do not appear on the Customer Price Sheet or in the Volume Licensing Service
Center. Please contact your partner (licensed service provider) for assistance on ordering retired Project Online
plans. If you have any issues finding your partner, please contact your local Licensing Sales Specialist.
See also
Renew your Project Online plans in a larger organization
Renew your Project Online plans in a larger
organization
In August of 2016, we announced some changes in the Project Online plans that will be available to you, as some
plans expired at the end of 2016 and new ones became available. Many of you may now need to renew your
retired Project Online plans and move your users to the new available plans.
For most organizations, the Project Online license renewal process can help you through purchasing and
reassigning licenses to your users. However, if you need to renew 3000 or more Project Online licenses, you need
to reassign user licenses with the steps documented in this article. These steps are:
1. Step 1: Determine my current licenses and users
2. Step 2: Determine which new Project Online SKUs you need for your users
3. Step 3: Buy the Project Online Skus that you need
4. Step 4: Assign the new licenses to your users
5. Step 5: Verify you have moved your users to the new SKUs
You'll need Windows PowerShell to do this

For the procedures in this article, you'll need to run scripts that will require you to connect to Office 365 from
Windows PowerShell. You'll need to install the following:
The 64-bit version of the Microsoft Online Services Sign-in Assistant for IT Professionals RTW.
The 64-bit version of the Windows Azure Active Directory Module for Windows PowerShell (64-bit
version).
For more information, see Connect to Office 365 PowerShell.
After you complete your installation, open the Windows Azure Active Directory Module for Windows PowerShell
on your desktop and type the following at the prompt:
Connect-MsolService
This lets you to enter your credentials needed to connect to Office 365.
Step 1: Determine my current licenses and users

As a first step, you need to know which Project Online licenses you have and which users they are assigned to. This
will help you to determine which new Project Online licenses they will need.
We suggest using the Manage your Office 365 Licenses script that you can download from the Microsoft Code
Gallery. This script lets you create a comprehensive report of assign skus and enabled plans that prints out to a
.CSV file. We can also use it for replacing your users assigned sku, which is described later in this article.
Make sure to run Get-Help on the script to get more information about usage and examples.
After downloading the Manage-MSOLLicense.ps1 file that contains the script, open your Microsoft Azure Active
Directory Module for Windows PowerShell, log in, and enter the following cmd to run the script:
./Manage-MSOLLicense.ps1 -IAgreeToTheDisclaimer -Report -Logfile .\MyReport.log
This will agree to the disclaimer, create a log file called MyReport.log and save it to the current location, and will
create a License Report CSV file and save it to the default location.
If you open the log file, it will contain the output displayed in the module when you run the script.
If you open the License Report CSV file in Excel, you will see a listing of your users and the SKUs that are assigned
to them:
For example, in the graphic above, you can tell that each user listed has both a Project Online Premium and an
Office 365 Enterprise E5 sku assigned to them. MOD385910 is the org id.
You can use your column filters in Excel to easily group users that are assigned specific licenses. For example, you
could find out which users are all using the Project Lite, Project Online, and Project Online with Project Pro for
Office 365 Skus.
Project Online SKU strings
The following tables lists the possible Project Online Sku strings that you will see in the script results. You can use
the following table to help you determine which Project Online skus are based on the Sku strings.
RETIRED SKU STRINGS SKU NAME
PROJECTONLINE_PLAN_1 Project Online Plan 1
PROJECTONLINE_PLAN_1_STUDENT Project Online Plan 1 Student (for educational institutions)
PROJECTONLINE_PLAN_1_FACULTY Project Online Plan 1 Faculty (for educational institutions)
PROJECTONLINE_PLAN_2 Project Online Plan 2

RETIRED SKU STRINGS SKU NAME
PROJECTONLINE_PLAN_2_STUDENT Project Online Plan 2 Student (for educational institutions)
PROJECTONLINE_PLAN_2_FACULTY Project Online Plan 2 Faculty (for educational institutions)
PROJECTCLIENT Project Pro for Office 365
PROJECTCLIENT_FACULTY Project Pro for Office 365 (for educational institutions)
PROJECTCLIENT_STUDENT Project Pro for Office 365 (for educational institutions)
PROJECT_ESSENTIALS Project Lite
You will also need to know what the new Project Online sku strings mean when you need to assign them to your
users later in this article.
NEW SKU STRINGS SKU NAME
PROJECTPREMIUM Project Online Premium
PROJECTPROFESSIONAL Project Online Professional
PROJECTESSENTIALS Project Online Essentials
PROJECTPREMIUM_STUDENT Project Online Premium Student (for educational institutions)
PROJECTPROFESSIONAL_STUDENT Project Online Professional Student (for educational

institutions)
PROJECTESSENTIALS_STUDENT Project Online Essentials Student (for educational institutions)
PROJECTPREMIUM_FACULTY Project Online Premium Faculty (for educational institutions)
PROJECTPROFESSIONAL_FACULTY Project Online Professional Faculty (for educational

institutions)
PROJECTESSENTIALS_FACULTY Project Online Essentials Faculty (for educational institutions)
PROJECTCLIENT_STUDENT Project Online Desktop Client Student (for educational

institutions)
Step 2: Determine which new Project Online SKUs you need for your
users
Now that you know which Skus are assigned to specific users, you need to determine which new Project Online
plans to renew them to. You first need to know your new Project Online plans and what they do. Look to the
following resources to provide you more information about how to best select the Project Online Skus for your
users:
RESOURCE DESCRIPTION
Important information for Project Online customers about Use this article to get an overview of retired and new Project
plan changes Online plans, and which plan you are likely to move to if you
want the same functionality from your previous plan.
Project Online Service Descriptions Use this article to get a detailed look into what each of the
new Project Online plans provides you in terms of features
and functionality.
Project Online plans and pricing Use this site to see pricing and a high-level comparison of
Project cloud-based solutions.
If you are looking to provide your users with similar functionality as they did in their retired Project Online SKU,
this table gives you some general guidance, but look to the above resources for more detail:
IF YOU PREVIOUSLY USED THIS YOU MOST LIKELY NEED THIS
Project Lite Project Essentials
Project for Office 365 Project Online Professional
Project Online Project Online Premium
Project Online with Project Pro for Office 365 Project Online Premium or Project Online Professional
Step 3: Buy the Project Online Skus that you need

Now that you know what you need, you can now purchase the needed number of licenses you need for each new
Project Online Skus. You can do this through the Microsoft 365 Admin Center through the Billing page. You will
want to Buy licenses for your Office 365 for business subscription.
Step 4: Assign the new licenses to your users

After purchasing the Project Online Skus that you need, you now need to assign them to your users. You can use
the Manage-MSOLLicense script you ran earlier to do this, but it will require additional parameters.
$users=Get-MSOLUser
./Manage-MSOLLicense.ps1 -IAgreeToTheDisclaimer -users $users -Logfile c:\temp\license.log -NewSKU

orgID:NewSKU -ExistingSKU orgID:ExistingSKU
ORGID NEWSKU EXISTINGSKU
Your Office 365 domain name. The Sku you are assigning to the user. The Sku you are replacing.
Example 1
In a very simple example, your company (Contoso) wants to assign new Project Online Essential Skus to all of its
users who currently have Project Lite Skus. I would run the script as the following:
$users=Get-MSOLUser

CONTOSO:PROJECTESSENTIALS -ExistingSKU CONTOSO:PROJECT_ESSENTIALS
After populating the $users variable with your Office 365 users in your tenant, the script first agrees to the
disclaimer, sets the log file location, and then sets the new Sku as Project Online Essentials (PROJECTESSENTIALS )
for all users who have the old Project Lite Sku (PROJECT_ESSENTIALS ) .
Example 2
In another example, let's say that at Contoso, you want to update all of your users in your HR department from
their old Project Online Plan 2 licenses and assign them new Project Online Premium licenses. However, there are
a few users in HR that have already been assigned Project Online Premium licenses, and we don't want to make
any changes to these users. You would run the following script:
C:\PS>$users=Get-MSOLUser | where {($_.Department -like "*HR") -and ($_.Licenses.accountskuid -notlike

"*PROJECTPREMIUM")}
CONTOSO:PROJECTPREMIUM -ExistingSKU CONTOSO:PROJECTONLINE_PLAN_2
This command reads all of your users who are in the HR department and who do not already have a Project
Online Premium Sku (PROJECTPREMIUM ) . The script then agrees to the disclaimer, sets the log file location, and
then sets the new Sku as Project Online Premium for all users who have the old Project Online Plan 2 sku.
NOTE
As mentioned previously, run the Get-Help command to take a look at detailed usage information and additional examples.
It will also provide you information about additional uses of the script that are not needed for this article.
Step 5: Verify you have moved your users to the new SKUs
When you have completed assigning your Project Online Skus to your users, you need to verify that your users no
longer have any of the old Project Online Skus assigned to them. You can do this by simply running the script
again to generate a new license report:
./Manage-MSOLLicense.ps1 -IAgreeToTheDisclaimer -Report -Logfile .\MyReport.log
After running it, open the newly generated License Report in Excel and search for any occurrences of the old
Project Online skus.
Also verify that if you have any unassigned old Project Online skus, that you cancel them in the Microsoft 365
Admin Center on the Billing page. You can search for retired skus by simply searching the file for occurrences of
the retired Project Online sku strings.
If you have any issues in trying to move to your new Project Online skus, you can Contact support for business
products - Admin Help for assistance.
Related Topics
Brian Smith's Project Support Blog: How to handle Project Online sku changes
Turn Roadmap on or off for your organization
Office 365 admins can turn the Project Online Roadmap feature on or off for their organization through their
Microsoft 365 Admin settings.
Considerations about Roadmap data deletion

Before using the Roadmap feature, admins should understand more about deleting Roadmap data, should they
need to do this in the future.
You can turn Roadmap off in the Microsoft 365 admin center. This will prevent your users from using Roadmap, but
will not remove any user data that currently exists.
If your Project Online subscription ends, most of the associated data is deleted in conformance with the Data
Retention, Deletion, and Destruction in Office 365. Unlike other Project Online data, Roadmap data isn’t
automatically deleted after your Project Online subscription ends.
For more information details about deleting Roadmap data, see Remove Roadmap from Office 365.
Turn Roadmap on or off

An Office 365 admin can do the following to turn Roadmap on or off for their organization:
NOTE
Roadmap is currently turned off by default. After March 15, Roadmap will be turned on for all licensed users. If you want to
ensure that Roadmap is off for your organization after that date, follow these steps after February 14, 2019 and turn it off.
You need to do this even if you previously turned Roadmap off, and even if you’ve never used Roadmap.
1. In the Microsoft 365 admin center, under Settings, click Services & add-ins.
2. Click Project Online.
3. Set Turn Roadmap on or off for your entire organization to On or Off.
4. Click Save.
5. After saving the settings, go to project.microsoft.com and verify that you can create a roadmap.
If you aren't able to turn on Roadmap
In the following conditions, you will not be able to turn on Roadmap:
Roadmap is not yet available to your organization
The Roadmap feature is being gradually rolled out to organizations over a period of time, similar to how other
Office 365 features are made available.
If you see this message, it simply means that Roadmap hasn't been made available yet to your tenant, but should be
shortly.
Roadmap is not yet available in your region

Per the Online Services Terms, specific countries have requirements for data storage within that country or region
for Project Online. If you see this message, it means that Roadmap is not currently available in your region.
Roadmap requires Business Application Platform support in your specific country. For the current list of countries
and regions supported by the Business Application Platform, please go to here.
NOTE
For more information about the Online Services Terms, see the Licensing Terms page.
You need to migrate to Common Data Service for Apps

Roadmap requires Common Data Service for Apps. If Roadmap is available to your organization, and you need to
upgrade to CDS for Apps, you will see a message in your Project Online Roadmap settings stating that Roadmap
requires Common Data Service for Apps on your default CDS instance. The message will also provide you a
link to documentation about how to upgrade to CDS for Apps.
Your Office 365 tenant does not have the correct license
Your Office 365 tenant needs to have a Project Online Professional or Project Online Premium license in
order to use the Roadmap feature. The Project Online settings in the Microsoft 365 Admin Center will not be
available if your Office 365 tenant does not have at least one of these licenses.
NOTE
Roadmap is currently not available in the Project Online Professional and Project Online Premium EDU licenses. This includes:
Project Online Professional for Faculty
Project Online Premium for Faculty
Project Online Professional for Students
Project Online Premium for Students
The Project Online Professional or Project Online Premium license assigned to a user will provide three
service plans that will allow the user to use the Roadmap feature. The Project P3, Data integration for Project
with Flow, and Common Data Service for Project service plans directly support the infrastructure of running
Roadmap. All three must be turned on for Roadmap to work for the user.
Related Topics
Roadmap training
Remove Roadmap from Office 365
You can turn Roadmap off in the Microsoft 365 admin center. This will prevent your users from using Roadmap,
but will not remove any user data that currently exists. (Note that it may take a few minutes for roadmap
functionality to be disabled while the setting synchronizes across your tenant.)
1. In the Microsoft 365 admin center, under Settings, click Services & add-ins.
2. Click Project Online.
3. Set Turn Roadmap on or off for your entire organization to Off.
If your Project Online subscription ends, most of the associated data is deleted in conformance with the Data
Retention, Deletion, and Destruction in Office 365. Unlike other Project Online data, Roadmap data isn’t
automatically deleted when your Project Online subscription ends.
You can remove all roadmap data by removing the entire Roadmap solution from Microsoft 365. This will delete all
of the existing roadmaps and associated user data.
1. In the Microsoft 365 admin center, under Admin centers, click Dynamics 365.
2. In the Dynamics 365 Administraton Center, select the default instance, and then click Open.
3. On the Settings menu, under Customization, click Solutions.
4. Select the PortfolioService solution, and then click Delete.
5. Select the PortfolioService_Anchor solution, and then click Delete.
NOTE
Removing the Roadmap solution does not affect any of the projects or tasks that the roadmaps are connected to.
See Also
Delete user data from Roadmap
Delete user data from Roadmap
To delete user data from Roadmap, you need the user's Azure AD Object ID. You can get this by checking the user's
profile properties in Azure AD or by using Get-AzureADUser.
To find a user's roadmaps
1. In the Microsoft 365 admin center, under Admin centers, click Dynamics 365.
2. In the Dynamics 365 Administraton Center, select the default instance, and then click Open.
3. Click Advanced Find.
4. From the Look for menu, choose Roadmaps.
5. Click Edit Columns
6. Click Add Columns.
7. Choose the columns below that you want to search on. Be sure to include Office 365 Group AAD ID.
DISPLAY NAME DESCRIPTION
Name Name of the roadmap.
Order Hint Ordering of the roadmap rows within a roadmap.
Owner AAD ID ID of the user in AAD who owns the roadmap.
Parent Roadmap ID of the parent roadmap.
Creator AAD ID ID of the user in AAD who created the roadmap.
Office 365 Group AAD ID ID of the roadmap's Office 365 group in AAD.
Roadmap Unique identifier of a roadmap.
Roadmap Type The type of roadmap record.
8. Click OK, and then click OK again.

9. In the Fields list, choose Owner AAD Id and type in the user's Azure AD Object ID.
10. Click Results.
Make note of the Office 365 Group AAD ID for any roadmap that you want to make changes to. You must join this
group as an owner in order to make updates to the roadmap.
To add yourself as a group owner, use Add-AzureADGroupOwner:
Add-AzureADGroupOwner -ObjectId <GroupID> -RefObjectId <YourAADObjectID>
For example,
Add-AzureADGroupOwner -ObjectId "62438306-7c37-4638-a72d-0ee8d9217680" -RefObjectId "0a1068c0-dbb6-4537-9db3-
b48f3e31dd76"
Once you are an owner for the groups, you can open the roadmaps from Project Home and make edits or
deletions directly. (Roadmap must be enabled to do this.)
See Also
Create, edit, or save an Advanced Find search

Project Online Service Description

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Online Service Description

Uploaded by

Copyright:

Available Formats

Contents

Get Started with Project Online

Plan to Implement Project Online

Best Practices to Improve Performance

Project Online Software Limits and Boundaries

Configure Rollup of Timephased Reporting Data in Project Online

Project Online is web-based, and is great for:

First, subscribe to Project Online

Start from scratch Add Project Online to Office 365

Next, make sure you can get in!

1. First, add people to Office 365

Start by adding users in the Microsoft 365 admin center. If

When you're ready to add someone to Project Online,

2. Next, group people by what they'll be doing with Project Online

Now that you've added people to

Role Description Permission name

To more easily manage people in Project Online, create

Then, add users to groups.

3. Then, add people as resources

If you know a person will work on projects and tasks,

1. On the Office 365 app launcher , choose Project.

4. Finally, share Project Online with the people you added

Set your time zone

Got users in different time zones? Project Online stores

Want your team members

Want to use groups to manage who's doing what in

And there's more...

There are lots of ways to map Project Online to the way

Ready to move past setup?

Next up, Create a project in Project Web App!

How do I know if I have the right

If you see Project Online listed, this

To add Project Online to your existing Office 365 account:

To enable Project Online on an existing site collection:

2. Click the app launcher , and then click Admin.

Is Project Online for me?

THINGS THAT MIGHT PREVENT ME FROM MIGRATING TO PROJECT

Migrate to Project Online

Need help with your migration?

How to connect to Project Online

2. On the next screen, select Blank project.

5. On the Project Web Apps Accounts page, select Add.

Make room for a new Project Web App site

Check the queue for Failed and Blocking jobs.

Review the errors related to Failed and Blocking jobs to troubleshoot.

Cancel Failed and Blocking jobs.

Check Active Directory synchronization

Update Resource Breakdown Structure

Maintain a valid enterprise resource

Check the ADMINISTRATORS group for

Check with Office 365 Global admin for

Provide timesheet training to new users.

Provide project manager training to new project managers.

Create fiscal periods for the next calendar year.

Consider deleting timesheets for long-ago periods.

Configure Project ID settings when creating a new Enterprise Project

Fin_ 10001 _HR 1 Finance Team: High-

IT_ 10001 1 Information

MKT_ 10001 1 Marketing Team

Other best practices to consider:

Which languages are supported by Project Online?

LANGUAGE LL-CC LOCALE ID (LCID)

Arabic ar-sa 1025