Resource Types - Codes

For developers creating queries and SQL reports, this might be useful to know;

‘Res_TYPE’ field values in Published DB

1 - User NOT resource

2 - WORK Enterprise Resources

20 - Generic WORK Enterprise Resource

21 - MATERIAL Enterprise Resource

26 - COST Enterprise Resource

51 - BUDGET COST Enterprise Resource

101 - Inactive User (not resource)

Rules for Deploying Shared Service Provider

Before deploying an SSP, you will need a thorough understanding about the rules for deploying them. This topic discusses the rules for deploying SSPs.

The rules are as follows:

1. You can associate each Web application with one SSP only. To associated specific web application to a particular SSP, Change Associations is used. All WSS site collections and sites under the associated Web application inherit the use of the SSP. It is required that you associate all Web applications to SSPs. When you create the first SSP in your farm, the SSP is marked as the default SSP for the farm. All Web applications that do not have an explicit SSP assigned use the default SSP.
2. The application pool identity accounts of Web applications that will need to use a shared service from an SSP must be granted access to the SSP. The details can be specified in the SSP properties page as shown below.
   When you create a Web application, the application pool identity of the Web application is automatically associated with the default SSP.
3. All shared services exist as a tightly bound cluster of services. This means that if you create a SSP, it will contain all services. These services include user profiles, Excel services, BDC, search, and usage reporting. All shared services are turned on at the SSP level. For example, you cannot turn off the Search service and expect all other shared services to work correctly.
4. Every SSP you create must have an associated administration site. The administration site is used for managing application level settings and configurations for the SSP.

EPM Vs Project Standard

Why use EPM instead of Microsoft Project Standard?

EPM Provides a Centralised working environment to manage projects/activities. Benefits by Roles;

Project Managers (PM)

1. Use of Standard Enterprise work structure templates to plan projects/activities.
   • PMs simply select the most appropriate template to create their project plan or activity plan.
   • The templates have the 'core' work structure, with estimated durations and dependencies, already setup. PMs need to modify start date and certain key aspects of the new project.
   • Standard Enterprise Views for data entry/update. Consistent approach used by all PMs.
2. Use of Standard Enterprise Views for monitoring and tracking project/milestone progress. Consistent approach used by all PMs.
• Approving TM updates automatically updates projects
3. PMs can manage associated Project Documentation, Risks and Issues in a central secure location. The Risk and Issues can be assigned to other members of project team to monitor/track and resolve. Project Artefacts can be linked to tasks/activities on projects.
• Security/Access Control can be tightly controlled by owner
• Project Artefacts are version managed.
• Alerts for changes
• Discussions, Wikis, Surveys
• Workflow can set configured (MOSS)
4. Existing Business Processes can be Mapped to EPM processes. In using EPM, Project Managers can reduce time taken for planning, monitoring and tracking projects/activities whilst helping the business achieve the overall objective of improving the Project delivery/Management maturity level.
5. Status Reporting - Built-in workflow to request and collate updates from TMs
6. Built-in workflow to automatically disseminate individual assignments from a project
7. Use of Enterprise Baselines to track programme/project portfolio performance

Programme Managers

1. Programme Managers can create cross-project dependencies (Hard and Soft)
2. Review rolled-up progress on programmes and publish executives

Portfolio Managers (PPM)

1. Project Portfolio Managers can review progress on all their projects/activity plans in their department/division

Team Members (TM)

1. TMs can review detail of multiple projects they are working.
2. TMs can collaborate on Project/Activities;
• TMs review their 'work-stack'/assignments across multiple projects
• TMs report progress on projects assignments
3. Contribute in Project Status Reporting
4. Subscribe to built-in work-flows for Alerts and notifications (Tasks and Status Reports)
5. Subscribe to scheduled reminders for changes in artefacts or status of tasks.
6. TMs can work on project documentation associated with Project
7. Review and update project documentation
8. Review, monitor and update project risk and issue status.

Executives/Managers

1. As a by-product of PMs' managing projects in EPM, executives/managers gain 'real-time' visibility of Milestone/Phase and project progress, via flexible/customisable reports/views.
2. Executives can collaborate on Project artefacts (documents, risks and issues)
3. Built-in Workflow for requesting Status reports from PMs

PMO/PSO

1. Ability Manage best practice for planning by maintaining the templates based on completed project performance i.e. following LL and EOP report.
   • Improving on best practice and consistency of Project Management including planning is key progressing up the CMMI scale.

Resource Managers

1. EPM maintains a common ERP which is used by PMs to resource their projects
2. Manage Proposed and committed resource requirement on projects
3. As a by-product of PMs' managing projects in EPM, Resource Managers gain 'real-time' visibility of their resource demands.