Recently I had a client who was interested in using the timesheet comments for tracking additional details about work done for their clients. The client was using timesheets for billing and wanted their consultants to provide additional details about the work done using comments. In their particular case timesheet comments meet their requirements. For this client, the timesheet comments worked and at the time I thought it was great solution. However, after playing with the solution, I discovered that many factors can cause the comments to be overridden.
It turns out that when a project manager or a timesheet manager approves time, the manager is prompted to send a comment back to the resource. It is at this point, the project manager's comment or blank comment, over writes the existing comments. For my client, the solution worked well because they were not statusing, however most of my clients do statusing, so I decided to dig deeper into this issue.
As I dug deeper into the database to understand timesheet comments, I discovered that the server configuration was also playing a big part in how and when timesheet comments are over written. The following are few scenario statusing in which timesheet comments are not overridden:
I have tested many combination of configurations keep finding that most configuration will over write the timesheet comments after an approval. You may find my scenarios list above may not be correct and my response is, "somewhere in the project server configuration is has affected the comments".
Deep Dive into Timesheet Comments
Determine to find a good solution for timesheets comment, I decided to take a deep time into the data flow of timesheet line comments in the project server database. My thinking at the time was the comments are saved somewhere in the published database or a transaction log file had a history of the comments. My theory didn't pan out as I hoped.
When a timesheet is created; the published database table MSP_TIMESHEET_LINES is updated with a record for each line in the timesheet. Each time a timesheet updated and saved, then the timesheet line data is replaced with the saved data from the form into the MSP_TIMESHEET_LINES. Comments are also saved and updated each time a save occurs.
In the example, below a comment has been added to each line in the timesheet.
After saving the timesheet, we query the PUB.TIMESHEET_LINES and find the following results. Each time a timesheet is save, the comments can be found in TS_LINE_COMMENT field from the PUB.MSP_TIMESHEET_LINES table.
At some point in time user submits their time by clicking SEND and "Turn in Final Timesheet". The timesheet ribbon provides an option to include a comment and then the timesheet is forward to the timesheet manager. Several things happen at this point.
First of all, the comments in the PUB.TIMESHEETS_LINES are the same as before. Second, we find new records inserted in the table DBO.MSP_TIMESHEETLINE. I have also seen with different project server configurations, that the save operations saves records in both tables at times. While watching both the PUB.TIMESHEET_LINES and DBO.MSP_TIMESHEETLINE tables and performing an approval, I found that the approval often over writes the timesheet comment with notes like [mwharton: 3/30/2015] which is the name of the resource and timestamp of the project manager or timesheet manager. Once that happens the timesheet comment is useless if the purpose of the comment was to record details about work done that week.
Conclusion about using Timesheet Comments
Capturing additional details about work using timesheet comments has many limitations. Most project server configuration can cause timesheet comments to be over written. If you are only using the Timesheet feature of project server then this featur may work for you. Timesheet comments are saved and generating detail work reports using commentes may work fine. However, if statusing is part of your governance or if the project server settings is set to SME (Single entry mode) then approvals is going to overwrite your comments and the timesheet comments will be lost.
There is one hope that can make this work for all scenarios. Project server provides server side event handlers that can be used for capture your timesheet comments. The [Timesheet Submitted] event handler can be used to capture the timesheet comments and then write them into a separate table before other approvals override them. A little time and money is needed to be invested in creating this solution because it requires custom coding and connecting the custom code to the event handler. Seems complicated but there are some great coding examples found on MSDN.
Send me your comments if you have found a better solution to manage timesheet comments.
I ran into a small performance issue when running Project Server Service and Distributed Cache Service on the same server and wanted to pass this info to the group. Some of you may find it interesting.
After installing and configuring SharePoint 2013 I have noticed that Distributed Cache Service is enabled by default. I never thought much about what it does until recently. While reading about the purpose of Distributed Cache services, the article stated that Distributed Cache Service should not be running on the same server that runs Project Service, Excel Service, SQL Server or Search Service. What? I'm I the last person on earth that just found this out? I hate to be the last to know this things!
Distributed cache service is used for with SharePoint services such as Newsfeeds, OneNote client access, Security Trimming, Page load performance and Authentication. It also grabs 10% or more of physical memory, which can an impact on performance. The cure to remove is easy. Simply stop the services using SharePoint Admin or PowerShell. I stopped Distribute Cache service on my SharePoint servers and project server does seem slightly more responsive.
So as a best practice when installing SharePoint using the SharePoint 2013 Product Configuration Wizard or when using a PowerShell cmdlet that uses New-SPConfigurationDatabase (by default Distributed Cache services is started) is to stop the Distributed Cache Service after the SharePoint farm is provisioned.. Also the New-SPConfigurationDatabase cmdlet has a switch called –SkipRegisterAsDistributedCacheHost that prevents the distributed cache service from being load, so I have included this switch in my PowerShell scripts.
Here is a reference link about Distributed Cache Service https://technet.microsoft.com/library/jj219572(office.15).aspx
Defining resources roles in a new or existing PMO is a critical aspect of setting up project server. It can be only a handful of roles as such as those that come from out-of-the-box installation or additional roles can be added to meet your organization's requirements. Once the roles are defined, then security groups are built to define the permissions for the resource roles.
Here are the general steps for defining PMO roles and security groups for resources.
Microsoft did a pretty good job with defining basic roles when they designed project server. The key roles out-of-the-box are: Administrators, Executives, Portfolio Managers, Project Managers, Resource Managers, Team Leads and Team Members. With each project server role a security group is defined with basic permissions already associate with the roles. Pretty much 90% of most PMO can start up right away using these definitions. In fact, I usually suggest that organization go with the out-of-box roles and security groups, because it makes deployment much easier. Once a customer users the tool for a few months makes is easier for them for refining user roles and security groups.
However, over time I have found other security groups that helps refine the PMO roles by ensuring that the right permissions are provided to the right process and also trimming permission from the out-of-box groups to ensure that the PMO runs smoothly.
During the PMO requirements gathering stage review the current project server security groups and roles that come out-of-box and see how they fit into your PMO. Look further past the out-of-box and determine if perhaps other roles may be needed. Once you have defined the roles that your PMO will use, then the next step is to determine the permission required for each. There are a lot of category and global permissions to consider, but once it is done, a big part of your PMO security will be defined.
Below is a quick and general review of general roles in a PMO and their general function. If you already familiar with these skip this and look at the new roles.
Administrator: The administrator role is one or two persons who can read all or modify any information in project server. The key aspect of this role is configuration of the project server, but often is the person that manages resources and projects. It is the most powerful role and thus only a few people show have this role. Only one or two people should have this role, however some departments may need limited admin rights for updating enterprise custom tables or managing their side of the RBS and may need a Departmental Administrator.
Executives: The executive role provides the ability to see any data in project server but no permissions to modify data. It makes sense for upper management should have this role because they me the most interested in seeing the full scope of their investment and benefits of using project server. However, some managers may be sensitive to what others are seeing and a Departmental Executive group may be required.
Portfolio Viewers: Portfolio viewers is similar to executive role but limited to their programs and projects. They general do not make major configuration changes and often view the results that come up from the portfolio manager.
Portfolio Managers: Portfolio manager controls the configuration of the portfolio analyzer and requires modifying many different projects to play what-if games.
Project Managers: Project manager's role is to plan and execute the project schedule. They are responsible for completing the project in a timely manner and under budget. The do this monitoring and updating the project schedule weekly and updating the schedule as required. Often they manage the resources in the project schedule, however some companies use the resource manager to manage the resource loads in a project schedule.
Resource Managers: The resource manager role is to work with the project manager and allocate resources in a manner as to not overburden the resources. In an idea world, the project manager request resources from the resource manager and the resource manager allocates the resources to the project schedule. This takes quite a bit of maturity and coordination within the PMO. Often the project manager and the resource manager roles are given to the project manager and the project manager is responsible for coordinating the resource load.
Team Leads: This role allows a team leads with limited control of a project schedule to reallocated resources and reassign team member assignments.
Team Members: All new work resources are assigned team member role. Some of the basic functionality is the ability to logon on PWA and enter timesheets or task sheets. One aspect from this role is that everyone is assigned this role by default and this may be a good reason to use a different role.
The resource roles below of for special requirements in a PMO or perhaps to allow for greater control in your PMO. Implementing this roles are given to a few group of people and at the same time will remove permission from other groups. Review and discuss each of the roles and determine if they make sense in your organization.
Department Admin: The department admin is a stripped down version of the Administrator. Their role may be to update custom enterprise tables or update RBS and categories.
D2D Manager: The Day-to-Day manager role is similar to a project manager, but they manage resource schedule for a year. The purpose of the D2D manager is allocate resource for operational and business as usual activities.
Resource Member (PPM Member, Work Member): The resource member has the identical permissions as "Team Member". The reason for this group is that it requires deliberate action to add the role to the work resource. As mention before, team member is added to the new work resources and at times you may not want this to happen. When using this role, the team member role is configured without any permissions.
EPM Resource Pool Manager: The EPM resource pool manager role is to control the management of adding, updating and removing resources in the enterprise pool.
EPM Resource Manager: The EPM resource manager role is to control and manage resource allocations for many projects. They have the ability to edit many projects schedules and level resources.
Delegation Manager: The delegation manager role is to setup delegates and working on behalf of resources. This provides control and limits the surface of having others setting up delegation for administrators.
Delegate Manager (or Timesheet Manager): The delegate manager may be a person who enters and submits timesheets for a group of resource. This role could be the same person as the timesheet manager if they are required to get their resources timesheet in.
My Favorite Links on SharePoint and Project Server Patches and Updates
Project Server 2013 Cumulative Updates by Brian Smith
Project Server 2010 Cumulative Updates by Brian Smith
SharePoint 2013 Build Number by Todd Klindt
SharePoint 2010 Build Numbers by Todd Klindt
Service Account Suggestions for SharePoint 2013 by Todd Klindt
I came across a situation that when I tried deleting a project from PWA, the project deletion failed because it had outstanding rejected timesheets. Looking in the queue I found the following error messages. This occurred on Project Server 2010. A CU was issued to fixed this bug, but in my situation where I could not apply any patches until the end of year. Also, the project was a test project and needed to be deleted, because it was missing up the resource allocation.
When deleting a project I get the following errors.
rejectedTimesheetLines (System.Guid) :
Item value = 'cfe6ca01-bdae-49d8-ad41-0262d01f1fe7' :
Error: id='10000' name='GeneralItemDoesNotExist' uid='7b4279e5-c8a3-45af-a9ac-c050f232c09e'
Error: id='10000' name='GeneralItemDoesNotExist' uid='d87dff17-3e3c-4ac8-a63e-854f79fe725c'
Error: id='10000' name='GeneralItemDoesNotExist' uid='3910e065-30bd-454f-8911-164910232fd3'
ProjectDeleteFailure (23006). Details: id='23006' name='ProjectDeleteFailure' uid='e94c8143-7d28-4fa1-acb0-5e8aefb3adab' projectuid='05cfcc25-6a13-46e3-ab5c-d173942af6c5' messagetype='Microsoft.Office.Project.Server.BusinessLayer.QueueMsg.AdjustTimeSheetForDeletedProjectMessage' messageID='6' stage='' blocking='Undefined'.
GeneralQueueJobFailed (26000) - ProjectDelete.AdjustTimeSheetForDeletedProjectMessage. Details: id='26000' name='GeneralQueueJobFailed' uid='4768f5c6-52ee-4679-83e8-81c04002d2a0' JobUID='0ef10d90-9319-4979-b49f-da8f3c9a9ece' ComputerName='SP07' GroupType='ProjectDelete' MessageType='AdjustTimeSheetForDeletedProjectMessage' MessageId='6' Stage=''. For more details, check the ULS logs on machine SP07 for entries with JobUID 0ef10d90-9319-4979-b49f-da8f3c9a9ece.
I called the MS Support team and they provided me the following query to delete all the timesheets. I probably could just delete the rejected timesheets, but this particular project was a test project and so none of the teimesheet information was needed.
Here is what we did to resolve
1) Backup all the Project Server databases
2) Execute the SQL statements below
3) From PWA / Server Settings / Delete Objects/ Delete Published projects.
-- The Proj_UID should match the Proj_UID in query below
SELECT PROJ_NAME, PROJ_UID
WHERE PROJ_NAME like '%enter name of project%'
-- Make note of rows selected for reference
-- Replace the UID with number found above
SELECT * FROM MSP_TIMESHEET_ACTUALs
where ts_line_UID IN (SELECT DISTINCT A.TS_LINE_UID
FROM MSP_TIMESHEET_ACTIONS A
INNER JOIN MSP_TIMESHEET_LINES L ON A.TS_LINE_UID = L.TS_LINE_UID
WHERE A.TS_ACTION_ENUM = 1 AND L.PROJ_UID = '05CFCC25-6A13-46E3-AB5C-D173942AF6C5')
-- Query to remove rows
-- Make note of number of rows selected
SELECT * FROM MSP_TIMESHEET_LINES
PowerShell is becoming part of the mainstream for IT support. I have been using it for years and found it useful for keeping all my procedures together for installing and configuring SharePoint and Project Server. It's a wonderful tool and as I get older and forgetful, I am finding it is helping me keep my act together.
However, I never thought about using if for MS Project until just recently. Just recently I attended a PowerShell User Group meeting in Charlotte, NC with hopes of learning new tips and tricks for using PowerShell. What caught my eye for this meeting was the PowerShell Scripting Games. I have heard of this before and was curious on how this game was played.
The concept of PowerShell Scripting games is really simple. The facilitator of the meeting, basically presents a simple problem and everyone tries to solve them using their laptops running PowerShell. They can use any resource that they can access, including the internet. After about fifteen minutes, the group discusses how they solved the problem. As you can imagine, everyone has a slightly different approach on solving the problem and so there was a lot of good ideas passed around.
This particular evening, one game was to create an Excel spreadsheet and save it to three files (Peter.xls, Paul.xls and Mary.xls). Excel is a COM object and basically PowerShell can open Excel and manipulated Excel using PowerShell. Here is where the light turned on! Once I saw that I said to myself, PowerShell can be used for automating Project.
I am still trying to figure out some good business cases for using PowerShell and Microsoft Project, but a few choirs such as updating the enterprise resource pool or adding new users to the enterprise pool might be possible. More to come as I learn more about it. What I want to show in this blog is what a PowerShell script would look like and how it is executed.
At here is what the script produces.
The following procedure shows how to execute and create the MyPowerShellProject.mpp
Here is one tip that help me to quickly get started. I recorded a macro and much of these translated to PowerShell. Very cool!!
In summary, this is very exciting and I see a lot of potential. I raises a lot of questions and is giving me new ideas. I hope that if you try this out, you will later share with me how you are using PowerShell.
Most people familiar with project server will agree that the "project server permission mode" security model is powerful and flexible and at the same time complex and difficult understand. Because of this Microsoft create the SharePoint permission mode and though this security model is much simpler it lacks the security requirements that most companies required.
I have been working with project server security for years and though quite comfortable with molding PWA groups, categories and permissions to meet a PMO security requirements, I still find myself wondering the effects of my changes. Recently I came up with a PWA SECURITY TEST HARNESS that makes this much easier to understand the impact of security changes before putting into production. As you already know, it's best to test and develop in a test environment before rolling into production. With this in mind, the test harness can also be enable in production for a final review with little risk on production.
The concept of the test harness is simple. It's made up of a "TestHarnessGrp" security group and "TestHarnessCat" security category. The TestHarnessGrp group is configured using the TestHarnessCat category. All global and category permissions are unchecked with the exception of "Logon to Project Server'. If "Logon to Project Server" is unchecked, then you can't access PWA, which the minimum permission that we need for testing our PWA security.
Create a PWA Test User profile and then assign TestHarnessGrp group to user profile. The Test User contains only the TestHarnessGrp group and no other permissions checked. Log in PWA using TestUser and you will see something similar to screenshot below:
Here is where it gets interesting. You shouldn't see any PWA links or menu options after logging in as TestUser. It should look very similar to the screen shot above and here is your first insight into the security model. The few links that are shown are being controlled by SharePoint permission and not PWA.
So you next question may be; "How do I use the test harness?" The main principal of the test harness is to understand the minimum settings required for enabling a feature in PWA. The security model often requires one or more setting for a feature to work. It may require either global or category permissions and the views may also need to be enabled. For example, if you wanted to enable only the Resource Center link then what are the minimum permissions required. Then after the Resource Center is shown on the quick launch how do you control what data is shown. And finally how can you refine the project and resource list using the RBS. The test harness, it becomes easier to understand the effect of permissions and changes to the security model.
The Resource Center is a quick launch for viewing and updating various types of resources. Looking thru all the permission, I reasoned that enabling the global permission "Resource Center" turns on the Resource Center quick launch. To test this theory, I check "View Resource Center" in TestHarnessGrp group and then login using the TestUser account. The "Resource Center" quick launch is now available.
But when I quick on "Resource" to access the "Resource Center" the message, "View Failure" appears and then clicking OK comes up with "Access Denied". At first this may be a frustrating but you are almost there. Project server now wants additional information on what you can view and these permissions are set in the TestHarnessCat category.
The security category provides the rules for the security reach and the views. Looking back thru the TestHarnessCat category there is a view called "All Resources". This sounds promising, so enable this view and test it again using TestUser. BAM! You can now access the quick launch and a view data.
Using the security harness I can further refine my views and permissions to meet the PMO requirements. The key take away with using the test harness is to know the exact permissions and views to enable for a particular functionally. Once this is understand, you will better equip to either add new functionality or remove functionally.
Delegation provides the ability of working in behalf of another person. It is usually used because someone is out on vacation or just not available at the time when something needs to happen. It's a critical tool that facilities project server processes and data is moving in a timely fashion and ensures that PMO is running smoothly. For example, suppose timesheets are due first thing Monday morning at 10:00, so the contractors can get paid on Thursday. Timesheets have to be approved and moved thru the cycle, but if resource forgets to submit his timesheet, then there is a good chance he may not get paid in a timely manner. Or perhaps the timesheet needs to be approved and the timesheet manager is out on vacation. The process of getting the timesheets approve must still continue.
Delegation ensures that processes continue in a timely manager. Delegation is the grease that keeps are the PMO wheels turning. Another example, is the Project Manager is out for vacation. In the previous versions of project server, the project schedule owner had to be changed and the temporary manager could update the schedule and republish. It worked but it was not clean, because the project schedule may have update the status managers for the task and then the project manager returned and ownership had to change back. Sometimes it created a bigger mess, so delegation made this process of working in behalf of some very easy.
It's good feature for troubleshooting issues with project server. When a user is having a problem the technical support can work in behalf of the person and reproduce the problem. Often, problems are very difficult to understand and by using delegation I can better understand what the issue is and how to fix it. When the problem gets fixed, delegation can be used to verify that the problem is fixed.
Another useful function of delegation is that sending timesheets and submitting task updates for work resources who do not have access to project server. It's usually best for individuals to enter their own time, but there are situations where a person may need to put the updates on paper and then have another person keying in those updates. So it's easy to see that delegation can be used in many situations and it improves the process of keeping the data flow moving in project server.
And finally I find delegation useful for testing security and new processes within the PMO. When setting up a new PMO or making change to the processes on project server, delegation is useful for playing different role and making sure that processes work as they were designed. With delegation, it's easy to switch from one person to another and test different roles.
How to Use Delegation
Using delegation is straight forward. First a delegation session needs to be defined. It contains three parts. One person is assigned as the "delegate" who is doing the work and another person assigned the "working on behalf of" person and then a period of time is specified as to when the delegate is allowed to work in behalf of another. As simple as it is, the strategy for managing delegates can be complex. Delegation needs to be easy to maintain and at the same time, you need to prevent it from being a way to hack project server. Depending on the version of project server, there is a "Manage Delegates" and "Act as a Delegate" option found under server settings.
Step 1: Using "Manage Delegates" to define a delegation session
Setting and managing delegates is easy, however, there are some issues that we need to be concerned with. For example, it would not be good for delegates to work in behalf of the PWA "Administrator". If delegation is not properly designed, the keys to controlling PWA are given out freely to all those who have the "Delegate" security permission. Most people are ethical and wouldn't take advantage of this, but you still must be careful. Especially, if processes are tied into timesheets and contractor payments.
Step 2: Act as a delegate. Click on this option and then click on who you will be working on behalf of. If there are not records, then go back to step one. Once delegation is enable, there is a yellow bar on the ribbon.
Configuring Delegate Managers and Acting as Delegates
Configuring delegate managers and delegates is done by setting PWA security permissions in categories and groups. Configuration follows the same principles as defining any security permission. Often there is a category that defines the reach of how has features enables and a group that includes categories and global permissions. The out-of-box security has delegation setup for project managers and resource managers and may be a good place to study on how they are originally defined.
In the Global Permissions section in security group contains the following switches to enable or disable delegation:
Point of confusion. When "Manage My Delegates" is checked and "Manage My Resource Delegates" is not checked, the managed menu only allows you to define your delegate and will look like figure 1. However, if "Manage My Delegates" and "Manage My Resource Delegates" are both checked, then the menu looks like figure 2. Where the confusion is that it's hard to tell that the two permissions are enable. When both permissions are set then you must specify yourself you username in the "Working on behalf of" field. Also, when the "Manage My Delegates" is unchecked, this means that you cannot have someone to delegate for you.
Defining PMO delegation and "working on behalf of" governance.
The following statements can be used to determine the PMO delegation and "working on behalf of" policy for your organization.
Strategy of Implementing Delegation Governance.
Ways to Monitor Delegation
Once delegates and delegation is defined and deployed it then becomes critical to monitor delegation and ensure that it is being used properly, by the right people and at the right times. This may be more important as timesheets become the official time tracking tool and timesheets need to be in on time. Below are a list of reports that can be used to help with monitoring.
Do not adjust your browser. The unknown error message below is what you may see when accessing the Approval Center page. Uuugggg!
If you have seen this before, then you know the feeling. It's a general emptiness that you have because there are no traces for determining what caused it and yet you must solve this. When looking in the ULS logs there is nothing. This is because the error is coming from the browser and not the project server. The browser is expecting something and it was NULL. This is my most feared error message.
I originally used the "Developer Dashboard" to troubleshoot this message. I actually felt I got pretty far with my analysis. It failed on a store procedure called MSP_WEB_SP_QRY_Status_ReadTimePhasedDataForAssignments. The problem was that one or more AssnUID were invalid. I learned later that in this case a timesheet was referring to a project that no longer existed and I found out later, indeed someone was cleaning up PWA and decided to delete from project.
The fix to the problem is relatively simple.
PUB.MSP_TIMESHEET_LINES TSL -- Timesheet Lines
Full OUTER JOIN PUB.MSP_PROJECTS P ON P.PROJ_UID=TSL.PROJ_UID -- Projects
Full OUTER JOIN PUB.MSP_TIMESHEETS TS ON TS.TS_UID=TSL.TS_UID -- Timesheets
Full OUTER JOIN PUB.MSP_RESOURCES RES ON TS.RES_UID=RES.RES_UID -- Resources
Full OUTER JOIN PUB.MSP_WEB_TIME_PERIODS TP ON TP.WPRD_UID=TS.WPRD_UID -- Timesheet Periods
TSL.TS_Line_validation_Type = 1 -- 0 is Administrative Task, 1 is Project Task
AND P.PROJ_NAME is null -- Check for Deleted Projects
AND TS.TS_STATUS_ENUM IN (1,2) -- Check for Submitted Timesheets
The Project Conference 2014 was held in Anaheim, CA this past February. It was a great event with over a hundred sessions. The sessions were organized by tracks. The major tracks were Technical, Product and Business. Oh course, I could not go to them all, however, I have been watching them on Channel 9 at http://channel9.msdn.com/Events/Project/2014
I learned a lot from all the technical sessions, but my favorite technical tracks where the following.
#1 Read World Reports: Business Intelligence in Project Online and Project Server, presented by Andrew Lavinsky and Mike Mclean. The one thing that top this on top of the charts was using LINQPad for creating ODATA queries. Amazing tool and makes reporting building using ODATA so much easier.
#2 Troubleshooting Tips for Project and Project Server, presented by Adrian Jenkins and Brian Smith. Just a lot of good techniques and tools for troubleshooting. Tools like SQL Profiler, ULS Viewer and Developer Dashboard, but my favorite was enabling logging in the project client.
#3 The Great Database Migration, Project Server 2010 to 2013 Migration in 8 easy Step presented by Richard Van Langen. Richard took us into a deep dive with migration and the exact steps for using PowerShell. I love PowerShell, so you may only like this if you are a PowerShell nut.
#4 Top SharePoint 2013 features for IT Executives by Chris Givens. So many great features in SharePoint 2013 and Chris just touches the tip of the iceberg of many new features that could enhance a PMO. Some of my favorite are Metadata Navigation to create friendly names with site navigation, embedded code for videos, site mailboxes and eDiscovery to name a few.
Welcome to My Project Expert site. This site is dedicated to the implementation and deployment of Microsoft Project Server and the governance required for a successful PMO.
It's mostly my field notes as I find new tips and tricks or perhaps clear up some information that I find confusing.
Michael Wharton, MVP, MBA, PMP, MCT, MCST, MCDBA, MCSD, MCSE+I, MCC2011 and 2012