Task Type Use Cases in an IT Environment

In training sessions, my students traditionally have a tough time grasping the concept of task types and how they may be applied in the real world.   I often get the question of “Which task type would you recommend for ‘XYZ’?”  To which the response is almost always, “It depends.”  In this post, I figured I’d spend a little time talking about my own personal practices, and see if that sheds some light on task type usage patterns.

Task Types

First off, what are the available task types?

  • Fixed Duration
  • Fixed Work
  • Fixed Units

These task types play the part of variables in the Duration X Units = Work equation that Microsoft Project uses as the basis for a fair number of scheduling calculations.  (Note that the Duration X Units = Work equation should probably be more accurately depicted as Duration X Units (X Person Hours Per Day) = Work.)

The general way to identify which task type you would like to use is to ask yourself the question, “Which of those three variables, Duration, Units, or Work, do I know at this point?  Which variable will not change?”  That is the variable that should be fixed.

Planning the Project

Great in theory, but how does that work in practice?  Let’s take an IT project as an example.  As a consultant, I am often called upon to decompose the project scope and to identify the tasks required to complete the scope.  Since work frequently on similar projects, i.e. Project Server deployments, I might start with a schedule template that already lists the tasks and dependencies.

So my first goal is to work through that schedule list and attach work estimates.  At this point, I am not attaching duration or calculating a real schedule.  All I am doing is working through the list, and adding an estimate of work to each task….80 hours here, 20 hours there, 4 hours there.  Now here’s the trick.  Unless I uncover something new during the planning/estimating process, those hours will not change.  They probably will change when I get into the actual execution of the project, but we haven’t gotten there yet.  Hence, I will set those tasks to Fixed Work.  I don’t want those estimates to change.

Once I’ve gone through a first cut of the schedule and attached hours to the tasks – and set the tasks to Fixed Work, then I’ll go through and play with either the units of allocation of a resource or more likely the duration of a task.  I run through the project and start assessing duration for each of the activities.  Since work is fixed, and I am editing duration, the units field will recalculate – which is what I want.  My duration estimates are usually based on client availability estimates, i.e. I will assume that requirements gathering may take longer or shorter depending on the number of people involved in defining requirements or the complexity of the project.

Again though, unless I uncover something new during this process, the work estimates do not change.

Tracking the Project

Once I’ve reviewed my estimates, added calendars and constraints, then smoothed the overallocations, I tend to flip all of my tasks from Fixed Work to Fixed Units.  “Why?” you ask.  Well, when you get into execution, that’s when I am pretty sure that my work estimates will change routinely.  Similarly, I am pretty sure that my units will stay pretty stable – or at least they will do so for future estimates.  Past estimates will be overridden by the actual hours entered in the system.

So every week, I fill in my timesheet, and my actual hours get transferred back to my plan.  If I book more hours than I expected, units are fixed, and the duration comes in.  If as happens more often, I book less hours than expected, units are still fixed, and the duration gets pushed out.  If, based on partial completion, I change my work estimate, again units are fixed, and the duration is recalculated.

Hence, generally, in an IT environment that tracks hours, I would recommend using Fixed Units task.

So there you have it…..a long winded explanation of why “It depends” is a valid answer.  My recommendation for this specific scenario would be Fixed Work during the estimating and Fixed Units during the execution of the project.

Task Type Use Cases in an IT Environment

Considering a Large Project Server Implementation? Read This….

I’ve been heads down on a large implementation myself for the last couple months, and must’ve missed this one.  Check out this white paper from my colleague and frequent collaborator, Victor Richardson, where he breaks down deployment scenarios for the poorly understood multi-site collection Project Server install.

Link to PDF

Considering a Large Project Server Implementation? Read This….

Surfacing Risk Data in an External List

…so now that we have a custom SQL view developed and that data is surfaced in the form of an External Content Type, let’s add it to our SharePoint site.

Navigate to a SharePoint site, select the option to View All Site Content, and create a new External List.  If you plan to modify this list using SharePoint Designer, you’ll need to provision the list on any site but the main PWA site.

image

The list will appear as follows:

image

Add a grouping by Project Name, and you get the following…

image

Formatting the External List

To get fancy, you can even add conditional formatting to the External List.  To do so, open the list in SharePoint Designer.  Click on one of the cells in the column you would like to format, and choose the option to apply Conditional Formatting. 

image

Add the appropriate options, hit Save, refresh the page in the browser, and you should see something like this….

image

Search around the Web, and you should be able to find all sorts of blog postings about how to add icons instead of simple conditional formatting.

Removing the HTML Tags

One thing you may note is that some of the text fields have HTML tags.  This is because the fields are stored as rich text fields and then surfaced as plain text.

image

There’re probably a couple ways to fix this, including using both SQL and SharePoint Designer functionality.  Until I figure those out however, I simply went to the Project Site and converted the fields in the SharePoint Risk list from rich text to plain text. 

image

That solved the issue and doesn’t appear to throw errors on publish.  Note that you will have to republish the Risk InfoPath form if you make any changes to the fields.

…and there you have it, a more or less out of the box way to create an aggregated Risk list.  With a little practice, it shouldn’t take more than a couple of hours to implement.

Surfacing Risk Data in an External List

Creating an External Content Type for Project Risks

In this post, I will talk about how to surface the custom SQL view we developed in the previous post through External Content Types and SharePoint Business Connectivity Services (BCS).

Now this isn’t a new topic.  The only difference is that we’re using it to surface risk information.  For more information on deploying ECT against Project Server, please see one of my older posts.

….and, er….that’s pretty much it.  Not sure how much more I can add to that.  Once you’ve done that against the new custom SQL view, it will look something like this:

image

Next up….adding the data to an external list.

Creating an External Content Type for Project Risks

Customizing SQL Views to Provide Useful Datasets

In my last post, I decided to take a look at how to use External Content Types to surface Project Server Reporting database data on Risks and Issues.  In this post, I plan to talk about some quick and easy steps that are required to provide a useful dataset.

Now, before we get too far into this post, I should probably mention that working directly in the database is always a sensitive issue, but as far as I can tell, adding a custom view to the Reporting database will not cause supportability issues going forward.  Just make sure that everything is documented and backed up.  Now back to the narrative…

The challenge that I found when I first started playing with the risk tables in the Reporting database was that none of the risk tables seemed to include the Project name.  A couple include the Project ID field, but that won’t help when it’s surfaced in an External List.

image

…so I decided to create a custom SQL view.  To do that, I fired up SQL Management Studio and navigated to the Reporting database.  Once I found that, I right clicked on the Views option to create a new View.

image

From there, it’s a relatively simple matter to select the WSSRisk_Olapview and EPMProject_Userview tables to be included in my view.  I check the fields to be included, and then add a join at the ProjectUID field.  (If you’re not familiar with this interface, it works much like Access, you just grab the ProjectUID field from the table on the left and drag it to the one on the right to generate the join.)

image

Save the Custom View, and you can now use it for reporting purposes, whether that report is based on an External Content Type, an Office Data Connection file, or a direct connection back into SQL.

image

Customizing SQL Views to Provide Useful Datasets

Centralized Risk Repositories with External Lists

I was plugging away at the Project Server newsgroup when one of the contributors asked an interesting question.  After trying to aggregate Issues from each of the project sites to a single centralized repository using Content Query Webparts, Bart E. asked, “So there is no OOTB solution for a sortable aggregation, I take it?”

….well, that got me to thinking.  Is there an easy out of the box solution to deliver centralized risks and issues from Project Server?  The obvious solution would seem to be through the use of External Content Types, which I have come to regard as the Swiss Army knife of the SharePoint 2010 world.  Using External Content Types and External Lists would allow the development of easily customizable lists of aggregated risks.

So I sat down with a virtual image to see if I could make it work.  To my surprise, 20 minutes later, I pretty much had it working – with some minor formatting issues that took me back to the drawing board.

Hence my next couple of posts will be about this topic, specifically how to use External Content Types to surface the risk information embedded in the Project Server reporting database.  This approach is only suitable in the following circumstances:

  • Projects are published primarily from the Microsoft Project client – as that is the action which seems to refresh the database from the Project site data.
  • Risks are managed without custom fields, or at least the aggregation does not require those custom fields to work.  The Reporting database only captures the default fields.
  • Project schedules are updated regularly.  It is through the update process that the risks are populated within the Reporting database.

First, let’s start with a little review of the available literature.  What options are currently available?  Here are the ones I’ve come across so far.

  1. SSRS Reports – as documented by Christophe Fiessinger here.
  2. Third party tools such as this one from iPMO.
  3. Utilizing the Content Query Webpart within SharePoint – which required a little more coding the last time I played with it than I was comfortable with.  Still, probably worth a blog post at some point in the future.  A variant of this approach would cross site collections and might include something like the Content Monster Webpart.

This series of posts will focus on a fourth method, using External Content Types and an External List to surface Reporting database data.  You could probably do the same with a Web Service pulling data from SharePoint content databases, but I would defer to the SharePoint folks on that.

Hence, over the next couple of days, watch out for the following posts:

  1. Customizing SQL views to create the dataset
  2. Creating an External Content Type from a customized view
  3. Creating an External List with Risk data

(My plan is to come back and add hyperlinks to this post once each of those individual posts have been published.)

Centralized Risk Repositories with External Lists

Back to the Basics: Calculating Duration in Fixed Duration Tasks

My colleague approached me with an interesting question the other day.  Under specific conditions, he could make seemingly identical tasks appear with different durations.

image

So the question is “why?”  Why do seemingly identical tasks have different durations.  First off, lets look at how duration is calculated…

Fixed Duration Activities Without Assignments

In the example below, I have three tasks.  Each task is a different type.

image

You’ll note that the duration is the same.  Next, I will introduce an exception of one day in the Project Calendar.  In theory, this will push out the finish date for each task.

image

The results appear as below:

image

We see that the duration has not changed, even though the tasks now finish up on 6/13 instead of 6/10.  This is as expected, because the duration is calculated as the total number of working days, and excludes any nonworking days such as weekends or holidays.

Fixed Duration Activities With Assignments

Now let’s assign a resource to each of those tasks.

image

Everything looks correct.  The resource is using the same Project Calendar, and therefore, we anticipate no changes.  Here’s where things get a bit trickier.  I am going to add a 1 day exception to my resource calendar.

image

…and now my schedule looks like this:

image

See how the duration shows differently, yet for all intents and purposes, the start and finish dates are identical?

The reason for that is that Fixed Duration activities ignore the resource calendar when calculating duration.  A Fixed Duration task calculates the difference between the start and end date using the Task or Project calendar.  In this case, since I haven’t applied a Task calendar, the calculation uses the Project calendar.

Fixed Unit and Fixed Work tasks on the other hand, calculate duration by counting how many days on work is actually assigned.

image

Back to the Basics: Calculating Duration in Fixed Duration Tasks