Quick Links

Reply To: Support Required For Ongoing Project Pro / Project Online Installation

Home Forums Discussion Support Required For Ongoing Project Pro / Project Online Installation Reply To: Support Required For Ongoing Project Pro / Project Online Installation


Our firm is running Project 2013, Project Server, and we use single entry mode for timesheets. We have about 250 PMs with at least that many concurrent projects in flight. Average project size is about 7-9,000 hours with larger projects into the 100K hour and above range. We also have about 3,000 enterprise project resources assigned to those schedule who also enter timesheet data every Friday. We have a very tight security environment with well defined delineations of access and management authority (PWA Settings).

The amount of support will depend these factors, the number of internal processes required to produce the back end metrics, and how picky management is about the quality of the back end metrics. Meaning, if all management cares about is if the project is still active or completed, many of the bugs/problems we’ve encountered won’t be an impact. If management wants quality, explainable metrics, count on spending more time due to tool bugs.
We’ve found the tool itself has lots of bugs (no other way to put it). For example we’ve had project actual start dates up to 2 years before the first actual timesheet hours were entered. We continue to have issues with the tool adding future actual work of zeros to random tasks that end up setting the project completion date to be months/years after it actually completed. In single entry mode, the PMs can’t simply just type over these issues to fix them. This may not sound like much but when PMs are being measured on project duration compared to baseline, these types of issues are major problems that take a lot of time to research and debug. As a result of these types of issues (which over the past year+ to MS supports credit have been reducing), we shut down the Project environment once a week from the PMs so that we can open the environment with all security lifted and manually correct problems such as those noted above.
We’ve also found the quality of the Cumulative Updates (CU) to be rather suspect (I’m trying to be nice). CUs do not appear to be thoroughly tested and often introduce new problems, some of which would have shut down our environment had we not caught them ahead of time and skipped implementation of that specific CU. For example, several months ago, a CU reduced the size of a resource record field and as a result, we found in our test environment we couldn’t open schedules with resources impacted by this change and we couldn’t assign new resources to any schedule. As a result, we couldn’t access about 50+% of our schedules.
We also heavily use task level codes and a CU about 8 months ago was nice enough to wipe out all the task code values on each task when the schedule was saved. Fortunately, we caught this in CU testing and did not implement that CU. Bottom line we spend a LOT of time testing basic MS Project Server and PRO functionality with each CU.

So why did I provide all that background? So that there will be a context as to why our environment has two MS Project support teams.
The first team is the MS Project Tool USE support staff. It contains about 5 full time resources to support the PMs using the tool, research tool usage problems, develop processes/standards, and research bugs. Additionally, this team provides MS Project use training at a level above fundamentals. Meaning, what are our processes and how does our organization use the tool.
Our second team is the MS Project TECHNICAL support team of about 5 resources as well. Their role is to manage the technical environment (servers, SharePoint releases, install CUs and new releases) and also support the tool from a technical perspective. They are our team that interfaces with our primary MS Project support contact when trying to resolve product bugs.

In summary, there are many factors that will contribute to your support environment needs. Some are obvious (environment/server support) and some aren’t (data metric quality).