Blogroll

Month: May 2011

You may have never noticed, but if you look up in the top left of the screen you’re reading this on, you’ll probably see the title of this blog, Project Epistemology. I really came up with that name because WordPress kind of insists on having a blog name and won’t let you create a blog without it.

So the question you may be asking yourself is ‘Why ‘Project Epistemology?’” That’s being charitable I suppose – as a couple times now, I’ve had people misread that as “Project Episiotomy” – which I am sure would also be an interesting blog, but on a totally different topic. (The conclusion there is that I probably should have included more women in my focus groups.)

Well, I figured it was probably time to take a break from writing about the technical to the more esoteric, and explain away the name of this blog so I can point to this post the next time someone asks me where the name came from.

…often combined with the concept of known unknowns – a popular concept in project and risk management:

Unknown Unknowns

Known Unknowns

Known Knowns

Unknown Knowns

So how does that tie back to this blog….? The goal of this blog as I see it is to help me identify the limits of my own knowledge. Each time a customer or colleague asks me a question to which the response is “I don’t know” or “I’ll need to check on that,” I make a record of the topic. That list of known unknowns, much like the library of unread books referenced in Taleb’s Black Swans, represents the topics that I know I don’t know, or the topics falling under the rubric of conscious incompetence.

That list may be derived from other sources as well…newsgroups, other blogs, discussions at user group meetings. On a daily basis, users submit all sorts of fascinating questions to the newsgroups, to most of which my response is “I don’t know.”

In essence, I am leveraging customer and user interactions then to identify gaps in my own knowledge. Then, when I have the time, I sit down and review that list of known unknowns, pick a likely one, do the research and generate a blog post. Each blog post then represents a new check mark in the category of the known known or conscious competence category.

While configuring a proof of concept environment to demonstrate the TFS-Project Server integration the other day, I decided to take notes of my observations. Those notes became a blog post – which you are now reading. I am not sure exactly what the narrative is here, so for now, I guess we’ll just classify this under “Random Musings on the TFS-Project Server Integration Pack.”

First off, when creating a new PWA environment, I noticed that the process of mapping that PWA instance to TFS introduced six new Enterprise Custom Fields (ECF):

It would probably behoove an administrator to add these six fields to an enterprise view within the eGlobal. (hint, hint)

I also noticed that the mapping process created a couple of lookup tables.

I looked through those lookup tables, and they appeared to hold specific values used for the custom fields. Nothing of too much interest.

After mapping the PWA instance to a new TFS collection, I went to upload the default field mapping. Interestingly enough, the upload process kept failing with an error message of:

TFS 294026: The following work item field does not exist: Microsoft.VSTS.Scheduling.CompletedWork. Contact your administrator for Team Foundation Server to add this work item field.

Once I actually created a team project within the TFS Collection, that error went away. Moral of the story: ensure that you have at least one team project before uploading the default field set. My guess is that this will only be an issue in demo environments as any existing environment would already have a team project created.

A couple of other things to note:

Mapping work item types will set the task to Fixed Work in Project unless that is overridden in the original mapping process. This is actually pretty key, and worth noting.

If Team Explorer is open when the project is mapped to the team project, you’ll have to close Team Explorer before the Project Server tab will appear on the mapped work items.

The overall synopsis: developing the POC environment really wasn’t very hard at all, and although I ran into a couple of hiccups, they were mostly based on my own lack of familiarity with TFS and TFS terminology than anything technical. So far, I am pretty pleased with the integration.

Microsoft released the much awaited Project Server TFS demo image a couple of weeks ago, and I sat down this weekend to actually start working with it and getting some hands on experience. This post is not necessarily meant as a highly technical article, but more a first response, archive of my notes, and hopefully provide some assistance to other folks working through the demo image. If I can save someone else some time, great.

This post is specifically written for the demo image released on 4/20 and should not be construed as providing technical guidance for a production installation of the Project Server – TFS connector. All command lines have been tested on the demo image and the demo image only.

Getting Acquainted With the Image

First off, you’ll want to get familiar with the user accounts that you’ll be using for the demo. As near as I can tell, there are basically three:

Administrator – Contoso\Administrator

Lina Abola (PM) – Contoso\LinaA

Peder Thode (DevMgr) – Contoso\PederT

Also note that the password on this image is different than the usual one used on other Contoso images. For more information, you’ll have to download the image and see the accompanying support documentation.

Someone has thoughtfully included the ZoomIt presentation app on the C drive. Great!

Getting Acquainted With the Admin Interface

After playing around with the scripts and trying out some of the scenarios, you’ll probably want to familiarize yourself with the command line interface – partly to look under the covers and partly to troubleshoot issues you may have found during the demo scenarios.

To access the command line, log into the environment as the administrator. From the Start menu, select the Visual Studio Command Prompt.

The most useful command I found was the option to save the log file. This helped tremendously in trying to troubleshoot why or when data was pushed back and forth from Project Server to TFS. Tailored specifically to the demo environment configuration, the following command will yield the log file:

The output only includes errors, so if everything is working, you probably won’t see much in the file. Copy and paste the text into the command prompt and you’ll get a raw Excel document.

Add a table and some formatting, and you’ll get something like this:

…much easier to identify a specific project and why it may not be moving data back and forth.

The second command that I thought was helpful was the command to download the field mapping between Project Server and TFS. Just to see what fields were indeed mapped, the following command did the trick:

TFSAdmin ProjectServer /MapWorkItemTypes /Collection:http://tfspsdemo:8080/tfs /TeamProject:”TFS Project Name” /WorkItemTypes:”Type1,Type2″ (You’ll need to tailor the work item types to the options in the TFS template using that syntax.)

Project and Project Server Tweaks

Change the time zone to something more local. There’s nothing more distracting than looking at the displayed time during a demo and seeing it totally off – or maybe that’s just my OCD.

If you plan to show how to create new Project Server projects, and map them to TFS, you’ll probably want to take the Team Foundation Gantt (Project Server) view out of one of the demo projects and copy it into the Enterprise Global. Make sure to grab the corresponding table, and then to change the names slightly so you don’t get a conflict on opening the demo projects. Finally, go into the view in eGlobal and confirm it’s pointed at the right table.

Save and publish a project. Watch the queue. The queue seems to be stuck more often than not when I open up the image. Restart the Event and Queue services and everything works fine.

Set the site provisioning settings to manual. That way, it won’t create a site every time you create a test project.

Turn off the automatic Windows updates in the Control Panel. I inadvertently left the network adapter connected after activating the image and found out about this one. Windows Updates are set to download and install automatically – potentially kicking off a restart in the middle of a demo. Set it to never check for updates.

And finally, for an optimal experience, if you plan to use Microsoft Project from your host machine to log into the Hyper V machine, make sure you have Team Explorer running, and the add-in active in Microsoft Project. If that is absolutely impossible, you could get by with adding the Work Item Type (TFS) enterprise field to the default Microsoft Project view, but the experience is suboptimal – and it seems to break the functionality to roll up multiple resources from subtasks in TFS to tasks in Project Server.

Watch the log for errors along the line of “TF287005: An item that was changed does not contain a value for the work item type…” to see if that may be an issue. It appears to relate to the fact that the same data should be in both the local Text30 field and the enterprise field – which can be done manually or automatically with the help of the Team Explorer add-in.

Other Random Interesting Things

A couple of other things that may explain observed behavior:

Sync’d tasks become Fixed Work automatically unless the system is instructed otherwise.

Exporting from Project to TFS sometimes seems to take a while. If the data hasn’t been pushed over yet, check the logs. If the logs are empty, then most likely everything is working, but you need to refresh the TFS query.

I figured I’d clean out my old queue of blog posts that I’d written but never published. This particular post was half written when 2010 came out, and was sidelined while I soaked up all of the new product goodness. I then borrowed parts of it for an MVP blog post and never got around to fixing it up. Since I have a couple upcoming “Tips and Tricks” presentations coming up, I figured it was probably time to resurrect it.

This is Part Three in an ongoing series on rolling up the schedule to generate a single, 1 page report. In this post, we’ll talk about roll up options with the Group By Summary feature.

The Group functionality is a powerful reporting tool which can be used when I desire to report on elements of my schedule that may not map precisely to elements in my WBS. As an example, let’s say that I have developed my schedule based on a product-oriented WBS, but I wish to report on the progress of each phase. I would then create a custom flag field to identify which phase specific tasks are in, and then Group By that field to develop an overall phase view. Likewise, if I developed my original WBS as a phase-oriented approach (which I almost never would recommend), and want to map the schedule elements to specific products, I would employ a custom text field and the Group functionality.

Note that from my perspective, the schedule should always be structured to support your primary reporting needs – and coded to support any secondary reporting needs.

The Group By Summary feature is significantly more limited in functionality than the simple Roll Up field. By default, only the Task bars can be summarized using the Group By Summary field. If I want to roll up other key schedule components, like say Critical Path or baseline data, the Group By Summary will not roll up that data.

Luckily, there’s an obscure (but easy) workaround to that issue. In the last several posts, I talked about how I never really like to check the options in the Layout screen to force a roll up of all tasks. My preference is to selectively roll up items using the built in Roll Up field. In this particular case, when I am rolling up data using the Grouping functionality – and I want to roll up baseline and Critical Path information, I would recommend turning those options on.

Here’s what the Format > Layout options look like by default:

And here’s what they should look like when rolling up schedule data to the Summary bars using the Group functionality.

So let’s see how those options affect the following schedule.

You’ll see that I have assigned the tasks to two resources, Lkhagva and Dorj – both names that fall under the category of having been summarily rejected by my wife the last time we were in the market for baby names. (Apparently the fact that they’re gender neutral was not a selling point).

Let’s take a look at how the rollup appears with those options off.

And now with those options on:

You’ll see in the above example that I have rolled up the Critical Path and the baseline data. Typically, my clients may also ask for a rollup of the progress line as well. You’ll note that in the second example, it’s relatively easy to eyeball the schedule to identify the critical path – and to identify which resources are on the critical path at any specific time.

The unfortunate byproduct of toggling on this feature is that now, everything is rolled up to the top level. This may be ok for some users, but I usually feel the view is too cluttered, and wish to reduce the amount of clutter. We can’t use the Roll Up field to remove items from the summary bars, as we have just overridden the use of that field. You’ll see that if you toggle that field to No, the item does not get removed from the Rolled Up view.

In this case, I have found it helpful to create a new custom flag field to serve the same function – basically a Roll Up field for Grouped projects. So I add a custom flag field to the project. For this purpose, I will be using the Flag1 field.

Once adding that to my view, I go through the Bar Styles to add the Flag1 field as criteria for displaying.

Which now enables me to toggle the elements for display using the Flag1 field. In the following example, I have toggled off everything but the Critical Path activities.

I figured I’d clean out my old queue of blog posts that I’d written but never published. This particular post was half written when 2010 came out, and was sidelined while I soaked up all of the new product goodness. I then borrowed parts of it for an MVP blog post and never got around to fixing it up. Since I have a couple upcoming “Tips and Tricks” presentations coming up, I figured it was probably time to resurrect it.

Continuing on in our series on rolling up project data to a single page summary, this post talks about how to roll milestones up to a single summary view. Note that the Rollup component of this discussion may not be as relevant to the Project 2010 users – as they have access to the Timeline view, which pretty much serves the same purpose. That’s not to say that the instructions below will not apply to Project 2010, only that there’s an easier way to accomplish the same thing.

For a look at how to roll up Gantt Bars, take a look at yesterday’s post.

Rolling Milestones Up

Three elements are required to manage the data rollup feature:

1) Format > Layout > Uncheck the first two options. We’ll talk about how to use this feature in a future post. For now, I generally recommend turning it off, as it negates the ability to toggle rollups on or off using the default Rollup field.

2) Summary Task Level Rollup Field – Setting this to No will turn off all rollup functionality for this specific summary task. This should be turned on for any summary task intended to be displayed as a rollup task in the Gantt Chart.

3) Task Level Rollup Field – Setting this field to Yes will rollup the task to any summary task that also has the Rollup field set to Yes. If the summary task has Rollup set to No, this field will not have any impact.

For a better description (with screen shots) of the impact of these fields, please refer back to the last post on rolling up Gantt bars.

In the following example, we have a simple project schedule. I have a number of tasks and a number of key milestones.

My goal is to surface the milestones all on a single line. To do this, I expose the built-in Rollup field, and toggle the summary task and the target milestones to yes. This selectively rolls up the project milestones.

When collapsing the summary bar, I get a view like this. Note that one of the major challenges with attempting this approach prior to 2010 is that the text labels often run all over each other. Additionally, the summary bar somewhat obscures our view of the project.

Both issues are easy to fix. To correct the text placement, I have two options. I can opt to create a custom flag field, and tie it to a specific line in the Bar Styles dialog box, thus allowing me to toggle text position through the use of a custom field – or if it’s just a one-off formatting change, I can simply doubleclick on the milestone in question and modify the text placement. Generally my preference is to use custom fields, as that allows programmatic changes of formatting in the future. By clicking on the item and changing it, we’re creating a new, separate style just for that one item, which we may not want in the future. Note that you can also use custom fields to toggle the milestone into a second row to avoid overcrowding the main swimlane.

In this case, however, to keep things simple, we’ll just click on the Project Started milestone, select the Bar Text tab, and move the name from the top to the bottom.

Now to remove the Summary bar.

Doubleclick on the Gantt Chart to get the Bar Styles dialog box. Add the “Not Rolled Up” criteria to the Summary bar.

And the results are as follows.

So why use this instead of the Timeline View in 2010? In 2010, the Timeline View doesn’t display baseline or progress. You can’t control which text fields are connected to the milestone in the Timeline View. With this setup, all of those custom elements may be displayed, yielding a much richer experience.

I figured I’d clean out my old queue of blog posts that I’d written but never published. This particular post was half written when 2010 came out, and was sidelined while I soaked up all of the new product goodness. I then borrowed parts of it for an MVP blog post and never got around to fixing it up. Since I have a couple upcoming “Tips and Tricks” presentations coming up, I figured it was probably time to resurrect it.

Hence, this post marks the beginning of a multipart series on developing rollup views within the Microsoft Project desktop client. Note that the screenshots are mostly from the 2007 version, but that everything should apply pretty much the same to 2010. I guess at this point, that may engender some points purely for nostalgia.

***

This post focuses on using built-in functionality that a lot of people are not familiar with. In this case, our goal is to generate a simple, 1 page report of an active project using Microsoft Project’s Rollup and Group features. Note that the Rollup component of this discussion may not be as relevant to the Project 2010 users – as they have access to the Timeline view, which pretty much serves the same purpose (albeit with some limitations). That’s not to say that the instructions below will not apply to Project 2010, only that there’s an easier way to accomplish the same thing. The Group section of this post is still definitely relevant to Project 2010.

Understanding Out of the Box Views

Microsoft Project contains a number of Rollup Views out of the box. Few users in my experience have ever used these views, but they’re still there. The 2007 version even included the Rollup_Formatting Macro, which is one of those items that didn’t quite make the transfer to the 2010 product. (For instructions on how to bring it over to 2010, please see Dale Howard’s post on the topic.)

The macro actually performs/performed (depending on which version you’re using) some interesting functions:

It removed any custom bar styles applied to the view.

Toggled how the bars show up within the view (i.e. simply a finish milestone or the entire task bar)

Flag every other task to display the task label above the task using the Flag10 field. This effectively staggers the labels for the tasks so that there’s less chance of text overlap.

Here’s the same view with the summary row expanded. Note how the Text Above field is flagged as yes for every alternate row.

Rolling Data Up

First and foremost, it is important to remember that any schedule should be built upon the foundation of the WBS. That is the crux of effective rollup reporting. Each element of the schedule should be rolled up to match a specific deliverable listed within the WBS.

Assuming that this is indeed the case, then rolling up data will provide an easy to use view listing each WBS item on a specific line. Three elements are required to manage the data rollup feature:

1) Format > Layout > Uncheck the first two options. We’ll talk about how to use this feature in the next section. For now, I generally recommend turning it off, as it negates the ability to toggle rollups on or off using the default Rollup field.

2) Summary Task Level Rollup Field – Setting this to No will turn off all rollup functionality for this specific summary task. This should be turned on for any summary task intended to be displayed as a rollup task in the Gantt Chart.

3) Task Level Rollup Field – Setting this field to Yes will rollup the task to any summary task that also has the Rollup field set to Yes. If the summary task has Rollup set to No, this field will not have any impact.

So let’s take a look at a couple of examples. This is a relatively simple set of experiments borrowed from questions seen frequently on the Microsoft Project newsgroups.

In the first example, we wish to display a set of four subtasks rolled up on one Gantt Line. These may be subtasks or phases within the project.

By toggling the Rollup field, we can get each of the four tasks to show up on the summary line.

Note that if I set the summary task Rollup to No, then all of the formatting goes away.

The problem now is however, how do I visually differentiate the four tasks. To do that, I will add four flag fields, one for each subtask category. We’ll call them Phases 1-4.

Then I modify the Gantt Chart bars. To access this screen, doubleclick on the Gantt Chart. Scroll down to where you see the “*Rolled Up…” entries begin. Note that the “*” before each of the titles tells Microsoft Project not to include that specific label in the project legend when the project is printed. Using the *Rolled Up Task as the base, I insert four lines, and change the colors appropriately.

Going back to the Gantt Chart, this yields the following results:

At this point, I may also opt to change the formatting options for the subtasks so that they match their rolled up counterparts. I can then roll up the tasks to get the following view.

Let’s go back into the Bar Styles and modify the text labels…..

Note that I staggered the names, and put the labels on top for Phases 1 and 3, and on the bottom for Phases 2 and 4. This brings up the single trickiest issue that I have found with managing rollups, and that is trying to ensure that the text doesn’t all land on top of each other. The only solutions I have developed for this would be to use custom flag fields to control multiple bar chart styles, and thus allow me to toggle the text location – or add a callout using the Drawing options.

One more task remains – and that is to remove the summary task black bar. One handy trick when modifying the Gantt Styles is that you can mouse over the offending item to see which element in the Bar Styles Dialog is controlling the formatting:

So we have identified that the offending element is the Summary line. To remove this, I go back into the Bar Styles, and change the criteria for that bar:

And the end results look like this:

Now I point out that this view is pretty simplistic, and doesn’t come close to demonstrating the capabilities of Microsoft Project. In addition to rolling up Task bars, I can also roll up such items as baseline data, progress lines, or other key elements. This means that I can, in theory, roll up an entire view of the project to a handful of lines.

In a previous post, I took the time to review the Bulk Import Tool, one of the Project Server 2010 Solution Starters available for free download from Codeplex. The Bulk Import Tool imports large numbers of projects from SharePoint lists. As I discussed in that post, some of the data doesn’t quite make it into Project Server – or may make it into Project Server in a form that must be edited.

That makes the Bulk Edit Tool a natural next step. This tool allows the user to open any number of projects within the Project Center, and then to change the project level fields in a convenient datasheet interface. In all honesty, I‘ve had decidedly mixed luck with getting this tool to work, and was about to skip a discussion of it, but then I decided to give it a second try.

Thus, I spun up my Hyper V machine, installed the add-in and spent some time understanding how it works. This post represents the results of that second look.

First off, the installation is pretty much the same as the Bulk Import Tool. If you need guidance on how to install it, I refer you to that post.

That being said, the main quirks that I identified in this tool are pretty much as follows:

Sometimes the tool just doesn’t work. I am not sure why. I suspect that it just stops working when the number of projects exceeds a certain limit, but I don’t know. In environments where I can’t get it to work, I fall back on using the Bulk Import Tool to perform bulk edits (as documented here).

When selecting the projects to be edited, the user has the option to add a filter. For instance, if I only want to see the active projects, I can set a filter to only display projects where a custom field called Active=”Yes.” The filter actually seems to work pretty well on non-flag fields. Every time I ran the filter on a flag field, the tool would freeze.

Filters to identify which fields are blank seem to be problematic. For instance, when I filtered on a multiline text field to see if it was blank (=” ”), the filter wouldn’t run.

Filters on text and date fields seem to work just fine.

If you can get past the filter step, the tool allows you to set the values for the selected project fields. Some things that caught my eye here:

Flag fields, which show up in Project Server as offering the option of only Yes or No, show in the tool as having three possible states: Yes, No, and Unknown. As near as I can tell, Unknown corresponds to a blank cell, which is a bit weird as I’ve always learned that a blank cell is the same as entering “No.”

The owner field may not be changed in bulk, i.e. the user can’t select an option at the top and then use the highlight and fill option to populate the cells underneath. The Bulk Edit Tool may still be used to edit the owner field, but each cell must be clicked on one by one. (again, here the Bulk Import Tool is slightly more useful.)

Some fields seem to freeze the tool, for instance in preliminary testing, trying to bulk edit the Hyperlink tool didn’t quite succeed.

After clicking on the option to update the projects, I would recommend the following:

Watch the Manage Queue page to confirm that the server is still processing the projects. Sometimes it’s hard to get the feedback that the server has completed publishing all of the projects.

Review the option to Force Check In Enterprise Objects. Occasionally, some projects got stuck in checked out mode.