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.


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:


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.


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.


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.


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.


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


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.



Deliverable Dashboards with SharePoint Workflow

Alphabetical Order Matters: Naming Task Lists on Project Sites

Figured this out a while back for the forums, but then promptly forgot and shot myself in the foot.

Consider the following scenario:

  1. You modify the default site template to have more than one task list – for instance, if you plan to have workflow deployed on the site – which requires a task list.
  2. You publish a project with that site template.
  3. You create a schedule for that project.
  4. The schedule does not appear on the site.  You don’t get that cool Project Summary view.


It turns out the schedule is sync’d to the first task list it finds on the site alphabetically.  If you have a task list named something like, My Workflow Tasks, the schedule gets sync’d to that list.

The solution is to always make sure the task list that you want to sync with the project comes in first in the alphabet.  Optionally, the other method is to modify the Project Summary Webpart so it points to the correct list – although I’d probably check out option #1 first.

Alphabetical Order Matters: Naming Task Lists on Project Sites

Why Are We Talking Yammer at a Project Server Conference?

Man, that’s a great question.  I’m glad you asked.

Of course, there’s the technical reason.  Yammer is owned by Microsoft and falls under that same collaboration SharePoint umbrella Borg thing that Project Server also falls under.

Then there’re the organizational reasons….a couple of the folks from the Microsoft Project team that we all knew and, well, if not loved, at least generally enjoyed working with, jumped ship a year or two ago and moved over to the Yammer side of things.

And then there’s the fact that Yammer and Project Server really represent two sides of the same coin.  At the end of the day, the entire SharePointYammerProjectServerCollab story is really one of enabling teams, whether they be project teams, technical teams, management teams, or any other kind of team.  It’s a story of breaking down each individual’s personal identity and reforming it as part of a larger group with a common goal.  That larger group may be the project, the PMO, or the entire organization.  At some point, the membership and very identity of that group pivots around a central, common idea, or goal.

Yammer, to be specific, and collaboration tools in general, help groups determine their own path to achieve that goal.  It facilitates self-organization of the group to best achieve goals.  And that, by the way, is how you know you’re using Yammer correctly – if you’re using it (to paraphrase Michael Schrage) to create a shared experience and not to share experiences.  The latter means you’re just using Yammer as an internal corporate Facebook to share pictures from last quarter’s sales meeting.

Project Server, and project management tools, on the other hand are a much less tolerant of ambiguity.  Project Server is the X to Yammer’s Y.  Project Server is all about the metrics.  Project Server allows us to define our goal, and then to assess whether or not we’re going to achieve it.  Project Server brings the hard calculations missing in a pure collaborative space.

In a broader sense then, Project Server allows us to identify challenges in achieving our goals.  At the project level, that may mean finishing on schedule.  At the enterprise level, that may mean that we’re not focusing on the work we should be.  Either way, these metrics help quantify the challenges to achieving our shared goal.  These metrics create the shared problem space.  Collaborative tools help us develop solutions to these problems.  Both approaches are required to reach the finish line.

What’s interesting is the fundamental difference in approach from both tools.  Whereas Yammer assumes the existence of intrinsic motivation on behalf of the participants, as a more metrics driven tool, usage of Project Server is usually driven by extrinsic motivation.  It’s the difference between saying, “I want to work with this guy to achieve my goals,” and “I need to get my data in so the reports look right when they go to the boss.”

If you look at the work of the organization as occurring along a continuum, there is a certain structure that must be followed.  Within that structure, there’s a certain grey area that can be exploited to make the organization nimble and responsive.  This is a complementary arrangement that delineates the space in which Project Server and Yammer play.

Why Are We Talking Yammer at a Project Server Conference?

Lessons Learned, Stupid Organizations, and the Other Things

Many organizations are stupid.  This always surprises me as stupid organizations almost always have very smart people working within them and are often quite successful.  Stupid organizations are stupid however, because they’re missing actionable models for success.

Last Saturday was the fourth annual TEDxHouston, a great day of slam poetry, obscure conceptual mix-ups, and lessons on how stand up comedy and gender-neutral pronouns can save the world.  All of this was held around the proverbial corner at Rice University.

The basic concept of TEDx, for those of you who’ve never attended, is to pick a topic or concept, and then to invite an eclectic mix of local thinkers in the fields of Technology, Entertainment, and Design to interpret that concept through the lens of their particular passion.  The audience is then invited to translate those concepts through their own perception bias and into the realm of their own professions.  Saturday’s concept was “The Other Things,” a reference to the John F. Kennedy moonshot speech delivered at the Rice University stadium 50 years ago:

We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.

Last Saturday, a couple dozen speakers took 12 minutes each to identify what they felt those “other things” were.  One such session was presented by a physician from MD Anderson, a local hospital specializing in cancer care.  That’s what got me thinking about lessons learned and the concept of stupid organizations.

The concept is surprisingly simple.  Most people in the world do not have access to the world class cancer treatment available in treatment hubs such as the Houston Medical Center.  MD Anderson is thus teaming up with IBM to develop a rich database of data related to treatments and success models.  If a patient is diagnosed with cancer, the doctor may tap into this wealth of information to prescribe a tested, valid treatment plan. (Link to discussion here)

This is a perfect model for what the lessons learned exercise should be.  In a perfect world, lessons learned should focus on what success looks like, and how the project achieved success.  Specifically, a lessons learned exercise should be designed to refine success and convert it into an actionable model.  This actionable model may be used in at least three distinct ways:

  1. To structure the next project to take advantage of this model thereby enhancing the chance of success.
  2. To structure the next project to identify when the project is diverging from the approved model, and thereby increasing risk by branching onto a heretofore unknown development path.
  3. To structure the organizational processes to ensure that the chance of project success is enhanced (See point #1)

Not only does a smart organization continuously refine the model that brings success, but the smart organization continuously looks at that model as a scientific hypothesis, i.e. a theory that explains how things happen, but that can be jettisoned the moment we come up with a better model.  Models are like any theory: they’re valid until they’re not.

Instead of lackadaisically conducting a couple of interviews after your next project and calling it lessons learned, think about how to convert your current project into a repeatable model for future projects.  In retrospect, what were some of the key indicators and patterns that led to the place you’re currently in?  Break those down into at least two categories:

  1. Things that directly impacted the course of the endeavor.
  2. Things that enhanced the chance of the endeavor succeeding.

Take those concepts and feed it back into your lessons learned exercises, project structuring, and HR onboarding process.  Don’t start a lessons learned process by focusing on the solution and asking what generic information you need.  Rather, focus on the fundamental organizational problem by really defining success, asking what models lead to that success, and how you can structure your projects to map them to those models – or to detect when the project no longer aligns with a proven model.

Continue to test your models.  Don’t accept a success model as the gospel, instead continue to test it against success patterns to see if you’ve really distilled the essence of what makes your organization successful.

That’s how smart organizations learn.

Lessons Learned, Stupid Organizations, and the Other Things

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.


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:


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.


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


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.


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


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


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.


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.


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.


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

Creating a Centralized PMO Calendar

Mark Everett, out of our Dallas office, sent me an e-mail the other day asking me why I haven’t posted anything about SharePoint 2010’s new calendar overlay functionality.  Honestly, I hadn’t yet posted anything on the topic since it was the first I had heard that it even existed.

…so I did some digging, and here you are…..

The Overview

So it turns out that SharePoint 2010 has a new built in feature to aggregate up to 10 calendars into a single color-coded view.  Apparently it’s a well known feature, but I apparently missed the memo.


This is probably a pretty useful feature for PMOs or program managers who are looking for ways to aggregate multiple project calendars. 

If you’re not using project calendars, I point out that many of my clients actually use them quite heavily by e-mail enabling the calendar.  Once that’s done, the project calendar may be “invited” to project meetings just like a real person.  Any meeting invite will automatically get posted to the calendar, which in effect, works much like a project journal.

This functionality puts all of the project meetings into a single calendar – useful when your PMO maintains visibility into all of the key project meetings. 

The Set Up

It’s actually surprisingly easy to create a new aggregated calendar.  Just create a new calendar list within your SharePoint site.  In this example, I will create one in the main PWA site. 

Click on the options to View All Site Content under the Site Actions menu in the top left.


Select the calendar option.


Once the calendar has been created.  Choose the option in the Calendar tab to add a Calendar Overlay.


Choose the option for a new calendar.


Configure the next screen to point to the target calendar.  Choose a color, and you’re off to the races.


Note that you may change the default view to filter on specific meeting types such as status meetings or key phase gate meetings.

The end result:


Additional links:

E-mail Enabling SharePoint Calendars (Jeff Widmer)

Calendar Overlays Using Exchange Calendars (Sharad Kumar)

Creating a Centralized PMO Calendar