Workflow and Demand Management
Published: May 2010
Demand management is a new concept in Microsoft Project Server 2010 that integrates project proposals, portfolio analysis, and project management through workflows and project detail pages. The goal of demand management is to enable users to propose, view, categorize, prioritize, select, and track projects within their organization.
This article contains the following sections:
For an introduction to the processes of demand management, see Hitchhiker’s Guide to Demand Management (white paper).
The demand management process captures all work proposals in one place, guides the proposals through a multistage governance process, helps users make decisions about which proposals to approve, and tracks progress on project execution until the work is completed. A key component within demand management is the workflow governance model implemented in Project Server.
The project proposal feature in Microsoft Office Project Server 2007 helps capture demand in one place, but is not flexible and does not incorporate a governance workflow. The Builder module in Microsoft Office Project Portfolio Server 2007 is a flexible demand management process, but does not have the Project Server and SharePoint look and feel. The Portfolio Server 2007 process also has some usability and scalability problems. The demand management process in Project Server 2010 is designed to be both flexible and usable.
Later releases of the Project 2010 SDK will contain information about how to create and deploy workflows and project detail pages. Articles on Microsoft TechNet and Microsoft Office Online will include detailed information about how to manage and use workflows for demand management.
Developers can create governance workflows that enable complex life cycles for project proposals or demand in Project Server 2010. A demand is any proposal that requires resources, such as personnel, time, or financing.
A governance workflow includes definitions of the life cycle stages through which the project progresses, for example, proposal creation and initial approval. The workflow sets the information that is required or locked in each stage. For example, a workflow can lock budget cost after the project is approved. A workflow can include necessary manual approval or notification steps and add business logic to update other LOB systems. For example, a workflow can update an enterprise resource planning (ERP) system when the proposal budget is approved.
The Project Server workflow platform (Figure 1) is built on the SharePoint workflow platform, which in turn is based on Windows Workflow Foundation (WF). Workflow is a key component of demand management.
A Project Server workflow runs on a Project Web App site and helps to manage a sequence of activities or alternate sets of activities related to project management, such as Check Project Custom Field Value and Publish Project.
Project Server workflows are of the "site" type, which enables a workflow to apply to an entire SharePoint site. A site workflow removes the restriction that a SharePoint workflow can be started only on a list item. Project Server workflows are deployed to Project Web App, and a workflow instance can be run only on a project entity.
Figure 2 shows the high-level processes for workflow creation, administration, and use. There can be one and only one governance workflow instance associated with a project at any point in time.
Project Server workflows must be created in Visual Studio 2010. Project Server workflows cannot be created in Microsoft SharePoint Designer 2010, because configuring the Project Server workflow activities requires programmatic access to the Project Server Interface (PSI). Visual Studio 2010 is able to deploy site workflows directly to SharePoint sites.
The administration of Project Server workflows is identical to managing any other SharePoint workflows, thereby providing more consistency between Project Server and SharePoint Server and reducing redundant work. Workflow instances are created when a project proposal is created and are deleted when the project is deleted, rejected, or completed.
Unlike in SharePoint Server 2010, a user does not start a workflow instance from the administration page that lists all the Project Server workflows.
For more information about configuring Visual Studio, and developing and deploying a Project Server workflow, see Developing Project Server Workflows.
In project portfolio management, a project life cycle is a long-running process that spans governance phases. Typical demand management phases are create, select, plan, and manage. The planning and management phases are accomplished by the more familiar project management processes by using Project Professional and Project Web App. Workflow models the governance processes and provides a structured way for projects to proceed through the phases. Workflows, along with other proposal data in project detail pages (PDPs), are captured and integrated within the demand management feature set, providing a rich and dynamic platform on which customers and partners can build custom solutions.
Figure 3 shows the four phases of demand management and how they fit together. Within each phase are stages such as Propose idea and Initial review. Each stage can have an associated PDP in Project Web App. The entire collection of stages represents a single workflow that can be linked to an enterprise project template (EPT).
Enterprise Project Templates
An enterprise project template represents a wrapper that encapsulates phases, stages, a single workflow, and PDPs. Each EPT represents a single project type. Normally, project types are aligned with individual departments, for example, marketing projects, IT projects, or HR projects. Using project types helps to categorize projects within the same organization that have a similar project life cycle. For a user, the EPTs appear in a drop-down list of project types when the user clicks New Project on the Ribbon in Project Web App.
Phase: A Collection of Steps in a Project Life Cycle
A phase represents a collection of stages grouped to identify a common set of activities in the project life cycle. Examples of phases are project creation, project selection, and project management (shown as Create, Select, and Manage in Figure 3). Phases do not have any direct technical effect on the behavior of an EPT. That is, changing the order of phases does not affect how the system reacts. The primary purpose of demand management phases is to provide a smoother user experience where users have the option of organizing stages into logical groups.
Stage: A Step in a Project Life Cycle
A stage represents one step within a project life cycle. A stage is composed of one or more PDPs linked by common logic or theme. Stages at a user level appear as steps within a project. At each step, data must be entered, modified, reviewed, or processed.
At a technical level, each stage represents a step where data is manipulated before the workflow can move to the next step. For a single-stage workflow, very little programming is involved. The user enters all of the data in one PDP, and can then work on the project as she normally would. For a multistage workflow, each stage is separated by an activity (SetProjectStage) within a Visual Studio workflow diagram. The actual SetProjectStage activity acts as a marker between stages and sets default properties of the next stage. The activities that follow SetProjectStage outline the actions that must take place within the next stage.
The actual stage itself is not created within Visual Studio. The stage must first be created in Project Web App. After the stage is created, you can link to that stage within Visual Studio.
Project Detail Pages in Stages
A PDP represents a single Web Part Page in Project Web App. PDPs can be used to display or collect information from the user. You can create PDPs in much the same way you create any Web Part Page in a SharePoint site, where you can add Web Parts that provide the experience you want. You can add individual Web Parts from the standard Web Part galleries or create custom Web Parts.
Project Server Web Parts and custom Web Parts used in demand management all contain custom fields. Web Parts can make calls to the PSI, query the Reporting database, or integrate with external systems. Figure 4 shows the general hierarchy of the parts of demand management in Project Server 2010.
Workflows are associated with the stages. From a programming standpoint, PDPs are not actually referenced within the workflow. The PDPs simply act as containers to hold or display data. The workflow references custom fields in the Web Parts.
For more information and some scenarios where PDPs are used, see the Project Detail Page section in What's New for Developers.