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.


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.


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.

Posted in Scheduling, Workflow | Leave a comment

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.


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


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


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


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


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


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.

Posted in Admin, Project Online, SharePoint, Status Reports, Workflow | 1 Comment

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.


…and add two webparts:

  • Query String Filter Webpart
  • List Webpart


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


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


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.


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


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

Posted in Admin, Project Online, SharePoint, Status Reports, Workflow | Leave a comment

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.


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


Note the URL for the form:


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.


That yields a much shorter URL:


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:


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.


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.


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.


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.


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


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:


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

Posted in Admin, Project Online, SharePoint, Status Reports, Workflow | Leave a comment

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.


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.


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.


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.):


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.


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.


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


That yields an entire workflow that looks something like this:


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

Posted in Admin, Project Online, SharePoint, Workflow | 3 Comments

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.


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.


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.

Posted in Admin, Project Online, SharePoint, Status Reports, Workflow | Leave a comment

Project Conference 2015 Announced – Well Sort Of

See this link for more details: http://blogs.office.com/2014/07/21/microsofts-unified-technology-event-for-enterprises/

As has long been predicted, this will be the big one – where the worlds of collaboration collide for a unified Project/SharePoint/Exchange/Lync conference.

Posted in Events | Leave a comment