Haven’t been quite so active on the blog as of late as I’ve been working on a couple of presentations and enjoying this beautiful south Texas weather with the kids.  Stay tuned as we have some good content getting queued up and due to be released in the next couple of weeks.

In the meantime, please note that I’ll be delivering three presentations at the upcoming June PMI Houston blowout (more details here).

Interestingly enough, they all ended up getting organized in descending order on the schedule:

1) Projects as Innovation Systems – the 80,000 ft overview of projects, innovation, and generally my GUT on problem identification.  Attend if you want to see the PMBOK processes painted in a whole new light, or learn what your project has in common with a puppy dog.  (I thought it might be refreshing if this presentation makes absolutely no mention of any tools whatsoever.)

2) Best Practices in EPM Deployment – the 40,000 ft overview of deploying Enterprise Project Management tools from my skewed and somewhat jaded perspective.

3) First Look: Microsoft Project 2010 - Desktop – the 1 ft in the weeds review of the product which by then should have reached the ripe old age of one month.

I kind of see these topics conceptually as a plane lazily circling as it comes in for landing.

This is a question that’s come up multiple times with folks I’ve worked with, and is something I consider best practice.  The last time someone asked me about this, I figured I’d just blog it up with screenshots and send him the URL.  So Daniel, this post is for you….

For years Project has had a function which remarkably few people know about, and even fewer people use – that is the intelligent WBS Code.  The intelligent WBS code basically entails swapping out the default numerical outline (1.2.3) with a descriptive outline of the task (ABC.DEF.GHI).  There are two main functions of intelligent WBS codes:

1) To clearly identify tasks that have the same or similar names.  Often schedules are populated using fragments of templates.  For instance if I am a professional gaspasser and building a pipeline with multiple compressor stations, I’ll find an old template for compressor stations, then string the tasks into my schedule at various places.  The result of this practice is that I’ll have multiple tasks with pretty similar names.  The intelligent WBS is an easy way to differentiate those tasks in an easy and intuitive fashion.

2) Many organizations need to slice and dice their data in a number of different ways.  For instance, in the following example I am laying pipe in three locations: Harrisburg, Middletown, and Hershey.  I have similar tasks (grading, ditching, laying, cleaning) for each of the areas.  I want to sort by geographic area –or by subsystem – or by subsystem and then geographic area.  That is a pretty typical request from project schedulers that is enabled through the use of the intelligent WBS code.

A lot of schedulers end up creating custom fields to capture similar data and code each new activity with the appropriate metadata.  That is definitely a good practice.  From a tool perspective though, I’ve always felt the WBS code to be a slightly better option to do this as 1) it’s embedded in the system out of the box and 2) the WBS Code allows the user to simply enter data on the summary task and have the data cascade down to the child tasks automatically.  So from a desktop tool user perspective, the built-in WBS code provides a bit more ease of use. 

There’s plenty of documentation out there in the help screens to assist users in using the WBS Code.  My plan with this post is to cover the basics, as well as including a couple of custom formulas to strip different levels out of the WBS Code, and then discuss implications of using the WBS Code in conjunction with Project Server.

How To

This feature has been in the product as long as I’ve been using it.  The default behavior of the WBS Code is to display an outline structure for the project.

However, this behavior can be modified using the Define WBS Code Dialog Box found under the Project > WBS > Define Code menu structure.  By using this dialog box, we can easily create intelligent WBS Codes using text that clearly defines each of the activities.

In this case, I configure the Define WBS Code Dialog Box as follows:

The result is that my project now looks like this:

Now we can see the ease of using the WBS Code.  All I have to do to populate this code is select the summary task, click on WBS, and simply type whatever value I feel is appropriate.

There’s no need to position the cursor in the Input Bar, select text or anything.  Just click on the box and type the code for that summary task.  The program takes care of the rest.  All child tasks automatically take on the same value.

Now, I’ll go ahead and add the other codes to the project:

Again, all I have to is select the WBS cell for the task and type in the appropriate code.

WBS Formulas

So now the question is what to do with this WBS code.  Well, almost on an annual basis, someone asks me about formulas to pull different levels of the WBS from the WBS code.  Here’re a couple of formulas to get you started.  Note that these formulas are predicated on using WBS Codes separated with a period and with a Project Number prefix including a colon.

For example, “PROJ1:ABC.DEF.GHI”

To extract each level, insert the following formulas into a spare Text field.  Make sure to configure the fields to use the formula to calculate summary row values.

As you can see, the formulas got more and more complicated with each level.  I am sure that there are more elegant methods to achieve the same results, but these seem to get the job done.

I added those formulas to my example from above and got the following results:

Which now allows me to group on those fields using a custom Group developed in the Project > Group By menu.  I can analyze the work, cost, or schedule of the digging activities vs. the cleaning activities – or I can see how they work out on a schedule for resource allocation review.

Other Benefits

So once we have these intelligent codes, what can we do out of the box?

We can trace logic using the WBS Predecessor and WBS Successor fields.  If we’re analyzing dependencies created to support a resource critical path, i.e. that we have one pipe laying team, and built dependencies to enforce resource allocation rules, this would be an easy way to identify that logic in the network.

We can also review the tasks at the Assignment level, as the WBS Code extends to the Assignment data for each task:

This allows us to easily differentiate tasks with similar or identical names.

Server-Side Considerations

So the question is now that we have this wonderful feature in the desktop tool, can we use Project Server to surface this information?  Well, that’s a bit of a different challenge.

As a colleague and I found out a couple of years ago, the WBS field can be a bit tricky to use in the Server views.  The crux of the issue appears to be that WBS is published as a Task level field, and the Assignment level data sometimes is difficult to surface in some enterprise views.  Thus, the WBS code is not available in the My Tasks view of Project Server.

Never fail however.  There’s always a workaround.  The easiest method is to just create an enterprise custom field, which I called WBS2, and set the formula to “=[WBS].”  Then set the field to roll down to the assignment level, add to the My Tasks views, and you’re off to the races.

Similarly, those formulas I listed above work just fine as enterprise custom fields.  This will allow you to create grouped and filtered enterprise views just as you would on the desktop.  Following is a Project Detail view including the custom WBS fields.

There’ve been a number of good blog posts/articles in the last week or two on the basics of scheduling and project planning.  I haven’t had the time to capture each and every one of them, but I thought it was worth collecting some of the best ones in a short list here.  If you’re in the scheduling business, then these are well worth the time to check out.

Mosaic Projects on Metaplanning in Construction Schedules

Dan Patterson on Scheduling as a Science

Bruce McGraw of Fear No Project on Developing Quality Schedules

…and the Girls Guide to PM on Scheduling Backwards from Fixed End Dates

From EPMSource via Twitter:

http://www.businesswire.com/portal/site/seattle10/permalink/?ndmViewId=news_view&newsId=20100217007083&newsLang=en

Looking forward to playing with this….should be a great add-in to the tool – specifically the Portfolio Management aspects of it.

I was doing a bit of research into bolt-on desktop reporting tools, and figured I’d post some of the results.  My goal is not to point to specific 3rd party reporting packages, but rather to talk about the concept of desktop reporting tools – and propose a taxonomy that may be of help to those currently looking to supplement Microsoft Project’s native capabilities.  Note that I do not intend to talk about server based reporting tools in this post.

First off, let’s do a quick summary of Microsoft Project’s reporting options:

So with all of these options, why would you want to go to a third party tool?  Well, there are a couple of reasons:

1) The boss likes things simple and colorful, and those offerings just don’t suffice.

2) Your employer/client mandates it because that’s what they want (read: you’re a US federal contractor).

3) You need to summarize complex information into a single page.

4) You need to evaluate schedules prepared in a wider variety of formats.  For instance, you’re a general contractor, and have subcontractors who submit their weekly schedules as Excel tables or exports from Primavera.

5) You wish to track trends on specific items in your schedule

After reviewing the options on the market culled from my own experience and from the MVP FAQ Site, I cobbled together the following classification scheme:

If you’re looking for a tool, I’d recommend first figuring out what you’re looking for in the above categories – and then use that as a decision matrix against the various options.

Following up on our last two posts about authoring resource reports in Visio:

1) Creating an org chart using Resource Pool data.

2) Marrying enterprise data to an org chart.

I wanted to talk about a fundamental concept of reporting with Visio and Visio Services that’s probably self-evident in the Visio world, but requires some introduction to the Microsoft Project community at large – the concept of the PivotDiagram.  PivotDiagrams were introduced as part of Visio Professional (not Standard) in 2007, and allowed us to export our project files from Microsoft Project in the form of Visual Reports.

Now that we’re moving up a notch on the food chain, and using Visio to report on Project Server data, how do PivotDiagrams come into play?  To illustrate the difference between a PivotDiagram and a “normal” diagram in terms that Projecties can understand, let’s take a look at the following two Visio 2010 screenshots.  What is the difference between them?

…and….

You’ll see that the second illustration, which is the Data Selector dialog box from a PivotDiagram chart, contains one more option – the ability to directly pull data from SQL Server Analysis Services.  That is where the OLAP Cube data resides.

When you create a PivotDiagram, what you see is something that looks like this….

…allowing you to slice and dice the data any way you like.  How did I create this view?  Keep reading….

To Recreate This View

To create this view, I first opened a blank PivotDiagram.  When prompted to provide data, I point the wizard at my SQL Analysis Services instance, and pick the MSP_Portfolio_Analyzer cube.

…and, well, that’s pretty much it.  Then it’s just a matter of picking the fields to organize the data by.

Some Considerations

The question that struck me as I was developing this PivotDiagram is how is it different from an org chart?  Well, there’re a couple of different factors:

1) Unless you’re using a custom Reports To field to group by as in our org chart example, you’ll need to define some way of decomposing the organization into logical branches.  There are a number of ways of doing that, but you’ll have to organize your PivotDiagram into units that correspond to organizational cost centers.  This may require the use of additional custom fields, or creative adaptations of the Department or RBS field.

2) If you do in fact recreate an org chart in a PivotDiagram - which is entirely possible - you’ll note that the diagram sums the numbers up to the next level above.  This means that I don’t see the availability of the Departmental Heads, but instead for each of their boxes, I see the sum of all their reports’ data.  This Taylorist data interpretation may be fine for organizations that don’t allow executives to be assigned as resources, but excludes a chunk of data from the analysis.

3) To be incorporated into a PivotDiagram, any custom fields will have to be added to the OLAP cube, and the cube will have to be rebuilt.

Reposting content from Matt McD’s blog:

Announcing Catapult Systems Web Cast Series

Catapult Systems is taking the most popular in-person events and producing a series of web casts.

SharePoint 2010 Webcast Series

• Wednesday, March 17^th - 11:00am CST: Managed Metadata
• Wednesday, March 31^st - 11:00am CST: Social Computing
• Wednesday, April 14^th - 11:00am CST: Search
• Wednesday, April 28^th - 11:00am CST: Improvements in Document & Records Management
• Wednesday, May 12^th - 11:00am CST: Upgrades & Migrations
• Wednesday, May 26^th  - 11:00am CST: SharePoint 2010 Multi-Tenant Hosting

Where: Webcast

Registration Link: https://app.e2ma.net/app2/survey/1404047/205016946/2a25a44aa2/

Business Intelligence Webcast Series

• Tuesday, March 9^th - 11:00am CST: Improvements in BI with SharePoint 2010
• Tuesday, March 30^th - 11:00am CST: Excel Services Integration with PowerPivot
• Tuesday, April 13^th - 11:00am CST: Providing BI Solutions within SharePoint – Practical Examples

Where: Webcast

Registration Link: https://app.e2ma.net/app2/survey/1404047/205016919/c73b2ece3c/

Exchange 2010 Webcast Series

• Thursday, March 25^th - 11:00am CST: Features and Functionality
• Thursday, April 1^st - 11:00am CST: Understanding the Upgrade Path (Exchange 2003 & 2007)
• Thursday, April 8^th - 11:00am CST: Managing Your Exchange 2010 Environment

Where: Webcast

Registration Link: https://app.e2ma.net/app2/survey/1404047/205016780/8b442a369c/

…still playing with the reporting options in Microsoft Office Project Server 2010 and Visio Services.  This is a follow on post to our last story on how to create an org chart using Resource Pool data.  In that post, I talked about how to export the resource data into the Visio Org Chart Wizard.  I am still not sure why, in fact, someone would choose to do this, but one possible option would be to provide a reporting “hook” to hang all sorts of resource data on.

In this post, I’ll introduce some methods of getting data out of Project Server, and then connecting it to the org chart, thereby using the org chart as a navigation aid for resource reporting:

Our goal is to take a chart that looks as follows….

…and combine it with enterprise data.  Easy enough, once you have the initial chart developed.  To start out, we’re going to select the Data option in Visio.  We’re going to point the connection directly to our reporting database in SQL.

Make sure to connect to the appropriate table within the database.  In this case, we need resource data and will use the MSP_EPMResource_UserView table.

This gives us a list of all the fields within the table.  We can opt to import all of them, or just some of them.  Make sure to import the Resource Name and/or the Resource UID if you decided to use that as the primary identifier in the org chart development.  Since most of the Resource tables refer back to the Resource UID, I would encourage you to use that field.

In this case, I am keeping things simple, and just importing three fields.  Basically, we’re going to attach some demographic data to the org chart.

You’ll see the data show up in the External Data window at the bottom of the screen.  Select Automatically Link to marry the SQL database with the org chart reporting structure.

Identify the unique identifier….in this case that is the Resource Name.

And you’ll see the chain link against most of the rows in the External Data window, showing that the system linked the database data dynamically to the Visio shapes.  I can now click on any of the Visio shapes to display the Shape Data Window with our newly imported data.

Incorporating OLAP Data

Well, that’s relatively easy for nontimephased data.  But what if I want to marry OLAP data with my chart?  That’s a bit more complicated, but doable.  The first question is of course, why?  OLAP data is best served by importing into Visio using the PivotDiagram functionality.  That will be a subject for another post.  But let’s bypass this question for now, and just assume that we want to marry OLAP data to a flat org chart.  To do this, we need to first export the data into a dynamic Excel worksheet, and then import into Visio.

First off, we open Excel and add a PivotTable.  Add an external connection to provide the table data, and point the connection to the OLAP cube in Project Server.

The cube we are using is the MSP_PortfolioAnalyzer.  I’ve added a calculated Utilization field to track how many hours are assigned to each resource – and perhaps to annoy any TOC consultants who may be reading this post.

Saving the worksheet to our local machine or to a SharePoint library, we now navigate back to the org chart we already created in Visio.  Add a Data Link to the new Excel worksheet.

Select the columns to include.

The data is now imported into the Visio file.  Now just run the AutoLink command to link the OLAP data to our org chart report.

And we now have OLAP data married to each of the resources identified in the org chart.

Presenting with Visio Services

Reports ain’t nothing unless they can be presented in an easy to use, easy to navigate fashion.  Luckily, we can do that in SharePoint 2010 with Visio Services.  In this case, I save the file as a Visio Web Drawing (.vdw) file.

And now I have an attractive, intuitive report, where users can simply select a resource and see dynamically updated data pulled from Project Server.

More along the lines of playing at the intersection of Visio reporting and Microsoft Office Project Server 2010.  The question I was looking at today was how to export the Resource Pool from Project Server into an organization chart format in Visio.  I used the Microsoft demo image and was able to generate a rough Contoso org chart as appears below:

The first question is why would anyone want to do such a thing?  Honestly, I am not sure what that answer is quite yet, but this sort of report would seem to be a nice hook to add other reporting data to – for instance I can create an org chart, and then pair it with Availability/Work data, Risk/Issue data, or even a list of tasks – thus allowing me to navigate through an intuitive org chart format to get the data I want.  This exercise also allows me to see what’s possible, and what’s a bit less possible with Visio and the integration with Project Server. 

The Visio Organization Chart Wizard

The Visio Organization Chart Wizard can import data from your Exchange Database or from an Excel table to automatically create an organizational structure.  When importing from Excel, the reporting dependencies are defined using a column called “Reports_to.”  For instance, if the table looks like this…

….then Visio will import a diagram that looks like this:

So, the first thing we need to do is define the reporting relationships within the Resource Pool.  There’s a number of different ways to do this, but if we wish to work with the Visio Org Chart Wizard, then we need to use names of other resources as part of our Reports To field.  In theory, we could use any field where a manager’s name might be listed, perhaps something like the Timesheet Manager or Default Assignment Owner.  I considered using those fields for this example, but my feeling is that the Timesheet Manager is rarely defined to the level of granularity that would be required to develop an org chart.

The Wizard can import data from Exchange – and as a result, you may not have to go through the following steps to develop an org chart using Project Server data specifically.  It would probably be much easier to just generate an org chart from AD and then use that for reporting purposes. 

My assumption for this exercise is that we decided to go it alone, use Project Server data, and don’t want to mess with AD.

Preparing the Project Server Data

So in this case, I created a new field called Reports To and tied it to a Lookup Table listing Departmental Heads.  Here is the screenshot of the Lookup Table configuration.

You’’ll note that this is actually not too hard to keep updated, based on the fact that each of the items are tied to a resource using the Lookup Table GUID.  This means that I can swap out Lisa Andrews, the head of IT, with Landon Howell, the hypothetical new manager, and all of the resources will automatically take on the new change as an attribute.

Then I create a new Resource field called Reports To and tie it back to the Lookup Table.  You’ll note the exciting (to me anyway) feature introduced in 2010 that allows you to include comments on the new Enterprise Field.

In this case, I have set Don Funk as our corporate head that everyone reports to.

Now, we have one simple task to get the data ready – assign a Reports To selection to each of the resources in the Resource Pool.  In the future, I could envision this as being part of the new resource setup procedures – just like any other custom Resource field.  To accomplish this, I navigate to the Resource Center, filter on named resources, and open them all into Microsoft Project. 

Again, here you’ll note some minor improvements over the 2007 interface.  In 2010, I can click on the column header in a PWA view and get a number of options to sort, filter and/or group the data.

Modify in Microsoft Project and save back to the Resource Pool.  I assign the Departmental Heads a Reports To of Don Funk, our hypothetical corporate CEO.  Don Funk’s Report To selection should technically be blank – but we can fix that later on when we import into Visio.

Save the data back to Microsoft Project Server, close the file, and we’re done with Project.

Getting the Data Into Excel

We now have a couple of options on how to get that data into Visio.  We can simply open up a Visio chart and link directly to the Resource_UserView table in the Reporting Database.  That will give us all of the data we want, but it would seem to bypass the Org Chart Wizard import mechanism that creates all of the reporting relationships for us.  Those dependencies can be rebuilt using some custom coding, but my preference is for a no code solution.  We could import directly from a SQL database, but I have to admit that after some research, I still haven’t quite figured out how to do that.  (But when I do, I’ll provide an update to this post).

Therefore, I had to go another route, bring the Resource Data into Excel, and then import it into Visio, thus allowing us to trigger the Org Chart Wizard to import the data.  This will not be a dynamic link, and we will have to refresh the workbook and reimport when the resource data changes significantly – but that would not be too labor intensive.

In this case, I could do a cut/paste from PWA or MPP to Excel, or in order to create a repetitive process, I am going to just create a new Office Data Connection back to the MSP_EPMResource_UserView table in the Reporting Database.  This will give me a spreadsheet that I can refresh on a routine basis to feed back into the Visio Org Chart Wizard to provide a new base for reports.  Open Excel, select Data, create a new ODC for SQL Server.  (We have to create a new ODC, because the default out of the box ODC files are hard coded with the default fields, and will not include our new custom Reports To field.)

Configure the ODC file to hit the right table in the database.

This will generate a table in Excel replicating the MSP_EPMResource_UserView table.  We filter out the generic resources and eliminate the superfluous columns.  (Note that can all be done when creating the ODC file as well).  You may wish to consider including the Resource UID field to link the org chart with future data from the Project Server database.  In this step, I am also going to rename the columns to match what Visio looks for in the import process – although that is not strictly required since we can also map the columns during the import process.

Save the resulting file to your desktop or to a SharePoint library.

Import into Visio

Now we can open up a new file in Visio using the Business > Organization Chart template.  Kick off the Org Chart Import Wizard, and point the dialog box to our existing Excel file.

Make sure the columns all map appropriately:

Pick the fields to display in the shapes.

Pick data (if any) to show next to the shapes.  My preference is not to show anything now, as it just clutters up the chart.

Choose the appropriate options for a single page vs. multiple page layout.

You can now modify the results to include a page for each department – or roll everything up to one page.

By selecting modify page, we can assign the overall oversight role to Don Funk.

And we now have an org chart with all of our Resource Pool nicely laid out – and ready for publishing to SharePoint using Visio Web Services.

We can do a lot of things with this org chart, things that I will be blogging about in upcoming posts.  Some examples may be:

1) Linking the report to other webparts as documented here.

2) Adding OLAP Cube or other Reporting Database data to the Report to provide a navigation interface for portfolio data.