EPMSource

A while back I wrote about how you could customise your Project Server instance to incorporate one of the great new features of Internet Explorer 9, Jump Lists. In the post we explored how through a little bit of JavaScript and a content editor web part a Project Server administrator could provide quick access to common links in PWA when a user pins the site.

As I had been spending a lot of time around demand management workflows recently, I started to wonder if it would be possible to incorporate workflow approval tasks onto an IE9 jump list. After a little experimenting, I am pleased to announce IE9 Jump Lists Version 2.0

What does it do?

Just like the previous release, V2 provides quick access to core Project Server functions for users that choose to pin the site to their Windows 7 taskbar. Unlike the previous version, it will also poll Project Server to see if any workflow approval tasks are outstanding for the current user, specifically any tasks that are not in the status of completed and add them to the pinned menu in a special ‘Workflow tasks’ area.

Clicking on an approval task form the jump list will open up the approval task within Project Server for the user to action the approval.

Finally, V2 will also notify the user via a handy notification icon to show when there are outstanding workflow approvals awaiting action.

To give you a more detailed example of what V2 can do, I have created a small screencast showing the major features.

How it works

The new version of the IE9 Jump lists leverages a fantastic jQuery library called Pinify that is designed to reduce the effort and time required to implement IE9 jump lists on a site as well as providing a number of additional capabilities including notifications, discoverability and thumbnails. In our particular case, I have leveraged pinify to provide the static jump list components and to provide the plumbing to display the dynamic workflow tasks and notifications.

The other main components of the solution are:

• Leveraging the SPServices jQuery plugin to poll SharePoint to get the currently logged on user
• Using SharePoint’s inbuilt REST interface to lists to poll the currently assigned Workflow tasks from the ProjectServerWorkflowTasks list
• Parsing the returned results via JSON
• And finally, displaying a notification to the user on the task bar when Workflow Approval tasks are outstanding.

I am not going to go into the specifics of the implementation in this post due to the solution being slightly more complex than its predecessor. Instead, I have wrapped the whole solution, associated graphics and JavaScript files into a simple to install SharePoint feature, the source of which and Visual Studio project is available to download from my Skydrive account. In order for you to use this yourself, all that is needed is to:

1. Ensure you have a Shared Documents document library in your PWA site

2. Open the ie9jumplist.js file in the solution and update the PWA URL and ProjectServerWorkflowTasks list id to match your environment

3. Compile, test, deploy and enjoy.

N.B. This code is provided as is. No warranty is provided. You are responsible for testing the solution prior to deployment. The author accepts no responsibility for anything that may happen as a result of installing and using this code, etc, etc.

Today Mark McDermott and myself presented our session on Building advanced Project Server workflows with Nintex Workflow for Project Server. The session covered three main areas where organisations can leverage Nintex workflow within their Project Server environments.

Demand Management – During the session we looked at some of the more advanced scenarios for building demand management workflows, leveraging some of the Nintex out of the box actions such as state machines and flexi tasks. We also looked at using some of the new V2 features including the Query Project Data action that allows the workflow to query the PSI directly from within the workflow.

Event Driven – We introduced the new capability of Event Driven workflows allowing you to attach a Nintex workflow to a Project Server Server Side Event providing a huge array of new integration and extensibility options for your Project Server farm.

Project workspaces -Finally, we showed how workflow could be provided in project workspaces to support a project team with a number of activities including approvals, routing and custom notifications. We also showed how easily workflows could be extended to integrate with cloud based services such as Office 365.

Try it yourself

We wanted to make sure that you could try everything that we showed in the session yourself, so spent some time building up three detailed ‘how to’ guides each covering a different area. Links to these guides as well as further information on Nintex Workflow, Nintex Workflow for Project Server 2010 and how to obtain trial copies are available from http://bit.ly/pc332.

A user in the Project Server forums asked a question this week about whether it was possible to add printing capability to the Project Detail Pages in order to allow the ‘forms’ to be printed out as there is no print button available on the ribbon.

Out of the box, the printing capability in the Project Web Application is limited to the grids, including the schedule grids that are visible in a schedule PDP and uses a custom page to render the information as can be seen below.

After a little experimenting with the Internet Explorer printing, it seems that PDP’s can be printed quite well directly from the browser, so I thought I would try and pull together a ribbon feature that enables PDP printing.

The feature consists of XML button definition and a little piece of JavaScript to determine if the button will be enabled or not. This is important so that the button can be disabled when the user is on the schedule page that has it’s own grid based printing function like the picture above. For the purposes of this feature, I have gone the quick route and do the check based on the name of the page, in this case if the page is called schedule.aspx the button will be disabled. You may need to modify this check if your schedule based PDP(s) have a different name.

The element.xml looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction Id="Ribbon.Tabs.PDP.Home.Print"
				  Location="CommandUI.Ribbon">
		<CommandUIExtension>
			<CommandUIDefinitions>
				<CommandUIDefinition Location="Ribbon.Tabs.PDP.Home.Groups._children">
					<Group Id="Ribbon.Tabs.PDP.Home.Print"
						   Sequence="60"
						   Description="Print Custom Group"
						   Title="Share"
						   Command="EnableCustomGroup"
						   Template="Ribbon.Templates.Flexible2">
						<Controls Id="Ribbon.Tabs.PDP.Home.Print.Controls">
							<Button Id="Ribbon.Tabs.PDP.Home.Print.PrintPDP"
									Sequence="40"
									Command="PrintPDP"
									Alt="Print"
									Image16by16="/_layouts/$Resources:core,Language;/images/ps16x16.png"
									Image16by16Top="-96"
									Image16by16Left="-160"
									Image32by32="/_layouts/$Resources:core,Language;/images/ps32x32.png"
									Image32by32Top="-288"
									Image32by32Left="-128"
									LabelText="Print"
									TemplateAlias="o1"
							        ToolTipTitle="Print"
									ToolTipDescription="Print the contents of the PDP"/>
						</Controls>
					</Group>
				</CommandUIDefinition>
				<CommandUIDefinition Location="Ribbon.Tabs.PDP.Home.Scaling._children">
					<MaxSize
						Id="Ribbon.Tabs.PDP.Home.Scaling.Print"
						Sequence="140"
						GroupId="Ribbon.Tabs.PDP.Home.Print"
						Size="LargeLarge"/>
				</CommandUIDefinition>
			</CommandUIDefinitions>
			<CommandUIHandlers>
				<CommandUIHandler Command="EnableCustomGroup"
								  CommandAction="javascript:return true;" />
				<CommandUIHandler Command="PrintPDP"
								  CommandAction="javascript:window.print();"
								  EnabledScript="javascript:
								  function disablePrintForSchedule() {
									var sPath = window.location.pathname;
									var sPage = sPath.substring(sPath.lastIndexOf('/') + 1);
									if (sPage.toLowerCase() == 'schedule.aspx')
									{
										return false;
									}
									else
									{
										return true;
									}
								   }
									disablePrintForSchedule();"
/>
			</CommandUIHandlers>
		</CommandUIExtension>
	</CustomAction>
</Elements>

The process of building the feature is exactly the same as outlined in http://epmsource.com/2011/12/13/hiding-disabling-ribbon-items-in-project-server-part-ii/ but substitute the above code into the Element.xml file and change the feature name accordingly.

Once the feature is deployed and activated a Print button should available on the PDP ribbon that when clicked will invoke the Internet Explorer print dialog.

From my preliminary testing, the output is pretty good, as can be seen from this ‘Print to XPS’ below:

I have uploaded the full source to Skydrive which can be downloaded from the link below.

Project PDP Print Page

Happy PDP printing

I know I promised no more Nintex posts for a while, but this week, Nintex announced the availability of the first beta of Nintex Workflow for Project Server 2.0, the latest version of the popular Nintex Workflow for Project Server product and I just had to post!

Version 2.0 provides a number of enhancements to the existing product, including the following changes to the demand management components:

• Change Enterprise Project Type from within the workflow;
• New Publish project workflow action – Provides the ability to publish the project that the workflow is associated with, ensuring that project information is kept up to date in the Published Database;
• Query Project Server (also available in Site / List Workflows) – Provides a direct interface to PSI methods that query or read data from Project Server; and
• Update project properties (also available in Site / List Workflows) – Update project properties using site and list workflows.

If the ability to query the PSI from within the workflow wasn’t compelling enough, version 2.0 also boasts one other new feature, which I think will be a game changer, the ability to associate workflows to the Project Server Event Handler engine .

Through using these new Event Driven workflows it is now possible to create workflows and then associate them to the Event Handler engine within Project Server. Some of the uses that come to mind immediately including:

• Create a simple audit workflow that logs who published, edited or updated a schedule to a SharePoint audit list;
• Alerting the resource manager whenever one of their resources are added to a project schedule via a workflow task and alert;
• Synchronising a lookup table with an external system, or a SharePoint list when the list is updated or checked in; and
• Alert resource managers when new users are created in PS requiring an RBS to be assigned.

I have only had a couple of hours to play with the beta, but can already see some pretty compelling reasons and scenarios for use. Stay tuned for a couple of cool walk throughs in the coming weeks.

The Beta is available to all Nintex Partners.

Disclosure: I am an employee of OBS, a member of the Nintex group. However, this did not inform this post, I really think it’s a great update to an already great product.

Recently I have been looking into how far you can integrate a Nintex Workflow for Project Server workflow into the day to day management of a project. One particular area I have been concentrating on is encoded logic within the workflow to check the status of tasks within the schedule. Imagine the scenario, a project can only move into the close phase if all the deliverables or milestones in the project have been met, or you may want the phase of the project to change following the completion of a specific task.

In this post I am going to explore using Nintex Workflow for Project Server to query a project schedule to determine if all the milestones within the current phase have been completed before allowing the workflow to move forward.

The Schedule

In order for the workflow to determine which milestones belong to which phase, it is necessary to record the phase information against each task. To do this I have added a new Task custom field called ‘Task Stage’ and entered the relevant stage into it for each  task.

The Workflow

For the workflow I am going to follow the same basic pattern used for the Stage Gate approval in this post, a variable controlled loop that will continue to repeat until a certain condition is met. Unlike the previous post, instead of a task being assigned to security group for approval, we are going to leverage another Nintex action, called Execute SQL.

This action, in my opinion is one of the most underrated actions in the Nintex suite, usually because it’s only used to query non SharePoint data stores (remember direct SQL lookups against the ContentDB are not supported and shouldn’t be attempted). However as Project Server has it’s own dedicated Reporting database which contains a wealth of information about each project including the schedule that can be queried, we can leverage the Execute SQL action to our hearts content.

To start with, I am going to create the plumbing for the workflow, starting with setting up the initial stage (Execution) and logging some status information. Following this, the workflow variable that will control the loop is set to False (Phase Milestones Complete) and finally the loop action is added that is set to repeat whilst the Phase Milestones Complete variable is false.

Inside the loop we need to add a few more actions, starting with the Wait for Submit action that holds the workflow until the Submit button on the ribbon is pressed and the Execute SQL action which is going to do the clever stuff.

To configure the Execute SQL action, firstly the connection string needs to be configured, in this case I have configured the action to look at the PWA_Reporting database using the contoso\administrator windows logon.

The core of the action is the SQL itself, which does a count of all records the current project that are:

• Milestones (via the TaskIsMilestone flag);
• 100% complete, and
• in the current stage

and stores the result in the variable ‘Outstanding Milestone Count’.

The full SQL used is shown here:

select count(epmt.TaskUID) as [Outstanding Milestones] from MSP_EpmTask_UserView epmt
inner join MSP_EpmProject_UserView epmp on epmt.ProjectUID = epmp.ProjectUID
inner join MSP_EpmWorkflowStage epmws on epmt.[Task Stage] = epmws.StageName
where epmp.ProjectUID = '{Common:ProjectUID}'
and epmt.TaskIsMilestone = 1
and epmt.[TaskPercentCompleted] <> 100
and epmws.StageUID = '43A1EB7B-562D-42E8-9A96-88817EF74295'

You will notice that we leverage Nintex’s ‘Insert Reference’ capability to inject the ProjectUID directly into the query on line 4, also their is a GUID hardcoded into the query on line 7, in this case it’s the is the StageUID for the Execution phase, as determined by looking at the System Identification Data on the Execution stage page. Finally the query above joins the Task Stage to the Project Stages using the Stage name, so it’s imperative the stage names in the schedule match the stage names in the workflow.

When the SQL is run, if all the milestones for the current phase have been completed, the SQL Query will return 0, otherwise it will return the number outstanding.

The last part of the workflow uses a Set a Condition action that checks the number of outstanding milestones returned by the query and either breaks out of the loop if there are none, or loops again if there are one or more.

That’s really all there is to the workflow, hopefully the breakdown above was easy to follow, but in case it wasn’t I have published the full workflow image here for your viewing pleasure.

Running the workflow

To test the workflow, I have created a new EPT called ‘Milestone Test’ with two phases (Execution and Closure). To the workflow I uploaded the schedule from above as a template and associated it to the EPT so it would be created automatically.

Once the project has been created, the workflow will start and then wait until the submit button is pressed.

Clicking on the submit button will cause the workflow to proceed and check the schedule.

Notice the workflow has gone back to the Wait for Submit action again and noted that there are 2 milestones outstanding. Next open up the schedule via the Schedule PDP and set one of the milestones to 100% complete, then republish and submit once again.

You can see that the outstanding milestone count has gone down to 1, but the workflow is still in the Execution phase. This is because we still have one milestone left to complete before we can move to the next stage.

Lastly, set the final milestone to be 100% complete and republish and resubmit. The workflow will detect there are no outstanding milestones for the phase from the SQL query and therefore allow the workflow to proceed through to the next stage.

As you can see the Execute SQL action is a very powerful action within the Nintex toolset and when coupled with the Project Server Reporting Database allows you to incorporate nearly any aspect of your Project Server data into your governance workflow. Now get coding

It’s that time again, after a break over the summer, I am pleased to announce that the next Microsoft Project User Group (MPUG) Melbourne chapter meeting is scheduled for Tuesday 24th May 2011 at Microsoft Melbourne.

The topic of this meeting is demand management, covering the theory behind it, how it can benefit your organisation and Project Server 2010’s approach to implementing this exciting new capability.

This is a free event, so save the date and make sure you register via EventBrite now!  

 

In the first part of this series, we looked at using Playbooks to move demand management assets from one server to another. Whilst Playbooks is a very useful tool, it does have one limitation in that it moves all the chosen settings over, so if you wish to export a single EPT and its PDPs, you’re out of luck.

Luckily Microsoft released another tool as part of its ‘solution starters’ series that allows the selective exporting and importing of demand management assets. The solution starter consists of two components, the DMExport utility that is used to export the settings and the DMImport code and scripts that contains all that is needed to turn the exported items into a SharePoint 2010 feature for installation.

As with all solution starters, there are two components available, the compiled code mainly ready for deployment in your environment, and the full source code so you can see how it actually works and use it as the basis for future enhancements. For most solution starters, the documentation is either sufficient or the solution simple enough to install and use. Unfortunately in the case of the DMImport /DMExport solution starter, the documentation is a bit lacking and you need to do a fair bit to get it up and running, so hence this post

1. Download

Before we start, you will need to download both the Deployment and Source zip files from the solution starter site. The starters are updated on a very regular basis, so for the purposes of this post, I am using the release from late December 2010.

2. Install and use the DMExport Utility

In order to export the demand management assets, it is necessary to install a small utility on the server you wish to export from. Whilst the solution starter provides the source, the easiest way is to use the neatly packaged setup.exe that is provided in the deployment project. This will install the DMExport utilise to the c:\Program Files\Microsoft\DMExport directory ready for use.

Just like Playbooks, when you first run the DMExport tool it will request the address of the Project Server instance to script the configuration settings out of. Once a connection is established the GUI will display the various demand management items that can be selected and this is where the real advantage of the tool comes in.

Unlike playbooks where you script all the workflow settings, the DMExport tool allows you to choose what you wish to export and will attempt to determine the relevant associated assets to include. Now from my experience the autocomplete is pretty good but has one flaw, it forgets to associate the workflow status PDP’s (Proposal Stage Status in the above screenshot), which if you don’t include, the restore will fail as it is a mandatory field when creating an Enterprise Project Type.

Before hitting the export button, make sure to populate the ‘Feature Name’ which will eventually become the name of the SharePoint feature that is used to install the assets on the target server and to set the location that the data will be exported to.

Once the export process has completed, you should see a set of files like those below in your export directory.

These files contain the relevant data for the items selected for export and will eventually be turned into a SharePoint feature.

3. Building the DMImport components

The DMImport component consists of two parts, an import library that reads the exported files from above and updates the relevant components within Project Server 2010, and some scripts used to build a SharePoint feature that is used to deploy the assets. The feature when activated calls the import library via a feature receiver.

Before the DMImport scripts can be used it is necessary to build the import library and register it on the destination server. The source code zip file contains everything needed to build the import library. Simply open the project in Visual Studio 2010 and build the project. Once the build is complete the following DLL should be created:

To register the DLL, use the gacutil.exe file located in the DMImport\Deployment directory of the source zip file and the following command:

Gacutil.exe /i <path>\Microsoft.SDK.Project.Samples.ImportDemandManagement.dll

4. Build the feature

Creating the feature itself that contains all the demand management assets is relatively simple. To start, copy the files created in the export location to a new directory on the restore server as well as the contents of the \Solution Starters\EPT_Export_Import\DMImport\Deployment directory .

To build the feature, in the SharePoint 2010 Management Shell, enter the following command:

./InstallFeature.ps1 <directory of the exported assets, including a trailing />

This will kick off the PowerShell script and generate the feature by copying the exported files and building a feature.xml that pulls them all together and associates the feature receiver built above.

If all goes well you should see something like this in the output:

The red error is fine, it is caused by running the script in a SharePoint Management shell instead of a plain old PowerShell shell.

On seeing the ‘Done.’ above, the feature will be generated and installed on the destination server. To check, go to Site Actions > Site Collection Features on the destination server and the newly generated feature will be there awaiting activation.

You may notice the associated image is broken, there looks to be a bug in the script which I haven’t looked at yet.

5. Activate and use the feature

The demand management assets will not be installed until the feature is activated. On clicking Activate, SharePoint will activate the feature receiver and via the import library create the relevant assets inside Project Server. The activation process can take a while to complete, especially if you are importing a lot of assets. In addition, the first time you activate the feature it will create a special logging document library on the destination server that is used to store logging information and a set of XML files describing the changes made.

The latter are very important if you later choose to deactivate the feature as they outline how to roll back the changes and return the Project Server back to how it was before activation.

Again, the documentation is not exactly clear on the library, but for reference it is created at http://<server>/<projectserverinstancename>/DMImport.

6. Deactivating and removing the feature

Should you need to roll back the changes and uninstall the feature, simply Deactivate the feature via Site Actions > Site Collection Features, then in the SharePoint Management Shell enter the following command:

Uninstall-spfeature –Identity <featureName>

Over the Christmas break there was a question in the Project forums around how to deploy the various demand management assets from Development to Test to Production in a controlled manner, i.e. not manually. When I say demand management assets I mean things like Enterprise Project Types, Workflow Stages, Workflow Phases, Project Detail Pages, Web parts, Project Custom Fields and Workflow Proxy settings, i.e. all the bits that your Demand Management workflow needs to operate correctly, but not the necessarily the workflow itself. As you can imagine when you start to develop big complex workflows for your project management process, the number of stages and PDP’s could become quite arduous to manage.

Luckily MS provide two tools that can assist in packaging and moving these assets between environments which I am going to cover off in two posts. In this one, I will be looking at a tool called Playbooks, which allows you script out all the configuration settings from one environment and import them into another. In the next post, I will look at the DMImport / DMExport solution starter and provide a walkthrough of how to build, install and use it.

Getting started

Playbooks is the de-facto tool when it comes to moving Project Server configuration settings between environments. The tool interrogates the Project Server configuration settings and scripts them out into an XML file that can then be replayed back into a restore server.

For the purposes of this post, I am going to concentrate on moving only the demand management components, and will leave the general use of the tool and the various nuances to Andrew Lavinsky’s post.

Before we are in a position to run the tool, there are a few pre-requisite steps that need to be completed on the server being backed up.

1. Save any custom project workspace templates that may be referenced in your Enterprise Project Types
2. Save any project templates you may have associated with an Enterprise Project Type
3. Determine the UIDs of the project templates, this will be needed later on to map the template UIDs to the UID’s in the restore server. This last step can be a little tricky as there is no ‘simple’ way of getting the UID of a template. The easiest way I have found is to run the following query against the Draft DB.

 select PROJ_UID as [Project GUID],
PROJ_NAME as [Project Name],
PROJ_TYPE as [Project Type]
from MSP_PROJECTs where PROJ_TYPE = 1 

Once completed, the saved workspace template and project templates need to be installed on the restore server. In the case of the workspace template, this is as simple as Site Actions > Site Settings > Solutions and uploading the various project workspace templates into the gallery. The project templates require a little more work and will need you to use Project Professional connected to the restore server and to open and subsequently save each schedule template to the restore server, not forgetting to choose the ‘Template’ type in the Save to Project Server dialog.

Once the templates have been saved into the restore server, run the above SQL Query again and you will have the new UIDs of the templates needed for mapping in the playbooks file.

Backing up

To back up the demand management settings on the source server, it is necessary to install Playbooks onto the server itself. Once started, you will need to point the tool at the backup Project Server instance, in the case below http://project.contoso.com/PWA.

The tool will then provide a list of all the settings that can be backed up for the user to select from. As we are only interested in the demand management or workflow components, check the Workflow setting in the tool as highlighted below.

You will notice that several Enterprise Data options will also be checked automatically to ensure the correct reference data is also backed up. Also remember to provide a Filename to save the configuration settings into, this file will then be moved onto the restore server. Once the backup has completed you will see something like this including a link to the log for troubleshooting if needed.

Mapping the Templates.

Before the backup can be restored, it is necessary to modify the backup file slightly to map the new project schedule template UIDs to the old ones. This should be as simple as doing a find and replace using the UIDs from the backup sever and replacing them with the corresponding UIDs from the restore server. If you don’t do this step, the restore will fail with an “EnterpriseProjectTypeInvalidProjectPlanTemplateUID” error.

Restore

After transferring the updated mapped XML file to the restore server, the restore process is very similar to that of the backup, simple select the PS instance to restore the demand management settings to, load up the mapped XML file, select ‘Replace’ as the restore strategy and click on restore. Once again, it is important that Playbooks is run on the restore server itself and not remotely, even though the tool will allow it, otherwise the restore will fail.

If all goes well and you have completed the pre-requisites successfully, the demand management assets should now be restored to the server, and visible in the server settings,  ready to be used with your workflows.

In the next post, I will look at DMImport & DMExport, a ‘solution starter’ that approaches the problem in a slightly different manner, instead of picking up all the demand management assets in one go, it allows you to selectively export the assets, so you can choose which assets you want to deploy, not all of them.

A common request from people that develop workflows within Project Server is how to create a simple approval process for a project to transition a stage gate, so I thought I would write a blog post covering off how you can achieve it with Nintex Workflow for Project Server.

The stage gate logic I am going to use, is outlined in the flow chart below.

The approval will give the user two options, either approve and move into the next stage of the project, or reject the approval and stay in Stage 1.

Before we get to the approval part, the workflow logic needs to set a few things up. The initial stage, some status information, and to populate a workflow variable with the project name (which we will use in the approval later on).

 

This workflow makes use of a number of variables to store information read from the project as well as variables about the state of the project.

Next up, before we get into the rejection loop we are going to set the Stage Approval variable to ‘No’. This variable is important as when it is set to ‘Yes’ it will break out of the loop and continue into the next stage.

 

Once the variable is set, we can move into the loop.

 

Setting the loop up is really simple, basically we want to ensure the loop continues to loop whilst the Stage Approval variable is equal to ‘No’.

Once we are in the loop the first action is to ‘Wait for a Submit’, this ensures that we only proceed to create an approval if the user has clicked on submit for the project. Next we read in the users we wish to send the approval to, in this case we are using the ‘Read Project Security Group’ action, set to read in the Project Server ‘Portfolio Managers’ group and to store the information in the Portfolio Managers variable.

In the example above, I have also included a ‘Set Status Information’ action to update the Status Information for the user and let them know that the workflow is ‘Waiting for Approval’.

Next we need to actually set up the task. In this example, I have used a Nintex Flexi Task, which has a number of advantages over a normal to-do task:

• We can assign as many approval options as we want (not just two!!)
• There is out of the box logic to collate the results (majority, first past the post etc)
• It provides downstream options at design time for further actions Of course, just like a normal task list in Nintex, you also get the value of highly customised notifications, escalations, delegation and reminders all out of the box and really simple to configure.

For our purposes, the flexi task will be configured to assign a task to the users we retrieved into the Portfolio Managers variable earlier.

You can also see that the Task name has been configured to create tasks named ‘Stage Gate Approval : <Project Name>’ using the Project Name we retrieved into a variable earlier on in the workflow. For this blog post, I am not going to set up the other options such as Reminders and Escalation.

Next we need to configure the various actions to perform depending on the outcome of the approval.

 

As you can see above, if the task is approved, the Stage Approval variable is set to Yes, which causes the workflow to exit the loop, however if the task is rejected, the Status Information is updated to update All Approver Comments and the loop starts again, going back to wait for a Project submit.

Finally, all that is needed is to add the actions to set the next stage once we have exited the loop.

As you could imagine, the whole workflow itself can get quite long, so to that end I have uploaded an image of the whole workflow which you can download here.

So what does it look like in action?

Once a project has been created that uses the workflow, a task will be created in the Project Server Workflow Tasks list for each of the users that are part of the Portfolio Managers group. As you can see in the screenshot below, the task follows the naming convention we set up above.

Clicking on the task will bring up the default flexi task approval box (for those of us a bit more adventurous this can be customised with InfoPath 2010 to make it look as sexy as you want).

 

As you can see, the flexi task has automatically added links to the Workflow Status and Project Details pages so the reviewer can view the relevant information before they make a decision.

So as you can see, setting up a stage gate approval in NW4PS is pretty simple and this one took about five minutes to build from scratch. Of course if you are going to have many stage gate approvals you may want to consider moving the actions into an action set, or saving the approval as a snippit to make it easier to view and reuse. You could also look at extending the workflow to add some extra logic to handle those cases if the read security group action fails to determine any users, using a run if action. There are a wealth of possibilities, so get coding

Arguably one of the most exciting features in Project Server 2010 was demand management or project lifecycle management (PLM). What PLM provides is a set of tools within a Project Server 2010 instance to manage the whole project lifecycle, from the concept of project phases and stages, a mechanism to collect and display data as you move through the project and best of all, a workflow engine. Out of the box, the development of workflows for use in PLM can be quite arduous. Unlike the rest of SharePoint, workflows for PS2010 cannot be built with SharePoint Designer, instead organisations have two options:

• Leverage the Dynamic Workflow Solution Starter, a Microsoft released tool that enables simple approval type linear workflows to be built from within a web page without any code; or
• Get a .net developer to use Visual Studio 2010 to design, develop and test a bespoke workflow that meets all the organisational requirements.

However, there is a third option, enter Nintex Workflow for Project Server 2010 (NW4PS), an extension of the popular Nintex Workflow 2010 (NW2010) which brings a simplified drag and drop interface for building workflows and integration into the Project Server workflow components to users via the web browser.

So how does NW4PS stack up?

Installation

The installation of NW4PS is relatively painless and well documented. NW4PS requires two components to be installed, NW2010 which provides the base workflow functionality and NW4PS which provides the Project Server integration. Once installed and activated, two sections will be added to Central Administration where the various components of NW2010 and NW4PS can be configured.

Additionally two new options will be added to the Site Actions menu to provide end user access into NW2010 and NW4PS features.

Creating a Workflow

The true power of Nintex Workflow for Project Server is in the simplicity of creating workflows and this is evident in the workflow designer that uses a web based drag and drop interface to create workflows.

The left hand side of the screen provides a menu of actions that can be used within the workflow, each logically grouped and searchable. To use an action, simply drag and drop it onto the design surface.

Once on the design surface, each workflow action needs to be configured, allowing the user to set the various parameters using simple dialog boxes. As you can see in the diagram below, setting the project stage is as simple as selecting it from a combo box, instead of having to dig around for a stage GUID like you have to do with Visual Studio. In addition, if as you are building the workflow you realise you have forgotten a stage, a handy link is provided to enable you to create a new stage from within the tool.

For the purpose of this post, I decided to develop a simple branching workflow that collected some information for a proposal, then performed a validation and either approved or rejected the proposal based on the a predefined value, the exact same branching workflow described in this MSDN article.

The whole process of creating the workflow by dragging and dropping the workflow actions on to the design surface, configuring each action and then saving the workflow took a little under five minutes to complete.

Deploying a workflow

With Project Server workflows that are developed in Visual Studio, it is necessary to create a workflow solution package within VS2010 and then deploy the solution into Project Server. With Nintex, the process of deploying is as simple as clicking on the Publish button.

Once published, the workflow will be available in the EPT configuration screen to associate it with a specific Enterprise Project Type.

Running a workflow

Running a NW4PS workflow is exactly the same as you would expect for a traditional Project Server workflow, simply create a new project of the configured EPT and the workflow will kick off. As you would expect, the Project Detail Page (PDP) infrastructure of Project Server will kick in and the various pages will be displayed as configured for the current stage. Similarly, the normal PDP workflow overview page will continue to show the status of the workflow in a table, however Nintex also provides a handy visualisation for the workflow which makes it simple to see where a particular project is in the workflow process.

Ok, so what else can you do?

The true benefit of NW4PS other than the reduced time to develop and ease of deployment is the sheer number of preconfigured workflow actions you can draw onto make the workflow as functional as possible. Such scenarios as:

• Sending weekly reminders to Project Managers to complete their status reports whilst the project is in execution;
• Creating tasks within the project by using a workflow controlled PSI call;
• Alerting stakeholders that are not users of PS via an email of upcoming tasks / milestones;
• Performing queries against the PS Reporting Database and use the data returned within the workflow; and
• Link document approval workflows into PS workflows, ensuring that documents are approved before the PS workflow progresses are all possible, really taking Project Server Project Lifecycle Management capabilities to the next level.

Disclosure: I am an employee of OBS, a member of the Nintex group. However, this did not inform this post, I really do think it’s a great product