Microsoft Project 2010
The official blog of the Microsoft Office product development group. Learn how to manage your work effectively

March, 2010

  • Microsoft Project 2010

    Video Walkthrough of the Out of the Box Sample Proposal Workflow


    Out of the box, Project Server 2010 comes with a “Sample Workflow” which highlights many of the new features found within Project Server 2010 Workflows. The Sample Workflow was designed to help our customers not only just understand what our new workflows can do, but also give customers and partners the initial building blocks to create their customized workflows.

    The below videos is a step by step walk through of our Sample Proposal. It will show the end user experience, and highlight the different areas an admin must setup in order for this workflow to fully function.

    In addition to the posted videos, attached to this blog you will also find the Visio Diagram of the workflow. Please feel free to use this diagram to assist in traversing the workflow, and as a template for when you are creating your own custom workflow Visio diagrams.

    The source code for the Sample Proposal Workflow has been posted within our SDKs.  Please download the SDK to get access to the source code.  Once you have downloaded the source code, you should be able to modify the workflow logic and upload your own modified version of this sample proposal.

    If you have any questions, please leave them in the comments of this blog.

    Thank you,

    Sam Chung

  • Microsoft Project 2010

    Early Project 2010 Feedback and Issues – Part 2


    Thanks for all the feedback everyone has sent in so far. Here are some of the tops items we’re seeing.

    Fixed Issues -

    Print Preview: The text says “Print Enter Project” instead of “Print Entire Project”. This issue by far we have heard from the most people and we have fixed in the final version.

    Beta - image

    Post-Beta -image

    Exporting to Excel: In the Beta, only the tasks above the first blank line get exported to Excel. In the final version, we have fixed this so all the tasks get exported as expected.

    Setting Hours Per Day and Hours Per Week: This issue didn’t affect all users but it was possible to get into a state where you couldn’t adjust the Hours Per Day and Hours Per Week setting in the Options dialog. This has also been fixed in the final version. In the meantime, you can get around this issue by using VBA. The following line of code will update these settings, just replace # with the number you want to set them to.

    OptionsCalendar HoursPerDay:=#, HoursPerWeek:=#

    Common Questions -

    Entry Bar: In Project 2010, we have turned off the entry bar by default since we noticed people were not using it in usability studies and we want to remove any unnecessary elements from the UI. For those of you who dearly miss it, you can easily turn it back on. Go to File – Options – Display and check “Entry Bar”.

    Before -


    After -


    Setting Constraints: It is by design that you can’t set constraints for manually scheduled tasks (the dropdowns are disabled). The fact that the task is manually scheduled is a lot like the task having a constraint on it since the task is not going to automatically get re-scheduled. You can still set a deadline on manually scheduled tasks. For more information see this blog post.

    Re-sizing Rows: Several people have asked how to re-size all the rows at once. This works the same as Excel. To do this, click the box in the top left corner of the view:


    This will select all the rows in the project. Now, drag the row divider for one of the rows to the height you want all the rows to have. This will set all rows to the same height. This works the same way in Project 2007 too.

  • Microsoft Project 2010

    Project 2010: Project Permissions


    Other Users Need Access to My Projects

    Consider this scenario. As a project manager you create your project and now you’re ready to let others collaborate with you and so you ask yourself “how do I let others get access to my project?” By default, users who are added as resources to the project or who have tasks in the project have some level of access to it. But, these users may only have read access to the project and what about someone who is not directly associated with work on the project? How do you change permissions so that, for example, these users can read, write and publish a project?

    How to Accomplish this in Project Server 2007

    In Project 2007, giving access to another user who was not directly associated with your project would have likely meant making a request to the Project Server administrator to accomplish this task for you. To give access to your project, the administrator would have likely added the project to a security category and then added the category to your user account or to a group in which you belong. This was a lot of work and as the project manager you were at the mercy of the server administrator to do this work. What this typically meant was that there was usually a lag between the time when you wanted other users to help you with your project and when they actually got access to do so.

    So, how has Project Server 2010 made this better?

    How to Accomplish this in Project Server 2010

    In Project Server 2010, the new Project Permissions feature allows users or groups that have been granted the “Manage Basic Project Security” category permission to grant users and groups access to the projects they own. To access the Project Permissions feature do this:

    1. As a user who is a member of at least the default Project Managers group, go to the Project Center.

    2. Select the project you want to add, remove or modify permissions on.

    3. Click on the Project Permissions button on the ribbon.


    On the permissions page, if no permissions have been granted, then the ribbon and page looks like this:


    Here, you click the New button and you are taken to the Edit Project Permissions page. Now suppose your goal is to allow the following:

    1. All Project Managers can access your project.

    2. All Project Managers can open your project using Project Professional or Project Web App (PWA).

    3. All Project Managers can Save changes to your project.

    4. All Project Managers have the ability to view your project in the Project Center.

    Here are the options on the Edit Project Permissions page you’d select:


    As you can see, you can add either users or groups to your Project Permission and in this case, you’ve added the Project Managers group. You can also enable one or a combination of seven different permissions and you’ve enabled the three that will give your users the access they need. What do these permissions do and how do things work? Let’s Talk about this.

    Key Point: Project Server 2010 provides the Project Permissions feature to allow self-serve security on projects.

    Project Permissions – How it Works

    How do Project Permissions work and what do you need to know about them? Are there cases where they won’t give you what you want? Or, are there other things you need to consider? Let’s begin by looking at the basics of the Project Permissions feature.


    At a high level, Project Permissions are like mini security categories with the differences being the following:

    1. These categories can be controlled by non-security administrators (at least those in the default Project Managers group).

    2. These categories cannot be controlled by server administrators nor seen by them on the Manage Categories administrative page.

    3. They apply only to the given project.

    4. There are only seven project level permissions you can grant access to.

    5. You cannot deny any of the given permissions. You only explicitly grant access on the given permission.

    For more detailed information about security categories, please see the following article:

    Key Point: Project Permissions function like security categories.

    The Seven Permissions

    Here’s is a list of the seven available permissions along with a short description of each:



    Open the project within Project Professional or Project Web App

    This gives the user or group read access to the project from either Project Professional or PWA. The assumption is that the user or group already has rights to connect from Project Professional or PWA.

    Edit and Save the project within Project Professional or Project Web App

    This gives the user or group write access (can save changes) to the project from either Project Professional or PWA.

    Edit Project Summary Fields within Project Professional or Project Web App

    This is a variation of the previous permission. This gives a user or group the ability to change the project level properties on a project and to save them, but it does not give them rights to edit the entire project.

    Publish the project within Project Professional or Project Web App

    This gives a user or group the right to publish a project. This assumes the user can also open, edit and save a project.

    View the Project Summary in the Project Center

    This gives a user or group the ability to see a project in the Project Center view. This assumes you already have permissions to a use at least one Project Center view

    View the Project Schedule Details in Project Web App

    This allows a user or group the ability to drill into a project from the Project Center so that they can see the details of the project. The assumption is that you can go to the Project Center or you know the project’s URL so that you can see Project Schedule view.

    View the Project Site

    If a workspace has been published for the project, then this permission allows the user to get to the workspace page in order to see documents, issues, risks and other items associated with the project. It does not imply that users will be able to edit any of the entities in the various lists.

    Key Point: There are seven permissions you can set for a given project.

    Project Permissions Dependencies

    There’s a reason why the Project Permissions are listed in the order that they are. This is because in some cases, a given permission may be reliant on the previous permission in the list. For instance, let’s say you want to allow a user the ability to publish a project. To do this, the user also needs to be able to open, edit and save the project. Thus, the project permissions you would select for your user would be “Open the project in Project Professional or Project Web App”, “Edit and Save the project within Project Professional or Project Web App” and “Publish the project within Project Professional or Project Web App”. What if you selected just the “Publish the project within Project Professional or Project Web App” permission and not the others permissions? Well, your user wouldn’t be able to open the project in order to invoke the publish command and therefore, the permission would be dormant.

    Key Point: The permissions page does not enforce relationships among the permissions. You have to set any related permission a user or group may need.

    Project Permissions and other Server Permissions

    Because Project Permissions are category permissions, they are additive to other permissions a user or group may already have. It also means that if a user or group has been denied access on a given permission elsewhere, they will still be denied the permission no matter how you set up the Project Permissions on your project. An example of this is a user who has been denied the Save Project to Project Server global or category permission. In this case, even though you give your user the right to edit and save the project, they will still be denied the ability to do this because the deny permission overrides any explicit allow permission given elsewhere.

    As another example, suppose your user has been denied access to the Project Center view. This deny will override your wish to allow your user to view the project summary in the Project Center and they will still be blocked.

    Key Point: Project Permissions don’t override explicit Deny permissions set elsewhere.

    Other Considerations

    If you consider the various Project Permissions available, you’ll notice that many of them are “Project Manager” centric. That is, they represent tasks such as saving and publishing a project that a member of the project managers group would normally perform. What this implies is that Project Permissions work well for peers who are also have similar permissions. But, Project Permissions become less effective as a user’s permissions are reduced. Here’s an extreme example to illustrate this. You have a user who only has the Log On global permission. As a project manager, you create Project Permissions for one of your projects and you specify that this user can view the project in the Project Center. This user logs on to PWA, but they still don’t have access to the project. This is because they don’t have access to any Project Center views. Now, if this same user were a member of the team members group, then by-default, they would have what they need to see the project in the Project Center. So, what’s the lesson here? Setting Project Permissions doesn’t provide an automatic path in PWA or Project Professional to projects.

    Key Point: Project Permissions are great for users or groups who are peers but are less effective for users or groups who have fewer rights.

    Using Project Permissions

    There are a couple of points to understand about what you may see on the Permissions page. Here’s an example of what this page may look like after you’ve created and saved several permission sets:
    So how do you interpret what you see here? Well, this means that there are at least three different unique permission sets. On the first one, the Project Managers security group has been given the Open Project, and Save Project to Project Server permissions. On the second one, team members 11 – 14 have the View Project Summary in Project Center and the View Project Site permissions. On the last one, team member 5 has been given the View Project Summary in Project Center permission. When you edit and existing or create a new permission, you can add multiple users, but when you’re finished, each user and group will appear as a separate row in the list and each appears with their own permission set.

    If you edit multiple users or groups, and if they don’t have the same permissions, then all permissions for those users are reset and you have to select new ones. As an example, suppose you select TM11 and TM5 from the list and click Edit. On the Edit Project Permissions page, you’ll see both users, but in the permissions section, no permissions will be selected. Before you Save, you will have to select at least one permission for these two users.

    Key Point: The Permissions page shows you each individual user or group and shows the permissions for that entity. Editing users or groups with dissimilar permissions resets the permissions.


    Project Permissions in Project 2010 make it so that project managers and others can easily grant users or groups the right to perform specific actions on the projects they own. This feature reduces the Project Server administrative burden and makes it much easier for project managers to manage this chore by themselves.

  • Microsoft Project 2010

    Tips and Tricks: Add a custom bar to your print legend


    A popular request for printing project plans is have the legend display a custom bar that you’ve created in your project to highlight specific tasks. For example, if you want your printed project to display pink bars tasks in your project to indicate proposed task cuts AND you want the legend on the printed report to display this custom bar, you need to do more than just format specific bars with a new color. You also need to create a custom bar style that matches the bar formatting. Let’s look at this more carefully.

    1. Before you do anything else, format the individual task bars by right clicking on them and selecting Format Bar. (Or select multiple bars by using Ctrl + click.) In the example, I formatted two bars in pink to make them display more clearly. If you were to print the project at this point, the pink bars would print correctly, but the print legend would not indicate the significance of the new bar color.


    2. Now it gets a little tricky. After formatting the individual bars, create a style for the new bar. On the Format Menu, click Bar Style. (If you’re using Project 2010, On the Format tab, click the down arrow on Format, and then click Bar Styles.)
    Note   Keep in mind that normally you create a bar style to format specific types of tasks (like milestone or critical tasks) throughout your project without manually formatting all the bars. But in the case of improving the usability of the print legend, you need to create a new bar style as a type of workaround.

    3. Go the end of the list of bar styles, and type a name for the new bar style, for example, “Proposed Cut”.

    4. Click in the Appearance column for the new bar, and give the bar a new color, for example, “Fuchsia.” (OK, fuchsia not pink.)

    5. In the Show For column, indicate which task types will be formatted with the new bar. In the example, I indicated that “Normal, Summary” tasks will be formatted with the new color. Entering “Normal,Summary” in the Show For column prevents the bar from appearing on other non-customized bars in your Gantt Chart.


    Your "custom" bar format will now appear on the print legend.                            



  • Microsoft Project 2010

    Tips and Tricks: Mark a single task on the Calendar


    In my last Tips and Tricks blog I introduced the Calendar view in Project, a very familiar and popular way to present task information for instant reporting. Here is another trick you can do on the Calendar— format single tasks differently than other tasks.

    The trick is to first “mark” a task on the Gantt Chart, and then in the Calendar, specify that marked tasks be formatted in a specific way.

    1.  On the Gantt Chart, add the Marked column (right-click a column and then click Insert Column).

    2.  For each task that you want formatted differently, click Yes in the Marked column.


    3.  Now, switch to the Calendar view.

    4. If you’re using Project 2007, click Bar Styles on the View menu. (If your using Project 2010, click Bar Styles on the Format tab.)

    5.  In the Bar Styles dialog box, select the “Marked” task type, and then choose a type of formatting for tasks that are marked. Here is an example of a single task that has been marked in the Gantt Chart and then formatted red in the Calendar.


  • Microsoft Project 2010

    Project 2010: Introducing Delegates


    In Microsoft® Office® Project Server 2007, the timesheet surrogate feature exists to allow one timesheet user to give the management of their timesheet to another user — send updates and so forth. This is great for timesheets, but there are many other parts of Project Web App where you may want to delegate your duties to another user or users but you can’t because a delegation feature doesn’t exist. Based on this need, the delegates feature was born in Microsoft Project Server 2010. This feature simply allows one user to act as another user, no matter the permission level difference of the one user compared to the other. As an example, a team member can be a delegate for an administrator which means that when the team member becomes the delegate, they have all privileges that the administrator has.

    Let’s begin by talking about the security settings that control the delegates feature. Next, we’ll talk about how you create and administer delegates. After that, we’ll talk about delegates from a reporting and programming standpoint and finally we’ll talk about a few things you need to consider.

    The Delegates Security Settings

    There are a number of security permissions that control whether or not the delegates feature is enabled, whether or not a given user can be a delegate or act as a delegate and who has permission to create delegates. By default, the delegates feature is turned on globally, but the feature has not been enabled for any user or group except for administrators. Therefore, in order for the "ordinary" user to participate in delegation, you need to enable it for the various groups or users that you wish. Let’s first look at the Project Web App Global Permissions.


    Here in the Resource section, you can see the following permissions:

    · Manage My Resource Delegates   Allows a user to set up delegates for other users.

    · Manage My Delegates   Allows a user to create a delegate for themselves, but relies on someone else to pair up the delegation to another user who will do the work.

    · Can be Delegate   If a delegate has been created, it allows the user to go to the “Act as a Delegate” page and act for another user.

    · Manage Resource Delegates   Turns on the delegates feature.

    At the user or group security level, similar global permissions can be set. As mentioned earlier, except for the administrators group, all others do not have the ability to create and become delegates.


    There’s also a category permission you need to be aware of. The category permission, found in the <section name> is called “Manage Resource Delegations”.


    Note: By default, in the Administrators group for the My Organization category, this permission is enabled if you have a brand-new Project Server 2010 site and disabled for upgraded sites. What this means is that for upgraded sites by-default and by-design the delegates feature does not work.

    So how does all of this work? Actually, it’s quite simple. Once you become a delegate, Project Server 2010 authorizes you to connect to the server but then switches your context so that you now are working as the user you’re the delegate for. Let’s walk through the setup of a delegate so that you can see what needs to be done.

    Delegate Setup

    Now that you have the security settings set up, it’s time to create your delegates and to act as a delegate. Let’s suppose you manage resource Mary, and Mary has told you she is going to be out of the office for two weeks. You also know she has time that needs to be reported while she’s gone. There are two ways to handle establishing the delegate. If policy permits, Mary can set up her own delegate for you or if not, you as her manager can set this this delegate. In our example, let’s assume you’re going to manage Mary’s work for the two-week period — you can’t find another team member to do this for you – and so you’re going to setup the delegate. To do this, you go to Personal Settings and click Manage Delegates (if you have the Manage My Resource Delegates permission, you can find the Manage Delegates option on the Server Settings page).


    Next, you go to the ribbon and click New.


    Now you can set the period for the delegation and also the fact that you’ll be the delegate for Mary:


    Once the delegation is created, and as long as the current date is within the delegation period, you are now able to work on behalf of Mary. To start working as Mary, go to Personal Settings and click Act as a Delegate. Here you can see that the delegate isn’t active though your delegate is available:


    You select the delegate and click the Start Delegate Session button. At this point, you are now working as Mary and you see the same UI, tasks, timesheets and other things that Mary would see. As well, you have the same permissions as Mary. Thus, if you started out as a Project Manager and Mary is a team member, while working as Mary, you have Team Member privileges. To help alert you that you are working as someone else, all Project Web App (PWA) pages are branded with a status bar as shown below.


    To switch back to your account so that you are no longer a delegate, you can click the status bar where is says “Click here” or go to Personal SettingsAct as a Delegate. Here, you simply click the Stop Delegate Session button on the ribbon.


    Working with Delegates

    To help you find the delegations that you own or manage, filtering can be applied. On the Manage Delegations page, click Filters on the ribbon to see something like this:


    In this picture, you can see that you the manager have two different periods when you may act as Mary.

    Reporting and Programming

    There is no reporting available within PWA to show you, for example, when a user started and stopped a delegate session. The Unified Logging Service (ULS) log does, however, have entries to show you this sort of detail. For instance the following ULS log entries show the beginning and ending point for a delegation:

    3/01/2010 09:18:34.80 w3wp.exe (0x0A04)0x1374 Project Server      General 5z1a Medium PWA:http://pserver/pwa, ServiceApp:PSERVER_ProjectServiceApplication, User:DOMAIN\user, PSI: PWA.UserDelegationActivateDelegationCalling ActivateDelegation for delegationUid 77a5b19b-2b67-4b3c-8b49-c191994ac2df.   

    3/01/2010 09:40:34.98 w3wp.exe (0x0A04)0x1374 Project Server General 5z1c Medium PWA:http://pserver/pwa, ServiceApp:PSERVER_ProjectServiceApplication, User:DOMAIN\user, PSI: PWA.UserDelegationDeactivateDelegationCalling DeactivateDelegation for userUid a0672aff-c177-4908-b190-d9e24076f3ea.        

    In many organizations that enable delegates, you will want to be able to tell what a user has done while acting as a delegate. Though Project Server 2010 does not have built-in auditing, you can consider using Project Server’s built-in events to help you with this. Project Server 2010 has added ten new UserDelegation events you can use to determine when a delegate session is Activated, Activating, Changed, Changing, Created, Creating, Deactivated, Deactivating, Deleted and Deleting. You may find ways to use these events as well as other events to meet your needs.

    Notes and Things to Consider

    Here are some things to consider about delegations.

    1. Be careful about security elevation. Delegations work well for peers (those who have similar permissions) and from “managers” to “subordinates. But, you should probably avoid having someone like a team member act as a delegate for a manager, for example. You should also avoid having users act as administrators. If a user isn’t already an administrator but needs to act as one, you should probably consider just making them an administrator.

    2. When you are acting as a delegate, you cannot manage delegates. This prevents, for example, users who don’t have permissions to create delegates from doing so while acting as another user who has permissions to do so.

    3. Not all PWA functions work with delegation. Here’s a short list of things that may not function properly while you are a delegate for another user:

    a. Issues, Risks, going to Project workspaces. When you navigate to a project’s workspace, you are using your security context and not the delegated user’s context. If prior to activating the delegate session you have access to the project workspace, you will be able to do so while acting as a delegate. But, the delegate session does not grant you permissions to the workspace.

    b. Project Detail Pages. This is the same thing as point ‘a’. Essentially, whenever you leave the realm of Project Server 2010 pages and you’re in SharePoint 2010 pages, the delegation is not in effect.

    c. Project Professional. The delegate session does not apply to Project Professional. Thus, if you are a team member prior to the delegate session and now you’re acting as a project manager, you will still be unable to use Project Professional to work with projects.

    4. As noted earlier, if you upgrade from a previous version, delegates don’t work by-default even for the Administrators group. You will need to add the “Manage Resource Delegates” permission to a category (such as My Organization) that’s been placed on a group or user (preferably group).

    5. In Project Server 2007, timesheets surrogates are used to delegate timesheets from one user to another. Surrogates have been removed from PWA 2010 and delegates is the replacement.

Page 1 of 1 (6 items)