Running Workflows on a Project Server Linked Task List

In Project Server 2013, Microsoft has introduced a new feature where task data from the project schedule is automatically synchronized with the first task list found alphabetically on the linked Project Site.  When it does that, it locks down the target task list so that it may only be edited through the main PWA interface or Project Professional.

image

There are a number of scenarios where you might want to enable workflow on this task list.  For example, you could create a change log that records whenever a task is modified.  You could create a centralized list of milestones…..you could create a task approval process…..I’m sure I’ll come up with a number of options.

The interesting thing is that the default workflow options seem to get hidden on a synchronized task list.

image

Drill in to the task, and you’ll see the workflow option noticeably missing from the ribbon.

image

So it seems Microsoft is not keen on you leveraging workflow to the list.  Hence, proceed at your own caution.

Luckily, the workflow option is hidden but not removed.  If you dig up the right URL, you can still access the workflow for each task.   In this case, I had to get the ID of the item and the ListID (from the List Settings URL) and the following URL will display the task workflow options.

https://servername.sharepoint.com/sites/pwa/Document%20Dashboard/_layouts/15/start.aspx#/_layouts/15/Workflow.aspx?ID=1&List=%7BEBFC7875%2DDF56%2D4796%2DB166%2DFF727190053C%7D

image

So now we know the workflow is feasible, let’s create a simple one.  The following workflow creates a “Hello World” item in a custom list called WorkflowTest.

image

The trick is on the Workflow Settings screen…

image

See the option I’ve deselected?  If that is on, it will try to set a column in the task list with the status of the workflow.  As the task list is locked for editing due to the fact that it’s being synchronized with Project Server, this will cause the workflow to fail on execution.

To solve, simply deselect that option.

Now, whenever I modify a task on the schedule, it will generate a “Hello World” entry in my WorkflowTest list.

image

Not too far from there to a task change log kept in a SharePoint list.

Advertisements
Running Workflows on a Project Server Linked Task List

Deliverable Dashboards with SharePoint Workflow

A common request in project management is to be able to create a dashboard for each project that shows the status of specific defined deliverables that must be created.  For example, the project manager must be able to see that a SOW or proposal has been posted to the site.  The project manager must also post a status report to the project each week – or get flagged as being out of compliance.

image

In prior versions of SharePoint, this was typically performed through the use of custom code.  For this post, I decided to sit down and see if it could be done with a little SharePoint Designer workflow.  Turns out it wasn’t hard at all.

To create this solution, we’ll need:

  1. A custom SharePoint list for the dashboard
  2. A document library
  3. A couple custom content types
  4. One list workflow on the document library
  5. One site workflow on the dashboard list

Dashboard List

This is a simple list with a couple of fields:

image

Note that Status is a drop down with Red, Yellow, and Green as the available options.  (Red is the default).

I modified this list to add conditional formatting using SharePoint Designer 2010 as in this blog post.  It looks like SharePoint conditional formatting is being deprecated in 2013, so this is a bit of a hack where I had to install SPD2010 to get this to work.  I’d trust smarter folks than I to figure out a better way of sprucing up the dashboard – i.e. adding icons or leveraging some other method to create the conditional formatting.  For today’s post, this will do the job.

image

Add list items to your list for each deliverable you will be tracking.  I used the same names as the content type in the document library to facilitate the workflow finding the correct item to update.

Document Library

For the document library, I added a couple of content types and an Approved field.

image

Dashboard Update Workflow

I then created a simple workflow on the document library.  This is set to trigger whenever a document is created or modified.

image

Adding some additional detail to the picture above:

  1. Line 1 picks up the UID (as a string) of the dashboard item corresponding to the content type of the document in the document library.  This allows some minimal error handling by skipping the items that will throw an error if it can’t find a dashboard entry corresponding to the document content type.
  2. Line 3 establishes the URL of the document in order to populate that in the document dashboard – so the user can click directly from the dashboard to the document.
  3. The if….then clauses flag the dashboard item as green or yellow depending on if the document has actually been approved.

Here’s a shot of the step that updates the dashboard item.  (This is for approved documents.  The other one will flag the item as yellow.)  Note I’m copying the Last Modified date into the dashboard Updated field.

image

That will update our dashboard list per our requirements.  One more quick item, and we’re good.

Status Report Monitoring Workflow

For the final step, I want to add a bit of logic to flag the status update column yellow if no status update has been posted in the last week.  To do this, I’ll create a site workflow that will wake up every 24 hours, check to see if a new status update has been posted, and flag the item as yellow if it’s been a week since the last update.

That workflow looks like this (if anyone can suggest a better way to present SPD workflow in a blog post that’s not too tedious, let me know.)

image

More detail:

  1. Line 1 is pickup up the GUID for the status report item in the dashboard list.
  2. I’m basically picking up the Updated date, adding 7 days, then comparing it to today’s date to determine if the item must be shifted from green to yellow.

And there you have it…one compliance dashboard.  If anyone has suggestions on how to clean up the look and feel of the dashboard itself, feel free to post in the comments section.

image

image

Deliverable Dashboards with SharePoint Workflow

Unpacking Project Schedule Concepts

As many PMP trainers will tell you, one of the advantages of enterprise wide PMP certification is that all of the PMs within the organization start using the same terminology.  Everyone suddenly is able to speak in the same language.  That’s a significant part of what we do when we work with clients.  We often need to unpack the terminology that’s in use within the organization – and often we need to evaluate the actual practices being performed and map them to an EPM framework.

In this vein, it’s always impressive how much organizations attempt to pack into a project schedule.  Often times, there are very disparate concepts that get thrown into a project schedule – which don’t make too much sense, and may present an obstacle to the organization actually managing projects effectively.

Phases and Lifecycles

Take the example of the word “phase.”  The PMBOK defines a phase as a collection of tasks, usually culminating in the creation of a major deliverable. In the software world though, and I’m talking specifically about the world of Microsoft Project Server and SharePoint workflow, a phase implies that the project (or entity) is in a specific state, i.e. “Pending Authorization, Active, On Hold, Completed.”  In effect, a lifecycle phase is a label that we apply to the project that is then inherited by all of the various entities that comprise a project: resource work, allocated cost.

In this way, we have cost that is associated with projects that are still pending approval, and we have cost that has been allocated to projects that are currently active.  The phase label presents a convenient way of classifying this cost.  If we use this mechanism, by default, a project may only exist in a single phase.  For a project to exist in multiple phases at the same time typically requires that we model the project differently, i.e. as a program – where we have a program lifecycle that is comprised of multiple projects – and each project is in a distinct phase of the project lifecycle.  In fact, I typically use that as a test to see if we’ve defined the phases correctly.  If it’s possible to be in multiple phases at the same time, we didn’t get the lifecycle definitions correct.

Schedules

So that’s how the term “phase” is now used in the world of PMIS system design.  Now let’s talk “schedule.”  On this, I tend to go with the PMI definitions, which state that the schedule is a static representation of a schedule model – with a schedule model being the accumulated logic and information related to a project combined to provide a predictive forecast of time, cost and effort.  Each week, you input the latest developments into the model and generate a revised schedule.

This is where things may get confusing.  Schedules often include a logical grouping of tasks – often called a phase.  Note, however, that this is generally not the recommended way to structure a project schedule, as the general consensus in the scheduling world (at least within the circles I run in) is that schedules should tie directly back to the WBS, and a WBS should always be product oriented, not phase oriented.

Hence while a schedule model may be structured to map to a specific phase structure, that’s not necessarily required or even desirable.  In fact, one could argue that a phase structure supersedes the actual schedule of a project – as it’s very rare to actually incorporate the preauthorization, business case development steps in the schedule – which doesn’t typically get developed until a bit later in the lifecycle.  The same applies for post-project benefits analysis – which needs to occur, but is rarely incorporated into a project schedule.

On the other hand, it’s quite common to leverage the schedule model to forecast when a project will transition from one phase to another, i.e. to include milestones within the schedule that provide some prediction of when the project will progress to the next phase.

So we now have two terms which are often conflated:

  1. Phases – a specific definition of the status that a project is in within the project lifecycle – that definition being inherited downward to apply to all of the relevant component of the schedule model.
  2. Schedule Model – a simplified representation of the project schedule used to forecast time, cost and effort.

Checklists

And the last item that often gets confused with these two, surprisingly enough, a checklist.   What is a checklist?  It’s a collection of tasks or conditions that must be met for a specific item to be declared completed.  Sound familiar?  Sounds kind of like a phase, i.e. we have a collection of things that must be completed before the project may move from preauthorized to authorized. Similarly, it sounds a lot like a schedule, which contains a series of tasks that must be completed for the project to be completed.

The difference is that a checklist defines either conditions that must be met – or tasks that must be completed, but those tasks are so small and granular that they are not worth including in the schedule model.  We simply summarize the checklist process as a single task within the schedule, and capture the verification procedures that drive the checklist outside of the schedule.  At least, that’s how it should work – too often we see clients incorporate the checklist into the schedule model and try to model overly granular tasks in the schedule.

Once we’ve unpacked these terms, we can focus on improving each one.  Until that is done however, what we have is an unwieldy procedural mess.

Unpacking Project Schedule Concepts

Creating Status Reports with Project Online and SharePoint Designer (Part 5)

In the last couple of posts, I talked about how to leverage SharePoint workflow and OData to create a status reporting mechanism in Project Server and Project Online.  Let me recap.  On second thought, there is too much…let me sum up:

  1. Post 1: Creating the Required Lists and Columns
  2. Post 2: Creating the Workflow to Capture Status in a Status Lists
  3. Post 3: Creating a Workflow to Create the URL to Trigger the Status Reporting
  4. Post 4: Adding All of that to Project Detail Pages

In this post, I’d like to take that just a bit further and add a couple of custom actions to our status list.  These actions aren’t required, but they go a long way towards making the experience more intuitive (read: less training) for the end user.  We’re going to add those actions to the drop down list next to the status list item.

image

To do this, we’ll add a custom column to the list called Update Status.  I set it so it defaults to “Draft.”

image

Now we’ll go into SharePoint Designer and create a simple workflow on the list to change the field from Draft to Final.

image

Publish the workflow.  Now, within SPD, go to the option to modify the Status List.  You should see a screen like this:

image

Note the Custom Actions in the bottom left.  Create a new one, and set it to initiate a workflow.

image

Go back to the list and you’ll see that a new Approve Item step has been created in the drop down.

image

Click on it and the item will be updated.  Couple that with an e-mail alert task and you could create an entire status approval workflow easily triggered from the list item.

Creating Status Reports with Project Online and SharePoint Designer (Part 5)

Creating Status Reports with Project Online and SharePoint Designer (Part 4)

In the last several posts, we created a couple lists and the workflow logic to move data back and forth.  In this post, we’ll continue to work on the user interface to support our status reporting by creating two PDPs:

  • Custom Project Actions
  • Status Updates

Both PDPs will be pretty simple.  We’ll create a blank PDP.

image

…and add two webparts:

  • Query String Filter Webpart
  • List Webpart

image

Configure the Query String webpart to pull the ProjectUID from the URL.

image

…then connect it to the list to provide an automatic filter.

image

Repeat the same steps for the Status List PDP.  Add the PDPs to the appropriate workflow stage, and we can review what we have created…to do this, I create a new project – which triggers our new workflow to create a custom Project Action.

image

Click on the link to trigger our status update workflow….  We can then go to the Status List PDP to review the results:

image

But we’re not done.  In the next post, let’s add a couple of bells and whistles to update our status report.

Creating Status Reports with Project Online and SharePoint Designer (Part 4)

Creating Status Reports with Project Online and SharePoint Designer (Part 3)

In the last post, we created a workflow to trigger a status reporting process.  In this post, we’ll look at how to create a trigger for the workflow and embed it on a PDP for easy access and intuitive use.  To create this trigger, we’ll need to go to the Project Action list and start our new workflow.

Find the Initiation Form URL

To enable the testing of the workflow, I’ve manually create an item in our list with a functioning Project UID.

image

I fire off the workflow on the second item in the list.  This displays the Initiation Form we configured in the second post.

image

Note the URL for the form:

https://projectna.sharepoint.com/sites/pwa/wfsvc/7a64fbcaf3324d039910fa496f359b17/WFInitForm.aspx?List={1c1a0038-b729-4b26-99d8-193d46c13ecd}&ID=2&ItemGuid={B4276416-A12E-4721-B2FC-40CE66666BAE}&TemplateID={1F39EC48-B553-45F6-911D-64DE745056A0}&WF4=1&Source=https%3A%2F%2Fprojectna%2Esharepoint%2Ecom%2Fsites%2Fpwa%2FLists%2FProject%2520Actions%2FAllItems%2Easpx

It looks like a long string of variables – which it is.  We are going to parse this and add it to the Project Server workflow so a new unique URL will be generated in the Project Action list each time a new project is created.

Parsing the URL

The first issue is that the URL is too long to store in a standard link list column.  If we try to use this URL, the workflow will fail.  Hence, we need to strip all of the nonessential components from the URL.

image

That yields a much shorter URL:

https://projectna.sharepoint.com/sites/pwa/wfsvc/7a64fbcaf3324d039910fa496f359b17/WFInitForm.aspx?List={1c1a0038-b729-4b26-99d8-193d46c13ecd}&ID=1&TemplateID={1F39EC48-B553-45F6-911D-64DE745056A0}

Test this URL by dropping it into the browser to see if it activates our status update workflow.

Creating the Project Workflow

We’re now going to add a step to our project workflow to create the URL to trigger the form.  In this case, I have a simple workflow with a single stage.  In this stage, I’ve added three steps:

image

The first thing we’re going to do is create the initial item in the Project Action list.  We do this so that we can get the item ID, which is then added to the URL, and then updated back into our item.  Feel free to add any URL to the URL field – and populate the Project UID field with the correct lookup.

image

Note that this creates a workflow variable for the UID of the item in the Project Action list.  We’ll use this UID to come back and modify the item in step #3.

image

Here, we run into a limitation of SharePoint Designer.  If we try to create a URL that uses lookups as well as characters such as {,} & %, we will get an error.

SNAGHTML90721c7

For the search engines: Using the special characters ‘[%%]’ or ‘[%xxx%]’ in any string, or using the special character ‘{‘ in a string that also contains a workflow lookup, may corrupt the string and cause an unexpected result when the workflow runs.

Luckily, there’s a simple hack to get around this.  We need to capture the various elements with special characters as their own workflow variable – then compile that back into the URL.

image

Now we reassemble the URL, using the variables instead of special characters.

image

Note the addition of the user friendly label at the end of the URL.  Also note that we are looking up the ID for the item in the Project Actions list using the key of item GUID = workflow variable ActionUID.

From there, we go back and update the Project Action item with the correct URL.  The workflow should now look like this:

image

Add this to an EPT in Project Server…and we’re ready to move to the next step – creating the PDPs….

Creating Status Reports with Project Online and SharePoint Designer (Part 3)

Creating Status Reports with Project Online and SharePoint Designer (Part 2)

In the last post, we created two lists, one to hold the workflow trigger and one to capture the status of the project.  In this post, I’ll run through how to leverage workflow to capture project data and then store it in the status list.  To do this, we’ll need to fire up SharePoint Designer and point it at our PWA site.

image

Create a new workflow and assign it to the Project Actions list we created in the previous post.  Deselect the option to Automatically update the workflow status to the current stage name.

We also need to add a multiline parameter to the Initiation Form called status.  The Initiation Form is important because it can be called through the use of a simple URL.  We will capture this URL and embed it in a PDP to trigger the status reporting workflow.

image

The workflow will now be comprised of two stages:

  • Capture project data.
  • Create the status list item.
  • image

Consuming Project Data with SharePoint Designer

To consume project data, we basically need two actions within the stage….a Call action and a Get action.  For troubleshooting, we also want to log all transactions to the Workflow History list so we can trace when things fail.

image

We configure the Call action as follows (for my tenant, which is http://projectna.sharepoint.com/sites/pwa.  You’ll need to plug in the name of your own tenant.):

image

See how the Call action is pointing to the OData repository and then plugging in the Project UID field from the Project Action list?  Feel free to test this out by entering the URL into your browser, but substituting an actual Project UID for the lookup.

The other parameters in the Call action can basically be left blank, although I did name the content of the response “ResponseContent.”  This will be the dictionary of results – or each of the project level fields for the designated project.

We then need to Get the appropriate field from the ResponseContent dictionary and push it into a workflow variable.  Just follow the OData naming convention to identify the correct field name.  In this case, I am using LINQPad to assist in navigating the data structure.

image

Finally, write the new variable to the Workflow History list.  This will support troubleshooting efforts.

Now repeat the Get and logging actions for each field we need.

image

From there, we just need to create the status list item to store the data.

image

That yields an entire workflow that looks something like this:

image

Publish that workflow, and we’ll come back to it.

Next up, we build the trigger for this workflow and add it to the Project Action list…..

Creating Status Reports with Project Online and SharePoint Designer (Part 2)