Here we are again!
This is the third, and final Guest post, written by colleague and Project server workflows enthusiast Hester Blok. Stick around, because as I already mention in the first post: there is a special reason for Hester to do these guest posts on The Project Corner. Here we go with: Project Server workflows, do or don’t?
Implementing Project Server and Project Online solutions at our customers I notice a great deal of hesitance regarding the use of Project Server workflows. Recently I was asked to put the advantages and disadvantages of workflows on paper. So I did and here it is.
The Enterprise Project Type (EPT) is the most important entity within PPM. Technically an EPT is a collection of templates and settings. From an organizational point of view EPT’s define the different project types that are executed in an organization. Oftentimes these project types are similar to the organization’s departments, e.g. HR or IT projects. An EPT does or doesn’t have a workflow association. The pros and cons of both options are described here.
EPT without workflow
For projects that have been created based on an EPT without a workflow the project phase can be set manually by the user:
If this is done accurately for all projects overviews and reports can be created of e.g. all projects in Execution or all Closed projects. In all life cycle stages all project detail pages for the project are available. All project properties can be edited in every stage. Required fields are required from the moment the project is created.
EPT with workflow
The second option is to govern the project life cycle using workflow. For Project Server 2013 and Project Online workflows can be created using the SharePoint Designer 2013 (no code!). The workflow determines per stage:
- Which project detail pages are available;
- Which fields are required;
- Which fields are read-only;
- If approvals have to be given before the project can move to the next stage;
The simplest workflow just governs the stage a project is in. All a user has to do is click the Submit button to move the project to the next stage. Besides having required or read-only fields in certain stages the possibilities the SharePoint Designer offers are numerous. You can have the workflow:
- assign tasks or send e-mails to individuals or groups of people;
- check conditions before performing an action or moving to the next stage;
- set workflow status or project fields;
- create, delete, check out, check in or update SharePoint list items;
- use data from another data source by calling a http:// web service;
- perform calculations;
- start other workflows;
- govern the portfolio analysis.
Creating Project Server workflows is no easy feat. The first step is the hardest: getting a clear picture of your organization’s needs. Some of the challenges you may face after that are described in this post.
Final notes; and a very special goodbye!
Hi guys, Erik here again. I hope you enjoyed this last post written by Hester, because you will not see any more new workflow related posts by her hand.
Hester is leaving JSR, and even The Netherlands to “follow her heart” and try her luck with Alex. A great guy I got the pleasure of meeting during the JSR New Year dinner.
Alex and Hester will be running a small but very nice camping in France, called “En Campagne“:
Now here is an reason for you to care: If you ever visit France and need a camping spot. Tell Hester or Alex you know the spot through Erik from The Project Corner, and the first drink is on the house :).
Hester, I’ve enjoyed the 5 great years working together. I’ll miss your “Let’s do this!” mentality and I’ll be sure to collect my free drink once Wendy is old enough for the trip :-).
Here’s a picture to remember us by (the good old days at the Project Conference, Phoenix):