| Agile Product Lifecycle Management Product Portfolio Management User Guide Release 9.3.3 E39293-05 |
|
 Previous |
| Agile Product Lifecycle Management Product Portfolio Management User Guide Release 9.3.3 E39293-05 |
|
Previous |
This chapter describes the best practices that you can follow to derive the most value out of PPM to meet your business needs.
This section provides recommendations on:
Process Definition and Acceptance
Implementation Realities and Requirements
Any enterprise Project Execution and Management implementation requires a defined process or processes, and general acceptance or mandates that these processes will be followed. No automation or system can work if the stakeholders and solution constituents are not participating. The process or processes do not need to be fully developed, but they must be accepted and followed. As the system is used, processes will show their weaknesses and standard process improvement logic will apply.
The following are key areas for consideration before you turn on the computer:
Define the process and process steps that need to be managed. Start from the key milestones and gates, and work backward to the tasks that need to be accomplished, and the deliverables that need to be met.
Get general consensus from key stakeholders to ensure process adoption and compliance; or appoint an executive sponsor who will mandate that the process is followed.
Determine how many project types (templates) you need. It is probably more than one and less than 100. Start simple and grow into complexity.
Decide the categories in which you classify your projects and programs: Business unit, geography, demographics, customers, markets, and so on. These are critical to the ways in which PPM will build and control access to dashboard portfolios. Some categories will be used as security filters, and some as convenience filters.
Take the schedule agreed to in the preparation stage and determine the initial depth of tracking required to manage your first pass. It is recommended that you start at a maximum of 4 levels of task indentation, which gives you the phase level, summary task level, and detail task level. For many organizations, this is deep enough with granulation covering the major items to be tracked. Later on, when the process has been refined, there may be value in going into deeper layers, into a deep Work Breakdown structure.
Decide how deep your initial implementation needs are to track resources. It is advisable that you run the system with minimum expectations for resource management until you are confident of the process schedule, timing and sequence. Detailed resource planning against unreliable and erroneous schedules and durations can be frustrating and lead to distrust of the system. With the power of the template, it is not difficult to assign resource requirements to tasks in the system, but if the tasks are not correctly aligned in the schedule or in their duration, the resulting resource utilization calculations will also be out of alignment.
Understand the limits of coexistence with other project tracking systems. PPM adds value as a real-time enterprise project management solution. As such, changes made to projects and resources are made in real-time, providing up-to-the-minute task requirements, project health and status, and resource requirements. Projects that are managed in other systems and then uploaded create a set of reports and assignments that are only as accurate as the last uploads.
Guidelines for general administrative setup and project-specific setup are detailed in this section.
Security
Agile PPM uses the PLM security model, and treats all users in an Agile PLM implementation as potential project participants. All default roles in PPM have default configurations but can be enhanced or reduced to meet internal security requirements. See the security section of the Agile PLM Administrator Guide for more details. Guidelines on the use of PPM roles and privileges:
Project Manager - Use as delivered. The Project Manager has access to all PPM objects that he or she owns or is authorized to access. Understand that a project manager is given access to object types; project owners are given access to specific projects. These two concepts work together.
Project Administrator - Use as delivered. The Project Administrator has specific privileges that allow access to projects that he or she does not own. He Or She can also cancel or delete projects, put projects on hold, or delete mandatory deliverables.
Executive Privilege - This privilege, used with the PPM dashboard and project categories, provides a single dashboard UI that builds a portfolio based on the user's executive privilege to access certain of those categories. Thus a General Manager of Business Unit 1 will see all projects for his/her business unit, while the General Manager of Business Unit 2 will see all projects for his/her business unit. Others may be authorized by markets, product lines, and so on.
|
Note: Agile Users - All Agile PLM users are potential participants as owners and resources of a project phase or task. When added to a project or added from a template, the participant is given an internal project role. Thus a development manager can be added to a project as the "project manager" of his or her group of tasks. This does not override the Project Owner's rights and access to all project activities. |
Resource Pools
In Agile PPM resources can be assigned to projects and templates as resource pools. These are user groups, identified as resource pools, that act as containers for groups of Agile users that have been identified as potential project participants.
Consider the following:
Pool Segmentation
Divide your pools with as much granularity as required to manage conflicts.
Set up pools to match departmental realities. Effective use of resource pools requires a resource pool manager that can respond to requests, overloads and employee issues.
Pool Attributes: Pools carry with them similar attributes as an Agile user. Key to the PPM implementation is the need to put a standard cost per hour in monetary value to the pool labor force. This is used at project creation time to calculate a standard cost labor budget.
Empty Pools: This is useful when you need to generate requirements and budgets for resources that may not have Agile access: contractors, partners, and so on.
Individual users - Any individual added to a project is a resource. Most, if not all, should be assigned from a resource pool. Ideally, no resource should be assigned to more than one pool.
The system uses the monetary values assigned in the user ID for standard resource costing when calculating labor budgets or actuals.
The executive privilege looks at the user profile and the categories assigned to that profile to allow viewing of projects that are not owned by that user.
Distributed Task Management (DTM)
DTM provides project participants with accurate real-time assignments and resource requirements, and direct access to the project without project navigation.
The following setup items should be considered to take full advantage of DTM:
"My Assignments" Configuration - This ensures that all project task owners and resources have a single place to go to get their up-to-the-minute task assignments and priorities. This UI is designed to provide dynamic and actionable access to all tasks that are assigned to a user without the need to "navigate" to the project. These tables, and the actions to be allowed, are configured in the administration setup.
"Quick View" Creation - Quick views allow users across PLM to review key details about an object and its data, directly from a list, without navigating to that object. Quick views are accessible from the "My Assignments" UI. PPM is the only module that has actionable and editable "Quick Views". (For information on how to set up "quick Views" see the Agile PLM Administrator Guide.) Every sub-class can have a different quick view, with different access levels. Thus the Quick View for DG1 (Decision Gate, Phase One) can have different editable fields and actions.
Dashboard Categories
Using the segmentation needed for project filtering and security determined in the preparation stage, create the categories and category values required for your implementation. This is critical to the dashboard, analytics, reporting and security. None of the default categories are fixed. They can all be renamed and re-sequenced for selection.
Timesheets
If you need to track hours spent against hours budgeted, with or without costs, you must enable timesheets in the setup.
Activity Sub-Classes (Types) and flex fields
The following sub-classes are delivered as defaults with PPM. They can mostly be used as delivered. Any sub-class that is not being used should be disabled to remove them from prompts and lists.
Project - Self explanatory. A project is defined in PPM as an activity without a parent. The object type does not necessarily define its behavior.
Phase - Used in phase gate management. Though decision gates are segmented for the phase in which they participate (DG1-DG6) it is not often necessary to have corresponding phase segmentation. However, if there is a need to have a similar phase segmentation, use new sub-classes such as "PH1", "PH2".
Task - Generally use as delivered. In some environments, another task type such as "Meeting" (with agendas and attendee lists) can be set up using a new sub-class.
Program - Use as delivered. Seen by PPM BI with a specific context when used with the PLM Reference Field on the Project Object.
Portfolio- Use as delivered. Seen by PPM BI with a specific context when used with the PLM Reference Field on the Project Object.
Milestone and Gate Sub-Classes (Types) and flex-fields
Gates are defined as any entry on a project timeline that does not have duration. Many project methodologies do not use the concept of a gate, though they do support "tasks" with a zero or single day duration or they support a milestone. Agile PPM uniquely supports gates of multiple types to support both phase-gate and standard project management environments.
The following gate types exemplify the best practice definition of gates for project management:
Decision Gates
Phase gate methodology divides a project into distinct sets of tasks called a phase. Each phase is bounded at the end by a decision gate. In phase-gate processes a specific phase (P1) is bounded by a matching decision gate (DG1). In "Stage-Gate™" processes a specific phase is (P1) is bounded at the end by the next decision gate, (DG2).
Decision Gates are most often used for Phase-Gate or Stage-Gate™ processes and management. However they are not restricted to these environments. Decision gates, as implied by the name, are points in time in the project timeline that require a major decision. In the context of Phase-Gate, this is often referred to as a "go/no-go" or "kill" decision, essentially asking the question: "Should this project continue to be funded?" In phase-gate, the gates are connected as the end of a phase so Phase One is bounded at the end by Decision Gate.
Decision Gates should be set up as sub-classes for cross project reporting.
Agile is shipped with several pre-defined sub-classes that are designed to be used as decision gates: DG1, DG2, DG3, DG4, DG5, and DG6. If your organization has a nomenclature already established for gates, you can rename these defaults to reflect your terminology.
Each gate sub-class can have gate specific data fields by enabling Page Three flex-fields. DG1 will have a different Page Three from all other gates.
Decision gate workflows should be configured to reflect the specific gate type.
Review (Checkpoint) Gates
Review or check-point gates are points in time on the project timeline that set a border for a group of tasks within a phase. Typically, they are used as a checklist to validate that a set of deliverables or tasks have been completed as required. These gates are not typically routed for approval, but reviewed for completeness.
The default checkpoint gate sub-class in Agile is the "Review Gate". If your process requires additional stratification of review types it is recommended that you add additional sub-classes as required. Examples would be: CP1, CP2 or RV1, RV2.
Workflows are not typically used for review gates.
Milestones
Milestones are also a type of gate. In many different project methodologies the milestone is the only gate type. In phase-gate methodologies, milestones are typically used to mark significant points in the project that can trigger other activities.
The default milestone gate in Agile is the "Milestone" sub-class.
Typically milestones are not sub-classed. However, if your process has milestones that are important to you as a metric or that are needed to measure progress across the portfolio, it is recommended that you add sub-classes to meet that need. Examples would be MM1, MM2, or MS1, MS2.
Workflows are not typically used for milestones. However, using scripting and events, you could trigger a notification to mark the passing of a milestone. For example, when a customer project reaches a milestone, a notification is sent to accounting to bill the customer for work completed.
Templates are an integral part of the best practice use of PPM. Templates are used at a minimum to establish the corporate baseline for a particular project type, such as NPD versus NPI. In more sophisticated environments, templates are defined by business unit or product line, or both, to set a standard process at the appropriate accountability level. Templates are also an integral part of using PPM in a project context that uses Phase-Gate methodologies. With templates, you can create a deep and broad schedule process that must be only set up once, and then used to generate thousands of activities over time. With templates, you can set up complex gate and deliverable controls, mandatory deliverables, deep accountability and team structures, and guarantee compliance with internal and external process control or regulatory agencies. (ISO, FDA, and so on.)
This section provides some practices to consider when setting up templates (or projects).
Schedules
Consider the following when setting up a schedule in a template (or project):
Depth of Schedule: Set as deep as your accountability levels and your ability to absorb. This will change over time as the system becomes more pervasive and schedules more accurate.
Avoid "checklists" converted to tasks: This is a common problem that creates 2000 task projects. If you need to track 2000 tasks, then do so, but do not convert checklists to task lists. Checklists are best left as documents, attached to tasks.
Use gates to set boundaries: Even if you do not follow a Phase Gate process, milestones and checkpoints are powerful tools to set boundaries of activities, establish formal reviews, and mark significant progress that is visible to all.
Set up all necessary dependencies to ensure schedule integrity of any projects created from that template. Setting up project dependencies is a daunting task. To ensure the consistent durations required to manage task sequence generally requires a complex matrix of dependencies. When you set them up in the template, 80-90% of all dependencies required for the projects generated from that template can be pre-defined and automatically created.
Ownership
Ownership at the phase, summary task, task, or gate level is set in the template using resource pools. Owners, by default, are not given a percentage of activity and as such are not considered part of the resource load. If the owner is active in the activity and the owner of it, set the allocation to a number >0 that represents their contribution. Then, when projects are generated from a template, resource pool requests for task owners are generated, and if the owner allocation is >0, a resource load is also generated. Agile PPM enables you to set ownership at the deepest level, without giving up the master control of the project/program manager.
Resources
Resources for phase, summary task, task, and gate levels are set at each level in the template using resource pools. For each resource required, enter the pool which represents the resource, and set an allocation that represents their required contribution. When projects are generated from a template, the project team and labor cost budget are automatically created; resource loads are set at the proposed or active level; resource requests are sent to the resource pools. Always set resource requirements at the task level that you can or must absorb. Avoid duplicating the resources at multiple levels. Typically this is at a minimum at the summary task level.
Content /Deliverables
Agile PPM is unique in allowing users to build all standard project deliverables in the template, and have the template automate deliverable creation and controls. All standard deliverables should be set in the template.
Digital File Content: File attachments such as documents, spreadsheets, and presentations can be set into the template as content or deliverables. The template can be set to recognize the content as static pulls from the vault, or copies of a boilerplate. Here are some examples:
Static Pull - You can establish a link in the template to an ISO process document, version controlled in Agile PLM, which triggers the template to copy the latest version of the ISO document to every project created from that template.
Boilerplates - You can attach a project deliverable boilerplate (that is, standard product requirements document) to a task or phase in a template and the template will create a blank copy of that boilerplate for every new project.
Agile PLM Items: PLM documents and parts/BOMs can be set as deliverables. For example, you can set-up a mandated project document, such as a Regulatory Requirements Document (RRD), as an item document sub-class in PLM. Create an RRD template object from that sub-class, attach a digital document boilerplate to that RRD and then attach the RRD document template to the project template. Every time the template creates a project, it creates a new RRD (RRD-2010, RRD-2011, and so on) with the digital file boilerplate, as content in the task that controls its due dates.
Agile PLM Processes: PLM process templates can also be set as deliverables in the template, and the template will create a copy of that process every time the template creates a project. For example, create a Part Number Request (PNR) process template, attach it to a task in the project template and every time the template creates a project, it creates a new PLM PNR in the content tab of that task.
PLM PPM Objects: Agile PPM activities and Gates can also be created in the template. You can set up a phase with 3 review gates, and a decision gate. Then, in the template, you can add the 3 review gates as content to the decision gate, and set up a relationship that will not allow the decision gate to go into review, unless all 3 review gates were open (approved).
Content Tab and Rules
Agile PPM is designed to control all deliverables and files from the tab on the UI called the "Content" tab. It is highly recommended as a best practice to disable the Attachments tab on all project classes (activities, gates) and place all project content including standard digital files into Content. This provides the highest level of visibility, control, and flexibility when working with deliverables.Approval Workflows
All gates and milestones in Agile PPM have a standard 3 step workflow, which can be enforced, and automated. As stated above, using PPM best practices, a template can establish for every NPD project that DG1 depends upon deliverables such as the three review gates being open, the PNR reaching release status, and a requirements document reaching review status. You can set up the rule to state at the moment the last deliverable rule is met DG1 will be set in "review" status on the gate workflow. This immediately notifies all approvers and observers of the gate process. Workflows for gate approval are essential is successfully implementing complex Phase-Gate procedures.
This section covers recommendations on general project execution and phase-gate project execution.
Consider the following process execution recommendations before implementing PPM.
Using the PLM Reference Field
This field can be found on the General Info Tab of any project. The PLM Reference field is the primary way to associate a project with a specific PLM object in the project context. The PLM Reference field is pervasive across the entire project structure. Items entered here will be visible (based on security) to all other levels of the project. It is primarily used to identify the product or products to be developed within the project. You can also use it to associate the project with other projects, programs, or portfolios. Multiple objects can be entered here. With the additional implementation of PPM Business Intelligence (BI), you can use it to associate projects with a portfolio or program, or both. When used with PPM BI, the following concepts should be understood.
Any portfolio or program object placed in the PLM reference field will link that project to those objects in BI.
The first Item object encountered on that will be used by BI as the product to be associated with this project for reporting and filtering.
Using Project Keywords
This field can be found on the General Info Tab of any project. Use this field to free-associate the project with concepts and categories (keywords) for searching and filtering.
Using the UI Navigator
The Navigator is especially useful for PPM users. Any project that is displayed can be "pushed" to the Navigator and used to navigate to other parts of the project, drag and drop deliverables, and maintain one project view while navigating to another.
Creating and Releasing Projects
PPM was designed to provide a multi-step process from creation of a project, publishing the project, and executing the project. The steps to follow, and their implications are as follows:
Create project from template in "Proposed" state. This sets up a project with all template constructs, resource requirements, and deliverables. However in the "Proposed" state, the project is not generally visible. In this state the resource requirements are set but not treated as firm. Thus they do not add a load to the resource calculations unless one asks explicitly for proposed projects to be added into the calculations. No resource requests or task assignments are generated. The "proposed" project state is enabled for use by project managers to manipulate the project after it is created by the template, to mold its timeline and work to meet the specific needs of the new project: that is, add or subtract tasks or resources; reset dates; assign specific resources to the project, and so on. All changes to the project are audited, and any new tasks added can be identified as not coming from the template. Also, at the time of creation, the user can choose to establish a baseline.
Change project state from "Proposed" to "Active". This action is in effect the publication of the project to the community. The project is now "Active - Not Started". The project appears on dashboards, resource pool requirements are sent to pool owners, and any tasks assigned or owned by unique users appear on their "My Assignments" tab. However, no activity is taking place and the project can be activated well ahead of its scheduled start date. The setting enables projects to be published with the lead time necessary to staff the first group of tasks with resources and for users to see their workloads with the time needed to prepare. The system will prompt the user to set up a "Kick-off" baseline.
Change project status to "Active - In Progress". This is done by any task owner marking any task as "In Progress". When the first task is set to "In Progress", the project and all activities out-dented from that task are also marked "In Progress".
Assign resources as needed, not all at once. Because resources and owners can be set to resource pools, even without resources assigned the system sees the load. Thus it is logical to allow project and resource managers to assign specific resources close to the events for which they are needed.
Using Dependencies
Setting up complex dependencies in a project is essential yet onerous. The template functionality enables you to set up a very complex dependency model once, and use it over and over. The stepped process to project publication enables Project Owners to adjust those standard dependencies to meet specific needs. Agile PPM supports two dependency constructs: schedule dependencies, and progress dependencies.
Schedule dependencies: Agile PPM supports 4 types of schedule dependencies: Start to Start (SS), Start to Finish (SF), Finish to Start, and Finish to Finish. These dependencies, when set, will link the dates of the interlinked tasks, and if any task is moved in time (rescheduled), any linked task is automatically moved to keep the durations constant, based on the dependency type. This is standard to all project management systems, and is essential to maintaining schedule integrity when rescheduling any or all project activities.
Progress dependencies: Agile PPM supports the concept of progress dependencies using the content tab of the project, phase, gate, or task and content rules. There are two types of progress dependencies:
Project-based: This links any task or gate to another task or gate, and establishes a rule that predicates the progress of one task or gate, based on the progress (status) of another. For example you can prohibit a gate from opening until several previous tasks have been completed, or you can prohibit a gate from going into "Review" until several milestones have been completed, or you can automatically open a new project phase at the moment the pervious phase decision gate is approved/opened.
Deliverable-based: This links PLM deliverables, and their status to the progress of tasks and gates. For example, you can prohibit the start of the prototype phase of a project until the BOM of the product has been set to "Prototype", and when it is set to "Prototype", it can be set to automatically open the prototype phases and tasks.
Defining Dynamic and Static Deliverables
Standard deliverables are those that can be pre-defined in the template and that are generated during the creation process. These have been discussed.
Dynamic deliverables are those deliverables that cannot be pre-defined. These can be broken down further in those that are anticipated, and those that are not anticipated.
Anticipated: Every project has deliverables that are required but are not specific until the project is active. The most common of these in the NPD process is the BOM (P/N) of the product to be developed. In Agile PPM, the PLM object that represents the BOM, once created, can be added to the project content at any level for control. The status of the BOM can control the progress of the project from one phase to another.
Unanticipated: Every project has deliverables/issues that impact the project and must be addressed. For example, during the test of a prototype, a major flaw is discovered. An Agile Change Request (CR) or Agile CAPA is launched to fix the problem. No further action on the project should go forward until the investigation is complete. The owner of the CAPA or CR can navigate to the relationship tab of that process and set a rule to prohibit the project task or phase from progressing until the CAPA or CR reach a certain status. (Security controls are set to control such activity appropriately)
With unique abilities to track deliverables and use them to manage the sequence and requirements of a project PPM provides the most effective platform for true phase-gate process management.
This section provides a series of guidelines to follow when using Agile PPM for Phase-Gate Project methodologies.
Phase-Gate Management
Phase Management:
Phases should be owned by their logical center of accountability: that is, the Director of Development should own the "Development" phase.
Phases should always be bounded by a decision gate.
Phases should be linked by schedule or progress dependencies, or both, to other phases
Resources assigned at the phase level should not be duplicated at lower indented levels (tasks) within the phase.
Decision Gate Management:
Phase-Gate processes suggest that all phases must have a decision gate with an approval process linked to them that controls entry into the next phase. Decision gates should be automatically controlled by progress dependencies. For example, set a phase decision gate to automatically go into "Review" or "Open" when all of the checkpoint gates, defined in the phase are set to "Open".
Decision gates should be routed for review/approval in alignment with the phase that it bounds. The routing should include all stakeholders that can verify and support the work completed in the current phase, those stakeholders in the next phase that can verify readiness and confidence in that next phase, project management that can summarize the project condition and health, and executive managers responsible for funding and resource management.
Decision gates should be baselined. Agile enables users to set multiple baselines. Decision Gates have a specific type of baseline called "Plan of Record". Every decision gate process should involve creating a "Plan of Record" baseline.
Task Management
Agile PPM is designed for two basic types of Project Management:
Centralized Task Management: Typical project management tools do not provide users with the environment to effectively manage a distributed task context. These systems focus all control and accountability for the project and all project activity on the project manager. Agile PPM can be operated in this fashion, simply by assigning ownership of all activity in the project to the project manager. This is done in the creation dialog or in the template.
Distributed Task Management: Agile PPM also provides for decentralized management of all project activities. Tasks are owned and resourced with resource pools. All activities that require resources are visible when released in the task owner's "My Assignments" home page.
Task Ownership: Task owners are free to manipulate the tasks they own, within the boundaries of the projects: secondary project managers. Set up task owners to represent the accountability associated with each phase, summary task, or task. For example, "Phase Two: Product Development" is owned by the pool "Development" "; the summary task, "Engineer Product Design" is owned by the pool "Product Managers", and the actual tasks needed to design the product are owned by the doers, that is, mechanical engineers for tasks needed for a box design, formula engineers for the tasks needed to create a formula or process model, and electrical engineers for the tasks to create a PCB. As soon as needed, but no sooner, ownership assignments are converted from pools to individuals from those pools.
Resources: Project participants can and should come from across the enterprise. When a project is created from a template, the system will copy all resource requirements as defined in the template "Team" tab into the project "Team" tab with an allocation >0. Typically all resource requirements are represented as a resource pools. At some point in the process, when needed, resource pool assignments should be given to individual resources.
Timesheets and Actual Standard Costs: It is recommended that organizations that need to track labor costs across a project enable the timesheet functionality. Users whose time tracking is not necessary can elect to not have the timesheet tab visible. When a user enters time spent into the timesheet, Agile will use the time entered and calculate an actual labor cost. The system will multiply the hours reported by either the hourly cost of the individual resource if available in the user profile, or if not available, by the hourly cost of the resource pool entered in the pool profile.
Agile PLM Business Intelligence (PLM BI) derives information from PPM projects to generate analytical reports. Follow the guidelines provided in this section to ensure that the metrics captured in the reports are accurate and meaningful. Usually, the following steps are required:
Configure PLM BI correctly
Use the PLM Reference number correctly
Ensure projects have the right structure
Keep in mind that Agile PLM BI provides an administrator the ability to configure the following using domain values:
Activity subclasses, to be configured as Portfolios, Programs, or Phases.
You can configure one Activity subclass as a Portfolio and another Activity subclass as a Program.
You can configure one or more Activity subclasses as Phases.
There are no configurations required for Projects and Tasks. PLM BI infers these based on the Phase domain value configuration and the structural hierarchy of the Projects. Therefore, it is extremely important to follow the hierarchy rules provided in the subsequent sections.
Gate subclasses, to be configured as one or more Decision Gates.
You can configure one or more Gate subclasses as Decision Gates. In addition to this configuration, the exact level and position of the Decision Gate plays an important role in ensuring that Decision Gates are displayed correctly within PLM BI.
The Gate dimension within PLM BI is populated using the Decision Gates configuration described above. The gates that are not configured as Decision Gates do not appear in the gate dimension.
It is recommended that you follow the rules outlined in this section while using the PLM Reference field in PPM for Portfolio, Program, and Product objects.
Portfolio and Program objects can be created within PPM using the Activity subclass. You can use the subclass type Portfolio or Program, or the exact name of the object as configured in your system. Portfolio and Program are expected to be created as standalone objects; these objects should have no child objects under them.
The PLM Reference number in the Portfolio or Program object can group the programs and projects within BI. Some fundamental rules for using the PLM reference number are provided here:
The PLM reference field in a Portfolio object can refer to one or more projects or programs, or both. However, you cannot use the PLM Reference field on a Portfolio to refer to other Portfolios.
A Portfolio cannot be aggregated as a collection of programs within PLM BI. Portfolio is shown as a collection of projects. If Programs are associated with a Portfolio, PLM BI will break down the Programs into referred Projects for display within PLM BI.
All projects in programs associated with a Portfolio are treated as belonging to a Portfolio.
The PLM reference field in a Program can refer to one or more Projects. You cannot use the PLM Reference field on a Program to refer to other Programs or Portfolios.
Typically, Projects result in one or more 'Products'. You can use the PLM Reference number on a Project to identify the Product. Only objects of type 'Items' are treated as Products and reference to any other type of object will be ignored by PLM BI.
The PLM Reference field is available from Agile PLM version 9.3 onwards. If you are a 9.2.2.x customer, use a Defined field (P2/P3) instead of the PLM Reference field.
Based on the domain value configurations for each Project, Phase, and Decision Gate, PLM BI 'locates' the object and makes hierarchical inferences, as explained below:
An activity situated one level above a Phase is considered to be a Project. As a result, it is important to have one and only one object above the Phase in a Project hierarchy.
Tasks are activities that are one or more levels below a Phase.
Decision Gates can be at same level as a Phase or one level below the Phase.
Therefore, it is necessary to ensure that you follow the guidelines provided here while defining project structure.
The following figure illustrates the Project hierarchy structures that are recommended:
For more detailed metrics on Phases, you can split Phase subclasses into Phase 0, 1, 2... and so on.
PLM BI does not support a Phase subclass under another Phase subclass.
|
Note: While it is possible to look at a flat list of all Tasks below the Phase, PLM BI does not maintain or display a tree of tasks. For example, in the above Project hierarchies, it is possible to get Tasks under Phase 1 such as Task 1.1, 1.1.1 and 1.1.2 but it is not possible to get a list of Tasks under Task 1.1. |
Due to data and functionality constraints, we recommend that you follow these best practices when using the MSP-PPM integration functionality.
As a best practice, create your project in PPM, then export to MSP and publish it back to PPM.
The integration process does support constraints, however, there are some limitations to maintain data integrity.
Constraint data is not supported in the following schedule-related scenarios:
Update XML Date element in xml like: start / finish date of task
Task is found in xml but deleted in PPM
Task has been cancelled in PPM
Task is changed to 0 duration in PPM
Task's duration is changed in PPM
Duration type of task is modified in PPM
Task parent outline number has been changed in PPM
0 duration task milestone value is changed
Text30 for task is empty or missing
New tasks are added in PPM
New dependencies are added in PPM
The predecessor of activity has been deleted in PPM
Dependency has been removed in PPM
Time buffer/type of dependency is modified in PPM
Multiple resource in MSP is mapped to same user
Assignment has been deleted in PPM
Resource allocation has been changed in PPM
New assignments have been added in PPM
Constraint data is not supported in the following resource-related scenarios:
Multiple resource in MSP is mapped to same user
Assignment has been deleted in PPM
Resource allocation has been changed in PPM
New assignments have been added in PPM
