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…..

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)

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)

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)

The Microsoft Platform and the Evolution of a PMIS

Is a doorway a frame around empty space?  Or is it the space that is surrounded by a frame?  When selecting a PMIS platform, the same question should be asked.  Is a PMIS a series of solutions within an empty white space?  Or is the PMIS the empty white space populated throughout with a series of solutions?

For those of you not familiar with the PMIS term, it’s a standard industry name for a Project Management Information System – or any system within your organization that is used to track project data.  The PMIS could be a filing cabinet.  It could be a series of notebooks kept by engineers.  It could be an incredibly complex series of IT tools integrated through a data warehouse and a service bus.

Regardless of the technology underpinning it, the PMIS needs to serve specific functions, whether that is project tracking, portfolio analysis, resource management, risk management, or any one of the other key knowledge areas or processes defined in the PMI literature.

The particular form of a PMIS that’s supported by IT tools is part of our stock and trade.  As we see it, this PMIS evolves in different forms.

In some companies, there is no formalized PMIS.  In these organizations, there’s typically not a lot of formal project management processes, and most things are tracked in Excel – perhaps with some financial management in a specific tool such as Oracle or PeopleSoft.

In other organizations, there are a wide range of point solutions.  This is often associated with (but not exclusively with) large organizations where the project management function has been broken out in to a wide variety of distinct offices.  In these organization, there may be an enterprise architecture office, a risk management office, an office that deals with projects just being developed, an office that deals with projects that are more advanced, a reporting office…you get the picture.

The Microsoft platform has a different value proposition in each of those scenarios.  Note here that when I talk about the “Microsoft Platform.” I’m not simply talking about Microsoft Project Server – but rather the full panoply of Microsoft solutions: SharePoint, Project Server, Yammer, Power BI, SQL, etc.

For the first kind of organization, the one where there’re not a lot of formal tools in place, the Microsoft platform provides an excellent foundation to build upon.  Build your collaboration and document management workflows in SharePoint.  Build project scheduling practices and resource management in Project Server.  Enhance knowledge capture through Yammer.  Report on all of this in the Microsoft BI suite.

The challenge here is that Microsoft in presenting itself as a platform becomes a victim of trying to be all things to all people.   Microsoft is great for basic scheduling – but if you are attempting to model critical chain scheduling, you’ll need an add in.  If you’re attempting to do Earned Schedule analysis, you’ll need an add-in.  If you’re looking to manage large industry-specific design documents, you could do it in SharePoint, but you’ll likely be looking at another solution that’s more tailored to the specific needs of the industry.

For the second type of organization, the kind that already has a lot of solutions already in place, we find value in evaluating them and bringing them into the SharePoint fold.  Retire the ones that are superfluous.  Integrate the ones that aren’t.  At the end of the day, the Microsoft platform provides a single integrated user interface from which to navigate to those tools – and a data structure to enable integrated reporting.

At the end of the day, selecting a PMIS platform is less about point solutions and more about filling the white space within the organization’s project delivery organization.

The Microsoft Platform and the Evolution of a PMIS