Years ago I had a request from a customer to get Project Server to show where in a project lifecycle a project currently was. A simple solution was to create a project custom field using a look up table that held the lifecycle values observed by the customer. We then configured a Project Centre view that showed projects grouped by lifecycle stage.
The only problem with this solution was that it was dependent upon manual updating of the project field value in the project client and like as not there were often situations where a Project Manager either failed to update the value to reflect the current stage or they thought they had done it when in fact they hadn’t.
Eventually by constructing some task and project level fields with fairly tortuous calculated values it was possible to provide an automated perspective on where projects were in the project lifecycle. However the calculated fields approach was a less than ideal solution and did have an impact on server performance which was ultimately deemed unacceptable so we reverted to manual updating and all the pitfalls that it entailed.
With the launch of Project Server 2010 Microsoft introduced the concept of “Demand Management” and all of a sudden we had EPTs, PDPs, Project Server Workflow Phases and Stages and most intriguing of all “Workflow Controlled Fields” – unearthing the implications of this attribute of Project Level Enterprise Custom Fields took a while but eventually my eyes were opened to its potential.
One significant result of the new features introduced in Project Server 2010 is that it is now possible to show where in a defined lifecycle a Project currently resides as a function of the project being created and subjected to Project Server Workflow.
Given that different organisations observe differing lifecycles and project governance processes there is not an “out of the box” solution provided by Project Server. What it does provide is the elements you need to construct an approach aligned to your established processes for project lifecycle and governance.
There are several elements that together deliver visibility of Project Lifecycle Status and this is the first of five separate articles that will illustrate how these various elements combine.
Before delving into the details it is worth clarifying things at this point. Project Server Workflow as a term can be misconstrued by those who are new to Project Server. In a SharePoint environment a Workflow will typically infer that an action by one user will result in a request for action or response from someone else, for example you submit a document for approval using an Approval Workflow and someone else will be nominated to review and either approve or reject the document.
Project Server Workflows on their own do not require action by someone else when a project is submitted to a Project Server Workflow, a Project Server Workflow reflects the “Lifecycle” process for a project from inception to completion.
A Project Server Workflow can have a “Site Workflow” associated with it and the Site Workflow can be configured to require approval by one or more people.
I hope that clears things up. I personally think the term Project Server Workflow is a bit unfortunate in that it can suggest something other than what is intended. I tend to regard a Project server Workflow as being a representation of a Project Lifecycle model or process.
[ribbon_new header=”h2″ style=”light”]Workflow Phases [/ribbon_new]At first inspection Project Server Workflow Phases are not the most illuminating of features, defining a Workflow Phase involves just two elements, a name and a description.
Having defined a Workflow Phase you may then be wondering why you have done so? You can regard Workflow Phases as providing a structure within which Workflow Stages can reside.
The following is lifted straight from the Technet article covering workflow for demand management in Project Server 2013.
A demand management phase is used to organize multiple stages that make up a common set of activities in the project life cycle. Examples of phases are project creation, project selection, and project management (represented in the default Project Web App phases as Create, Select, and Manage). The phases themselves are just a way of organizing your stages and do not determine the order in which the stages are executed. (The order of the stages is determined by the associated workflow.)
To the uninitiated the description may appear to be superfluous as surely the workflow phase name says it all. However the description is there for a reason and should be invested with suitably descriptive text.
Furthermore I would suggest that it is a good idea to prefix Workflow Phases with a numeric value. The reason for this is that it will establish the order in which Workflow Phases are listed and also displayed which can make comprehension and management just that little bit easier.
As you can see in this example the numeric prefix establishes a logical order for the Workflow Phases from Create to Finished – if these phase names were not prefixed they would be listed alphabetically so you would end up with:
If you have OCD this would probably ruin your day.
The benefit of listing out your Workflow Phases with numeric prefixes is that it will be easier to envisage the full workflow from inception to completion and when designing “Site Workflows” to select the appropriate stage within the hierarchy of the phases. If this all sounds a bit convoluted please be patient, all will become apparent when I move on to exploring Workflow Stages in my next article.