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

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 1)

This blog started way back when with a post on creating status reports.  Back then, my go to method was to leverage an InfoPath form embedded in a Project Server PDP.  The key was to pull the ProjectUID from the PDP URL, drop that into a status report entry in a custom list, and then surface the status reports on another PDP.  This concept worked reasonably well, and I managed to leverage it for a number of use cases throughout the last couple of years.

Of late, I’ve been playing with SharePoint Designer workflows, and I came across another method of creating status reports.  In fact, status reports are merely one use case.  The techniques that this and several future blog posts will show will allow administrators to create a whole slew of custom actions that could augment the traditional Project Server experience.

Note that nothing I am writing about is specific to the Project Online or Project Server on-premises.  This could be applied to either platform.

Creating the Status List

To support this scenario, we will need to create at least two workflows, and at least two custom lists.  The first list will be our status update list.  I’ll create that as a custom SharePoint list and add columns for the Status, Project UID, Project Name, Project Start Date, and Project Finish Date.  The reality is, of course, I can add any fields that I would like.

image

This list will be used to capture the status updates.

Creating the Project Action List

Next, we will create the list to store our custom project actions.  This list will be a custom Link list.  We will also use this list to host the status reporting workflow.  To this list, we add a column for the Project UID.  Ignore the two crossed out columns, as those were used for testing the workflow.

image

That’s pretty much it for the blocking and tackling.  In the next post, I’ll talk about how to read project data in a workflow, and write it to the status list.  We’ll follow that up in the third post with a discussion of how to create URL triggers for the workflow.

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

Adding Yammer to Project 2013 Workspaces

Yammer is the greatest thing since sliced bread, automatic toll passes, and half price fajita night – or so I’ve been told.  For those of you not familiar with Yammer, it’s Microsoft’s solution for social networking and collaboration.  I am sure folks in Redmond may cringe when I write this, but imagine Yammer as a combination of Facebook and Twitter, but where the information and who can see the information is controlled by the organization.  This gives us all of the free wheeling knowledge management of social networking tools, but none (well, less) of the risk that this information walks out the door when I’m not paying attention.

What gets a bit confusing is that there’s a fair bit of overlap between Yammer (a recent acquisition) and the out of the box SharePoint social functionality.  That overlap hasn’t quite been rationalized as of yet, and is the topic of much speculation.  For now, note that there is a quarterly refresh of the roadmap for Yammer and SharePoint (link to the last one), and if you’re reading this post more than a couple months after it was made, it’s probably out of date due to the continuing convergence of the two investments.

This post isn’t intended to cover the differences between the two, as that topic has been extensively covered in other blog posts.  Instead, this post has me putting on my project and program manager hat and reviewing a couple of use cases in which Yammer could make my life a lot easier.

One particular use case is that I can extend my Yammer network to include team members that are outside of my corporate network and who don’t have access to the SharePoint site.  This provides an easy collaboration platform to augment the SharePoint site and Project Server.  Additionally, Yammer has a much larger presence in the mobile world, which means I can now participate in the project discussion easily from my mobile device.

This leads to one of the key elements in Project Server that, in my opinion, has been lacking for the last couple versions.  Specifically, Project Server has long had a gap in capturing the project narrative, the human story behind the status reports and the projects.  Yammer seems to be a great method of capturing and surfacing the narrative – and supporting the kind of asynchronous collaboration common to distributed project teams today.  This also augments the onboarding process as team members may join the team and quickly get caught up on the major discussions.  Think about how you can augment your requirements clarification discussions with specific hashtags for the requirement.

Adding Yammer to the Workspace

Adding Yammer to a workspace in 2013 is pretty simple.  Basically, go to the site, add an App, and select the Yammer app from the SharePoint store.

image

It would, of course, be nice to have the Yammer app as part of my site template so it would be provisioned automatically whenever I create a new project.  Unfortunately, it looks like we’re not quite there yet in terms of the roadmap, as when I tried to create a site template containing the Yammer app I got the following results:

image

The main issue I see there is that I don’t believe it’s possible to programmatically provision a Yammer group for each Project site that is created.  I’m not sure it’s possible at this juncture – but am relatively certain it’s in the roadmap.  On the other hand, I’m not sure it would always be desirable to automatically provision a Yammer group for each site, as there may be some thought required on how to architect the Yammer network.

As I’ll talk about a bit below, we would need to make the decision as to whether the group should be part of the internal corporate network, an externally accessible network – or even if we want to incorporate the project specific discussion into a larger group, for example, to support a program management model.

Configuring the Yammer App

After creating the new site and adding the Yammer App, you’ll be required to log in to Yammer and configure the Webpart.

image

Logging in to Yammer with an existing account, I get the option to configure the Webpart.

image

You’ll see that the Yammer app has three options when it’s first added to a page:

  1. Connect to an existing Group.
  2. Connect to the Home Feed
  3. Connect to a comment feed on this specific site (i.e. a Group created for this site URL)

Internal Discussions

I’d submit that the most common configuration would be to simply create a Yammer group mapped to the site URL.  In the case below, I create the Yammer group as a comment feed.

image

…and within seconds have a discussion group created to support my Project.  Note how this defaults to my internal organizational network, Project North America.

image

Logging into Yammer.com directly, I can see a new group has been created for the site URL.

image

The project team members may now collaborate and have conversations within Yammer, and I can see (and eventually search) the results within the SharePoint team site.  Users can also post documents to Yammer, which don’t get fed over to the SharePoint site, which presumably is also an issue on the ongoing roadmap for integration between the two products.

The value of Yammer in this case is to 1) provide a useful collaboration platform and 2) to provide a central hub for team members involved in multiple projects and/or groups to collaborate – and then send the information back to the Project Site.

External Discussions

What if I want to include external collaborators?  In this case, I go into my Yammer administrative interface and create a new network.  Below, see that I have created a network to support Project North America Collaboration.

image

Once the network has been created, I can create groups within it and send invitations to anyone with an e-mail address.  They would then receive an invitation to create a Yammer account (if they don’t already have one) and Bob’s your uncle, they’re collaborating on your project.  The trick here is to create the group in an external network within Yammer – and then go configure the Yammer app on the project site.

image

This feature proves to be a bit more interesting to me as it enables a number of useful scenarios:

  1. I have a project with both internal and external stakeholders.  Rather than go through the efforts of getting access for my external stakeholders or creating an extranet site outside of my corporate firewall, I can use my project site for internal communication, and then provision a Yammer group to support external communication.  I place carefully controlled documents on the Yammer site, such as policies, procedures, and content that would not be considered sensitive.
  2. I am supporting a joint venture project where we have multiple project sites, each one within the specific joint venture partner companies.  Yammer then provides the central collaboration to knit these sites together.

Other Models

A couple other models that may be enabled:

  1. Use Yammer to support program management.  While each project will have a Yammer thread, I can review all of those in a consolidated perspective from the program management office.
  2. Use Yammer to support application management and integration functions.  Many organizations struggle with Release Management, and with the interactions between multiple releases.  With Yammer, I could tag threads by application or environment, and informally use this to track activities that could impact system availability.  Or imagine that I have an application specific discussion group for SAP, and surface that on the project page so that users are aware of upcoming application changes.
  3. In an oilfield management example, I could capture the equivalent of the daily operations call and making it available for team members to refer to.

Hybrid Models

In the interest of being thorough, I figured I’d test out the possibility of adding two discussions to a Project site: one for internal discussions and one for external discussions.

image

Turns out this is indeed possible.  I’m not sure anyone would end up doing this, as it would seem to me that I would forget which discussion group I’m on and just post wherever I have my cursor.  Still, a good thing to know.  And again, once I start having multiple threads on a single page, I can use this to capture the daily signal traffic that I need to know to do my job, but that I don’t necessarily need to pay close attention to all of the time.

Not sure what my conclusion is other than that you can definitely see the value right now, and you can definitely see the potential for value to be greatly increased through a tighter integration with SharePoint and Project Server.  Stay tuned for most postings in this vein in coming quarters to periodically reassess specific project management use cases in the integration road map.

Adding Yammer to Project 2013 Workspaces

Defining an Update Methodology (Part V)

This post wraps up the discussion on developing update methodologies.  The first three posts addressed some of the basic principles of updating schedules as well as some of the specific mechanical elements within the Microsoft Project desktop client.

The last post reviewed how those principles and mechanisms could be applied to an IT scenario.  In this post, I’ll talk about how construction projects may get updated.  The goal is hopefully to provide suggestions that may be applicable to your own environment.

Again, there will always be nuances, but the general process will likely be as follows:

  1. Set the status date.
  2. Add the Actual Start or Actual Finish
  3. Set the Remaining Duration for in progress tasks.
  4. Progress all completed tasks to the status date.
  5. Reschedule unstarted tasks to the status date (or estimated start date)

Let’s walk through that scenario in a simple schedule.

image

In the simplest case, we first update the Actual Start or Actual Finish for the tasks that have actually started or finished.  I update the following:

  • Actual Finish for the Project Started milestone.
  • Actual Start for Task 1.
  • Actual Start for Task 4.

image

Then I set the Remaining Duration field for each of the tasks.  Generally, I would enter a Remaining Duration that pushes the new Finish date out to the estimated finish date that my resources are reporting to me.

image

If I am using Project Server, I might add a custom field for Estimated Finish to the My Tasks sheet, then roll the Estimated Finish field into the Remaining Duration field using a macro as part of the update process.

Then I select the option to Update the Project from the Project tab.  In this case, I select the started tasks first and set the options to progress the tasks as follows:

image

I could also use the Mark as Scheduled option in the Task tab to accomplish the same thing.

image

Note how % Complete automatically updates…

image

From there, it’s a simple step to reschedule any unstarted tasks to after the status date – again using the Update Project button.

Facilitating the Process

One method to facilitate this process is to add a custom field and grouping that would group tasks by whether or not they are in progress or unstarted.  A formula to establish that in a spare text field might look as follows:

IIf([% Complete]<100,IIf([Actual Start]<>ProjDateValue(‘NA’),”In Progress”,IIf([Start]<[Date1],”Unstarted”,””)),””)

…where Date1 is configured to equal the Status Date.

image

Group by it, and you would get the following view.

image

Review the process above, and the view makes things simpler.  If I apply the view after I’ve entered all of the Actual Start and Finish dates, then I can simply select the In Progress tasks to progress to the status date and the Unstarted tasks to reschedule after the status date.

Better yet, as discussed above, I could develop some form of VBA automation to refer to that field and update my project with a single key stroke.

Comparing Construction and IT

So now we’ve looked at two different scenarios, what is the fundamental difference? In both examples, we follow the two commandments of schedule updates, i.e. no incomplete work before the status date and no completed work after the status date.

However, we make different assumptions about why the task took longer than expected, i.e. whether the estimate was incorrect or whether the team was pulled off of the task.  In the example above, we assume that the team has been working continuously since the Actual Start date for the task.  In IT, we assume that the work was interrupted.  Are either examples always true in any industry?  No, what we’re attempting to do is to define a process that captures the bulk of the project updates, but there will always be tasks that don’t match this particular model.

Once we remove that assumption that the work was interrupted, % Complete becomes essentially useless for data input.  In that case, once the resource identifies the Actual Start and the Remaining Duration, the scheduler calculates % Complete for the resource.

Defining an Update Methodology (Part V)