5 Steps to Application Portfolio Management [Webinar]

Ben Chamberlain will be presenting on one of the hottest topics we see in the IT portfolio management world these days…..Application Portfolio Management.

Ad-hoc, event-driven approaches to Application Portfolio Management (APM) simply aren’t delivering results. Important application data and metrics simply can’t be effectively maintained using spreadsheets and homegrown tools. This makes it a challenge to sustain a continuous APM process that supports annual IT planning and budgeting.

Tune into this webinar to see how APM can help you:

  1. Consolidate applications in one inventory
  2. Derive key assessment metrics (Value, Risk,
    Architectural Fit etc.)
  3. Calculate  Total Cost of Ownership
  4. Collaborate to record lifecycle decisions
  5. Build and execute multi-year transformation roadmaps

For more details, or to register…..

Advertisements
5 Steps to Application Portfolio Management [Webinar]

Project Online: Step 1…Kill the Default PWA Site

After more than a year of watching folks adopt Microsoft’s Project Online, one thing we’ve noticed is that most organizations tend to have multiple Project Web Apps (DEV, PROD, Marketing, IT, etc.).  Additionally, many organizations prefer to modify the default URL to something that’s a bit more user friendly, i.e. the default https://tenantname.sharepoint.com/sites/pwa site often becomes /sites/projects or something like that.

The issue is that the default button within Project Online is hardwired to go to the https://tenantname.sharepoint.com/sites/pwa URL.  If that site is deleted, that button becomes useless.

image

One thing that we’re recommending as the standard then is to delete the default Project Web App (preferably before anyone has configured it.)

SNAGHTML1eb1f4b

After deleting it, provision a new team site at that location, i.e. with the same url: https://tenantname.sharepoint.com/sites/pwa.

image

Grant access to everyone in the organization to this page.  And now you can create a couple of PWA sites.

SNAGHTML1f2ebd0

….and add those links to our site at /sites/pwa.  You now have a project landing page hooked into the navigation button that can be used to redirect folks as appropriate.

image

Project Online: Step 1…Kill the Default PWA Site

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.

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

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)