When thinking about using Microsoft Project Server for your PMO, your first thought may be to run using Project Server on premise. As you think of other option, the idea of using Project Online may be effective as well. You then start asking questions and find hosting companies like BemoPro and Project Host can manage project server. But there is another option for running project server and that is running project serve in AZURE.
Ouch my head starts to hurt. Another option to weight into the mix of project server solutions. And so, I started my list of why it may be good to run from project server on AZURE versus running on premise. At first I didn't think it was a good option, but as I understand more about the platform and its abilities, I realized that it's a really good solution.
My list of why I like running project server 2013 on Azure.
So now we have another option for PMOs to think about when deciding where to run their project server. It's just something to think about. Call me if you have any questions.
Every PMO (Project Management Office) is different. Those of us who have been in the project management industry or who have worked within many PMOs will tell you the same. Go to any PMI local chapter meeting and talk with your colleagues about their PMO and often their PMO is quite different from yours. PMOs range from very strong and structure to very weak and perhaps even unknown in the organization. Each PMO has four or five key requirements that drive their makeup and for the most part they vary quite a bit from company to company.
However, there is one requirement that most all PMOs require and that requirement is "reporting to upper management". Over 85% of PMO survey will indicate that "reporting to upper management" is key to most PMOs. So the first thing that comes to my mind about reporting is "How accurate is the data?" Valid report and good data go hand-in-hand. Upper management want accurate reports for making the right decisions.
There are many elements for setting up a PMO and much of this is done by configuring project server. Also, for the most part configuration settings can be changed on the fly. The tracking method is one of the configuration settings and though it can be changed, it's best not to. The main reason for not changing once decided is that when projects are created, they have the tracking method properties set. If the tracking method changes on the server, the method does get changed in projects already created and this may cause confusion. In fact, changing the tracking method is basically having project server in "Free Form".
Microsoft project server and online have a four methods ways to track projects. All of the methods feed back into the project schedule. Some are more exact than others and though they do a good job; we will into a few other settings to make the data more accurate. The options are set in the "Task Settings and Display" under the "Server Settings".
A few other configuration that should be considered for obtaining accurate data for reports is to check the checkbox that forces everyone to use the same tracking method. Consistency and governance are key factors for increasing data accuracy.
The option "Only allow tasks via Tasks and Timesheets" should be checked for data accuracy. This forces actuals to come in from their inputs and it prevents project manager from creating actual work by marking tasks 100% complete.
At this point, your basic tracking method is in place and accurate data is feed back into your project schedule. However, there is more that can be done to ensure accurate data and valid reports. Taking data accuracy a step further requires using timesheets.
Timesheets is provides the most accurate data in your reports and at the same time has the most opposition. Task sheets can look like timesheets, but just saying "Timesheets" makes everyone feel like they are on the clock. Timesheets provides the PMO more information and better information than task sheets. Timesheets also implies a weekly submission of work done each week and because of weekly and regularly submissions of time, we get better and timely data.
For example, a person may work ten hours on a project. The next week they work zero hours. When timesheets are enable, PMO usually require forty hour to be reported. The person submits ten hours of work on project and thirty hours on other non-work tasks. When timesheets are part of the PMO monitoring cycle, the project manager can determine if resources have submitted their work efforts. In this example, if no work was done for a week, the resource still submits a timesheet showing forty hours of non-project work. The project manager then can determine, the resource didn't just forget submitting time.
Timesheets can be a separate process for submitting actual work. When I refer to timesheets, I am actually referring to SEM (Single Entry Mode). SEM puts task sheets and timesheets on a single form making it easier for resources to enter time for tasks on project schedules and admin task for non-project work. SEM is enable in the server settings under the "timesheet Settings and Defaults". The screen shot below shows the bottom part of the form.
As you can see from the form there are other configuration settings. Checking the "Single Entry Mode" does several things. First the timesheets and task sheets are combined on a single form and it also sets the task setting to "Hours of work done per period". There are other options that need to be thought thru and studied. Also, defining the governance of approval and when timesheets are submitted must also be defined. However, it this point the key project server configuration have been made for getting the most accurate date for reports to management.
In summary the key points for PMO strategy and project server governance.
Wow! What a week...or part of a week. Windows PowerShell Summit North America 2015 was here in Charlotte, NC this past week. It was three days of deep dive learning about PowerShell 5.0
I meet all the big names in PowerShell scripting. Jeffrey Snover, Jeffery Hicks, Don Jones, Ed Wilson, Lee Holmes, Jim Christopher and Jason Helmick. These guys really have it together and are making some great strides in using PowerShell and the new features in PowerShell 5.0 Preview.
Plus I learned a whole lot about PowerShell. I discovered better ways to organize my scripts using Modules and Functions. It seem obvious now, but the summit brought all that knowledge into my face.
Some of the other exciting news was. The PowerShell Gallery is an open source PowerShell scripts and modules that can provide more tools to your tool bag. The PowerShellGallery and GitHub are open source repository for building new scripts. Your scripts can submitted and vetted by Microsoft and if they meet right stuff, the scripts can be part of the PowerShell Gallery.
It's been around since PowerShell 4.0, but I finally got a handle on what DSC (Desired State Configuration) and how it can help me do my job. DSC basically is a file of attributes that you system needs and if something changes it can put it back. For example, let's assume that your IIS has application pools are configure to use a service account and the service account is disable or changed. The DSC will set it back.
I also found a few skills PowerShell user that have configured DSC to install software. It's very powerful and the new release will have even more.
The three day PowerShell Summit was well worth the time and money and look forward to attending next year in Redmond.
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.
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