Support Required For Ongoing Project Pro / Project Online Installation

Home Forums Discussion Forum Support Required For Ongoing Project Pro / Project Online Installation

Viewing 4 reply threads
  • Author
    Posts
    • #408747
      John Murphy
      Member

      We are in the process of rolling out Project Pro and Project Online to various groups at our company. I am spending 100% of my time on the setup and rollout.

      What ongoing support / staff is required to keep an installation going and growing?

      thanks
      John

    • #408748
      Norm Christensen
      Guest

      Hi John,

      I too went through this about 2 years ago and I was alone. I finally got permission to have a firm called Advisicon help me out.
      We are now in operational mode. My time dropped from 100% down to about 40%.

    • #408752
      John Murphy
      Member

      Thanks for the reply …

      What do you cover and what does Advisicon do?

      I am hoping others will reply too … I want to be able to let management know what is required on the average ….

      John

    • #408763
      Daryl Deffler
      Participant

      John;
      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).

    • #408765
      John Murphy
      Member

      Daryl,

      Thanks for the detail.

      We only have about 200 users of which about 80 are PMs and RMs. I am the lone Admin at this point. At this point based on your feedback I do not think just 10% of my time ongoing is going to work to cover maintenance, troubleshooting, training, etc. 🙂

      Appreciate it
      John

Viewing 4 reply threads
  • You must be logged in to reply to this topic.