none
Change Field Name in PDP RRS feed

  • Question

  • Is it possible to change the name of the Project Field in the Project Fields web part when used in a PDP?

    For example, if I add a field called [Project Stage] but I want to display it as "Project Stage X" in the PDP... can this be done with SharePoint Designer or through another technique?

    Monday, December 13, 2010 8:54 PM

Answers

  • John:

    There is no question that a high number of task-level fields, especially calculated fields, can slow performance. For Project Server 2007, running on 32bit platform, once you hit around 50 (calculated + noncalculated) you probably hit your performance limit. I haven't had a customer who has pushed it that far in a while, but I expect that on a 64bit platform and right server horsepower combined with the right type of drive arrays on SQL, you could push this beyond where you will need to go from a practical perspective.

    Not all calculated fields are created equal, and your mileage may vary.

     


    Gary Chefetz, MCITP, MCP, MVP msProjectExperts
    Project and Project ServerFAQs
    Project Server Help BLOG
    Friday, December 17, 2010 10:27 PM
    Moderator

All replies

  • I don't think that the project fields webpart which is used in the PDP would allow this without customization of the webpart itself.
    Jack Dahlgren blogs at:
    Project and Retrovention
    and rarely Twitter
    Monday, December 13, 2010 9:48 PM
    Moderator
  • You can do this farily easily for read-onlyl fields by referencing them as a formula in a custom Enterprise field.
    Gary Chefetz, MCITP, MCP, MVP msProjectExperts
    Project and Project ServerFAQs
    Project Server Help BLOG
    Tuesday, December 14, 2010 6:45 PM
    Moderator
  • Gary,

    In your experience with PS 2007 and PS 2010, what are the biggest numbers of such formula-type custom enterprise fields on tasks that you have encountered for various installations?

    I'm trying to understand the difference between the SDK documentation indicating that the number of custom enterprise fields is theoretically unlimited and the PS 2010 published thresholds for large project portfolios recommending 6-15 task formulas for acceptable performance.

    Thanks.

    --John 

    Friday, December 17, 2010 6:44 PM
  • John:

    There is no question that a high number of task-level fields, especially calculated fields, can slow performance. For Project Server 2007, running on 32bit platform, once you hit around 50 (calculated + noncalculated) you probably hit your performance limit. I haven't had a customer who has pushed it that far in a while, but I expect that on a 64bit platform and right server horsepower combined with the right type of drive arrays on SQL, you could push this beyond where you will need to go from a practical perspective.

    Not all calculated fields are created equal, and your mileage may vary.

     


    Gary Chefetz, MCITP, MCP, MVP msProjectExperts
    Project and Project ServerFAQs
    Project Server Help BLOG
    Friday, December 17, 2010 10:27 PM
    Moderator
  • Gary,

    It's a credit to your programming prowess to be comfortable with a working "limit" of 50 task-class custom enterprise fields in Project Server 2007, 2010. 

    Granted: When the paramount mission is accomplishing "out of the box" scheduling, we really don't need very many additional fields to get results.

    For most of the past decade, I have been working with resource modeling across fairly large R&D project portfolios. This has included scheduling requirements as well.

    Essential for long-range resource forecasting is time-phased intersection of WBS with RBS not only on individual projcts but across a given portfolio in multiple consolidations (reporting groupings).

    Automated calculation of planned effort through algorithms (parametric estimation) benefits from using many additional fields and formulas than pure scheduling questions generate.

    Each "leg" or functional area of the resource breakdown structure has distinctive ways to specify demand based upon complexity, test populations, sites, etc. (Majority of these  custom fields appear in the task entity as a single data point rather than duplicating the same information for a projects tasks into multiple resource areas.) Resource forecasting makes use of substantial numbers of drivers, multipliers, modifiers.

    For the "task entity" PS equivalent, I have over 700 non-calculating stored "custom task" fields and more than 2000 additional calculating formulas that are dynamically available when the application is running.  Architecture is object oriented and does not suffer from task-related performance penalties that may make PS become sluggish by accommodating too many formulas.

    Learning to solve problems within 30-50 such Project Server custom enterprise task field "slots" will be challenging. One suggested approach is to decentralize resourcing to department groups. This may seemingly simplify resourcing needs and reduce the number of task formulas needed in a given department's  instance of PS. Such a path will bring about a need for some form of synchronization across multiple Project Server instances--likely five or more plus a master schedule.

    Thinking back on Microsoft's documentation, the published thresholds have not changed signficantly between PS 2007 and PS 2010. Do you recall any mention that a 64-bit PS 2010 instance will gain higher thresholds for task field formulas (not to exclude resource field formulas) than what a 32-bit installation has had historically?

    I look forward to seeing how you treat resource modeling in your forthcoming title--which I have already pre-ordered this month.

    --John

    Monday, December 20, 2010 3:12 PM