Author: Michael Wharton

MVP, MBA, PMP, MCT, MCTS, MCITP, MCSD, MCSE+I, MCDBA. Michael Wharton is a Project/SharePoint Consultant and Trainer. Michael’s career started as a software developer before moving into project management. His passion to improve project management processes began in 2003 using tools like Project Professional and Server. Since then he has trained hundreds of project managers and implemented Project Server in over twenty-five PMOs. He has passed over forty Microsoft certification exams giving him a solid technical background with Project and SharePoint Server. Michael is active in the community. He is the past President-Elect and past Director of Programs for the NC Piedmont PMI, board member of the Triad SQL Server User Group, Triad Developers Guild and Enterprise Architect Roundtable. He is currently writing a book about implementing Portfolio Management using Project Server 2013.

Estimating Annual Budgets using Project Server and Online

Event Description Project Server/Online does great job managing projects and resources, however, did you know that it can also help manage costs and be used for rolling up department budgets for next year? This topic will look at stretching the PMO and PWA capabilities and use it for managing costs and planning budgets using resource loads. In this session, we look at using Day-to-Day or Operations Schedules to capture the complete resource load of resources. For example, the DBA may be working 50% of their time on projects and the other 50% on operational activities. We’ll look at how this resource load can also be captured and then use schedules for working up budgets in the upcoming years. Managing costs and budgets uses project sand operational schedules to plan out and capture this year’s activities making it easier to plan for next year’s schedules. Several companies have used these operational schedules and saved millions of dollars each year when they discovered resources invoices are billing wrong projects and budgeting next year’s operational budget. Basically, we are stretching the PMO capabilities. Presenter Info : Michael Wharton, MVP, MBA, PMP, MCT, MCTS, MCITP, MCSD, MCSE+I, MCDBA. Michael is a Project/SharePoint Consultant and Trainer. Michael’s career started as a software developer before moving into project management. His passion to improve project management processes began in 2003 using tools like Project Professional and Server. Since then he has trained hundreds of project managers and implemented Project Server in over twenty-five PMOs. He has passed over forty Microsoft certification exams giving him a solid technical background with Project and SharePoint Server. Michael is active in the community. He is the past President-Elect and past Director of Programs for the NC Piedmont PMI, board member of the Triad SQL Server User Group, Triad Developers Guild and Enterprise Architect Roundtable. He is currently writing a book about implementing Portfolio Management using Project Server 2013.   Have you watched this webinar recording? Tell MPUG viewers what you think! [WPCR_INSERT]

Estimating Annual Budgets using Project Online/Server

As we all know, Project Online/Server (PWA) does a great job with managing project schedules and resource loads; however, can PWA manage other company process when we stretch the PMO into taking on more roles? For example, several of my previous clients have used PWA to estimate next year’s annual budgets. This article takes a quick look on how PWA can be used to roll up departmental budgets and improve on the capturing of the real resource load across a whole organization. Let’s first look at what project center looks like when departmental budgets are loaded into PWA. Then, we’ll walk back and see how to accomplish this. Note that the same project center view shows next year’s budget (2019) rolled up for all the departments in the organization. In the example below, the company only has three departments, but the concept works for as many departments as are required. The project center view is grouped by year. Because of this, we can roll up the plan costs for all the departments. The blank year displays current projects that are in process— some of them across multiple years. These are current projects not involved with the budget. Year 2019 shows the day to day (D2D) schedules. You might wonder what that means. It will be discussed later, but basically it captures non-project work for those people not on a project. For example, D2D 2018 IT schedule, which captures work business as usual work from a DBA or help desk person. Year 2019 is the roll up of all the departments for next year. This is accomplished by having each department or business group create a staff schedule with any additional fixed expenses. The screen shot below shows what a schedule may look like. There are many ways to do this. My preference is to set up each staff member as a summary task and include big pockets of time showing their main activity. For example, Teresa Black is estimated to spend 1400 hours on projects, 500 hours on design and questions outside of her projects, and 100 hours on administrative activities. The hours add up to about 2000. Close enough for me; however, based on your requirements, you may want a more accurate accounting of hours. You may have a circumstance where you wish to add two additional people for next year. The same kind of hourly planning can be added to that schedule. Finally, utilizing fixed costs or cost resource options can be used to capture other costs and overhead. This would bring your budget in line and provide an accurate picture of what you are asking for for the following year. As I said before, this is just one of many ways to create a budget with PWA. Of course, you’ll want to include enough details to make good decisions on what is required or to be cut for next year’s budget. Once the D2D schedules are completed, they can be revised and several iterations can occur until the final budget is approved. Wow! This makes budgeting easy for next year, and could be the end of article, but it’s not! There are many more benefits beyond just budgeting to this approach for both the PMO and the company as a whole. Resource load is more accurate for all resources throughout the year, and using PWA timesheets can be a good replacement for primitive or expensive time tracking systems. Let me explain. By capturing the day to day schedules of all resources for the year, the project and resource manager have a better view of what the actual resource load looks like. For example, the DBA may spend half their day doing maintenance leaving them with only 20 hours a week for working on projects. The diagram below shows a more accurate picture of resource workloads when using D2D schedules. Once the schedules are published, there is a good reason to start using the PWA timesheet system or at least removing an old-time tracking system. The PWA timesheet can be configured to use charge code and capture where time is really going. It also has a robust approval system. See an example below of a simple timesheet showing a few day to day items. Another bonus is entering vacation time and capturing the impact of such on project schedules. In summary, when using PWA to estimate next year’s budgets, we have killed three birds with one stone: The company has a better way to estimate annual budgets each year. The PMO has better view of resource workload for the year. The PWA Timesheet system allows for the replacement of outdated timesheets, making time tracking easier to manage by department. I hope you will watch my on-demand webinar on this topic, as we explore more fully the in’s and out’s of implementing the process I have suggested here.  

Time to Reboot Your PMO?

The project management office — much like a computer — becomes ineffective and inefficient over time and sometimes requires a reboot. Rebooting a computer resets the system, clears out cache, releases memory and updates drivers. Once the computer system is back up and running, presumably it runs faster and more efficiently. You could look at the PMO in the same way. The average lifetime of a PMO is about five and half years. Think about what has happened in the five years after a PMO has launched. Executive management and sponsors have probably been promoted, left the company or retired, which means someone else has inherited it. Processes and procedures become stalled and ineffective over time. The project management system may not be the latest and greatest. Newer project managers may have begun incorporating agile into their processes, creating chaos and confusion. Likewise, newer people may be asking, “Why are we doing it this way?” The original vision and purpose of the PMO will have changed over time. The PMO role and reach may need to expand and align with human resources or contract management. It’s clear that many events can occur with the passing of time. But instead of letting the PMO continue to become increasingly ineffective, perhaps it just needs a reboot. What does it mean to reboot the PMO? It’s just a matter of revisiting the vision and purpose of the PMO and ensuring that it still aligns with its mission. How do you do this? Here’s my suggested list of activities: Verify PMO executive support. Write a PMO reboot plan and schedule. Review the PMO vision and core values. Review the PMO scope such as portfolios, program and projects. Review the PMO maturity model. Review the staffing and resources required for the PMO. Review PMO training, mentoring and coaching. Review PMO “mythologies” and processes. Review PMO reporting meeting management requirements. Review PMO standards for reporting. Review PMO security and access permissions. Review PMO tools, projects and software. The last step provides a key point. Companies often upgrade Microsoft Project Server without thinking about rebooting their PMO at the same time. Yet the cycle could work out nicely — to change out the software while also reflecting on what has changed over the years and how the new features can be incorporated into the PMO’s revamped operations to make both work better for your organization. For example, it may be time to consider some stretch goals for the PMO that incorporate Project Server features such as timesheets, resource engagements, portfolio management or workflow. Time flies. Maybe it’s time for you to consider your PMO reboot. When was the last time you rebooted your PMO? Share the details with the MPUG community in comments below. Image Source

Migration to Project Server 2016

Project Management Institute (PMI)® Professional Development Units (PDUs): This Webinar is eligible for 1 PMI® PDU in the Strategic category of the Talent Triangle. Event Description:  Migrating from one project server to the next version has many paths and pitfalls. Which one that works best for your company depends on your vision and requirements, your budget and perhaps the easiest way to get to your final solution. This session starts by at reviewing your PMO vision and requirements, then planning architectures of the different versions of SharePoint and Project server. Then we review strategies and advantages between doing an upgrades versus a migration. Building your migration with PowerShell scripts and checklists of additional tasks. Once the migration is stabilize, we go over the steps for the final deployment. Presenter Info: Michael Wharton, Project MVP, has done over 30 migrations for upgrading project server to newer versions.  Every migration has been a different with its own particular problems, however each has been overcome with proper planning. Have you watched this webinar recording? Tell MPUG viewers what you think! [WPCR_INSERT]

Refining Resource Roles and Security Groups in Your PMO

Defining resource roles in a new or existing project management office (PMO) is a critical aspect of setting up Microsoft Project Server. That might be just a handful of roles, such as those that come from out-of-the-box installation; or you can add additional roles to meet your organization’s requirements. Once the roles are defined, then security groups define the permissions for each.   Here are the general steps for defining PMO roles and security groups for resources:  Determine the resource roles in PMO. Define security groups for each resource role. Define permission for each security group with both global permissions and category permissions. Configure and test your security group and verify that the security groups meet your PMO requirements. Default Resource Roles in Project Server Microsoft did a pretty good job with defining basic roles when it designed Project Server. The default basic roles encompass these: Administrators: Given to one or two people who can read all or modify any information in Project Server. The main aspect of this role is configuration of Project Server; but often it’s the person who manages resources and projects. It’s the most powerful role, and thus only a few people should have it. However some departments may need limited administrative rights for updating enterprise custom tables or managing their side of the resource breakdown structure (RBS) and may need a Departmental Administrator (covered below). Executives: Provides the ability to see any data in Project Server but has no permissions to modify data. It makes sense for upper management to have this role to enable them to see 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 (covered below) may be required. Portfolio Managers: Controls the configuration of the portfolio analyzer and requires modifying many different projects to model “what-if” scenarios. Portfolio Viewers: Similar to the executive role but limited to specific programs and projects. They generally don’t make major configuration changes and often view the results that come up from the portfolio manager. Project Managers: The PM role is to plan and execute the project schedule. They’re responsible for completing the project in a timely manner and under budget and update the project schedule weekly or as it requires. Often they also manage the resources in the project schedule. Other times, an organization assigns a resource manager to manage the resource loads in a project schedule. Resource Managers: This role works with the PM and allocates resources in a manner as to not overburden them. In an ideal world, the PM requests 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 PM and resource manager roles are both given to the PM, and he or she is responsible for both sets of duties. Team Leads: Grants a team lead limited control of a project schedule to reallocate resources and reassign team member assignments. Team Members: All new work resources are assigned a team member role. Some of the basic functionality is the ability to sign into Project Web App to enter timesheets or task sheets. Everyone in the project is assigned this role by default. With each Project Server role a security group is defined with basic permissions already associated with the role. In my experience, 9 in 10 PMOs will be happy with this set from the start. In fact, I usually suggest that organizations go with the out-of-box roles and security groups because it makes deployment so much easier. New Resource Roles to Consider After a customer has used the tool for a few months, however, he or she may decide to refine the user roles and security groups. When new roles are needed, the next step is to determine the permissions required for each. There are a lot of category and global permissions to consider, but once it’s done, a big part of your PMO security will be defined. Here are few roles that may come up on your list: Departmental Administrator: A stripped down version of the Administrator that allows the person to update custom enterprise tables or update RBS and categories. Departmental Executive: The same as the executive role but with permissions to see data within a given department. Day to Day (D2D) Manager: Similar to a project manager with this difference: He or she allocates resources for operational and business-as-usual activities. Resource Member (PPM Member, Work Member): The resource member has the identical permissions as a team member. The reason to create this role is so that it requires deliberate action to add the role to the work resource. Sometimes you don’t want a team member added to the new work resources by default; this role stops that from happening. When using this role, the team member role is configured without any permissions. EPM Resource Pool Manager: Controls the management of adding, updating and removing resources in the enterprise pool. EPM Resource Manager: Controls and manages resource allocations and schedules for many projects and can also level resources. Delegation Manager: Sets up delegation and works on behalf of resources. This provides a measure of control and limits the “surface” of having others setting up delegation for administrators. Timesheet Manager: The person who enters and submits timesheets for a group of resources. The resource roles I’ve covered here address special requirements within the PMO, providing a more nuanced way to control resources. You should note that implementing new roles removes permissions from other groups. So be sure to review and discuss each role to make sure it makes sense for your organization. Does your PMO use roles not covered here? Let me know in the comments below. A version of this article first appeared on Michael Wharton’s blog, MyProjectExpert. Image Source   

Showing PMO Love Through Monitoring and Automation

  Project Management Institute (PMI)® Professional Development Units (PDUs): This Webinar is eligible for 1 PMI® PDU in the Power Skills Category of the Talent Triangle. Event Description: PMO spend a lot of time planning and developing governance to build a smooth running PMO. Extensive documentation is written that documents the PMO people, roles and processes. The problem is nobody wants to read the documentation and memorize all the rules. It’s hard to verify that processes are being followed. In this webinar we will explain how centralized data containing project and resource information will make it much easier to monitor and manage PMO governance thru automation. Topics covered: 1. What is PMO governance and why it is important? 2. Examine a few general PMO processes and cycles and how they can be monitored using project server and automated reports. 3. Project schedules governance and templates. 4. We will examine a few key points on what to monitor in a resource profile and resource over allocation 5. Next steps for further monitor and automated your PMO governance. Presenter Info: Michael Wharton Michael Wharton is a Project/SharePoint Consultant and Trainer. Michael’s career started as a software developer before moving into project management. His passion to improve project management processes began in 2003 using tools like Project Professional and Server. Since then he has trained hundreds of project managers and implemented Project Server in over twenty-five PMOs. He has passed over forty Microsoft certification exams giving him a solid technical background with Project and SharePoint Server. Michael is active in the community. He is the past President-Elect and past Director of Programs for the NC Piedmont PMI, board member of the Triad SQL Server User Group, Triad Developers Guild and Enterprise Architect Roundtable. He is currently writing a book about implementing Portfolio Management using Project Server 2013. Have you watched this webinar recording? Tell MPUG viewers what you think! [WPCR_INSERT]

The Challenge of Capturing Timesheet Comments

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 met their requirements, 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 that the project manager’s comment or blank comment overwrites the existing comments. For my client, the solution worked well because they were not using the status field. However, most of my clients do, so I decided to dig deeper into this issue. I discovered that the server configuration was also playing a big part in how and when timesheet comments were overwritten. The following are a few scenarios where statusing doesn’t overwrite timesheet comments: Single entry mode is enabled, the resource timesheet manager and resource are the same person and the project manager doesn’t approve time for statusing; Task Manager is enabled and resource is auto-approved; Task Manager is disabled and resource is approved by the timesheet manager; and Sometimes “Fix Approval Routing” is enabled to prevent timesheet line approval. (If you have more to add to this list, I hope you’ll comment after reading the rest of the article!) Deep Dive into Timesheet Comments Determined to find a good solution for timesheets comment, I took a look into the data flow of timesheet line comments in the Project Server database. My thinking at the time was that the comments are saved somewhere in the published database or that a transaction log file had a history of the comments. My theory didn’t pan out as I had 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 was updated and saved, 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 queried the PUB.TIMESHEET_LINES and found that each time a timesheet was saved, the comments could be tracked down in the TS_LINE_COMMENT field from the PUB.MSP_TIMESHEET_LINES table. At some point users submit 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 forwarded to the timesheet manager. Several things happen at this point. First, 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 noticed that with different Project Server configurations, Save sometimes saves records in both tables. While watching both the PUB.TIMESHEET_LINES and DBO.MSP_TIMESHEETLINE tables and performing an approval, I found that the approval often overwrites the timesheet comment with notes such as “[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. One Hope on Timesheet Comments Capturing additional details about work using timesheet comments has many limitations. Most Project Server configuration can cause timesheet comments to be overwritten. If you’re only using the timesheet feature of Project Server, then this feature may work for you. Timesheet comments will be saved and generating detail work reports with comments may work fine. However, if statusing is part of your governance or if Project Server is set to single entry mode, then approvals will overwrite and lose your comments. There is one hope that can make this work for all scenarios. Project Server provides server-side event handlers that can be used to capture your timesheet comments. Specifically, the [Timesheet Submitted]” event handler can capture the timesheet comments and write them into a separate table before other approvals override them. A little time is needed to be invested in creating this solution because it requires custom coding and connecting the custom code to the event handler. While it may sound complicated, there are some great coding examples found on MSDN. Please post your comments if you’ve found a better solution for managing timesheet comments. A version of this article originally appeared on Michael Wharton’s blog, MyProjectExpert. Image courtesy of Marjory Collins, via Wikimedia Commons    

Book Report

How To Help Your PMO Generate Better Management Reports

Every Project Management Office (PMO) 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 strong and structured to 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 almost nine in 10 PMOs require (according to PMI surveys): reporting to upper management. So the first thing that comes to my mind about reporting is, how accurate is the data? Good data and valid reporting go hand-in-hand. Upper management expects accurate reports for making the right decisions. For the purposes of reporting Project Server offers several ways to track progress and tasks on projects, as shown in the first figure below. This setting can be changed on the fly, but I don’t recommend doing so. The main reason for not changing a tracking method 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 changes within projects already created, which may cause confusion. In fact, changing the tracking method places Project Server into “free form” mode. Microsoft Project Server and Project Online offer four tracking 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’ll tweak a few other settings to make the data more accurate. The options are set in the “Task Settings and Display” under the “Server Settings.” Percent of work complete. This popular option provides a good read on how a project is progressing and provides decent feedback on what’s complete or not. The main drawback of using this option is that actual work and actual costs is often not accurate. Depending on the task type used and the skill of the project manager, the actual work can be inflated when the duration is extended or when a task is marked 100 percent complete, which is interpreted as actual work rather than planned work. Actual work done and work remaining. This is a better option because it ensures the accuracy of actual work. My only issue with it is that it doesn’t require time periods and doesn’t have to be done on a recurring cycle. You can’t tell if a week has been skipped. Hours of work done per period. This is an even better option than either of the two previous choices. It requires using time periods and thus makes it easier to determine if time is entered each week. If actual work isn’t tracked weekly, it’s easy to lose work done. This is the best option of the three for measuring actual costs, work and scope achieved. However, as much as I like it, there’s an even better solution called Single Entry Mode, which, when enabled, turns on hours of work done per period. Free form is the final option. It may be best for organizations that have weak PMOs and can’t define and mandate a standard. Because of the inability of a PMO to define a tracking standard, this option would be my very last choice. A few other configurations that should be considered for obtaining accurate data for reports are on this same page. You might want to choose the checkbox, for example, that forces everyone to use the same tracking method. Consistency and governance are crucial for increasing data accuracy. The option, “Only allow tasks via Tasks and Timesheets,” should also be checked. This forces actuals to come in from PM entries, preventing the PMs from creating “actual work” data by marking tasks 100 percent complete. At this point, your basic tracking method is in place and accurate data is being fed 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. The Timesheets setting provides the most accurate data in your reports — and at the same time will generate the most opposition among your users. Task sheets can look like timesheets; and just saying “Timesheets” makes everyone feel like they’re punching a clock. Timesheets provides the PMO more and better information than task sheets. Timesheets also implies regular submission of work done each week, which in turn feeds into having better and timelier data. Let’s say a person works 10 hours on a project in one week and zero hours on the project the next week. When Timesheets is enabled, the PMO might require 40 hours to be reported. So the person might submit 10 hours of work on the project and 30 hours on other non-project tasks. When timesheets are part of the PMO monitoring cycle, the project manager can determine that resources have submitted their work efforts. In this person’s case, the PM can tell that she did non-project work, not that she simply forgot to submit her time. Timesheets can be a separate process for submitting actual work. When I refer to timesheets, I am actually referring to Single Entry Mode, which does several things. The timesheets and task sheets are combined on a single form and the task setting is set to “Hours of work done per period,” whether project related or not. Single Entry Mode is enabled in the server settings under the “Timesheet Settings and Defaults,” as shown in the screenshot below. As you can see from the form, there are other configuration settings too, such as those related to defining the governance of approval and when timesheets need to be submitted. In summary, the key points I want you to take away are these: First and foremost, if you’re in a PMO, a key requirement of your job will inevitably involve reporting project status in some form to management. The reports you develop need to use accurate, timely data. Single entry mode, through Project Server, is a handy setting to know about in achieving this goal. A version of this article originally appeared in Michael Wharton’s blog, MyProjectExpert. Image courtesy of Juhan Sonin — CC 2.0

  • 1
  • 2