We’re finishing up a couple of deployments of Project Server 2010 wherein we did a number of custom workflows for the clients, and I thought I’d pass along some lessons we learned, some the hard way.

First, a bit of clarification: I’m talking about “Demand Management” workflows, not document approvals or anything else you might write for the SharePoint Foundation workspaces. Demand Management workflows leverage a number of configurable objects in Project Server 2010 – things like phases, stages, Enterprise Project Types, and Project Detail Pages.

We got a lot of help from the friendly folks at Microsoft when it came to documentation on customizing workflows. We needed it, as it was a bit of a hunt to find a centralized list of these documents. Here’s a stab at exactly that:

• Hitchhiker’s Guide to Demand Management – this is a great starting point. It’s a write-up by Steven Haden which is step-by-step through some of the samples included in the out of the box tool as well as the SDK.
• A Webcast of Steven’s presentation on the same material from the Project Conference
• TechNet library dedicated to Demand Management – some good Webcasts and Microsoft technical documentation on the functionality. A little more advanced help..
• MSDN content on Project Server workflows – good info to get developers up and running. Good info on setting up Visual Studio, and basic workflow development tips.
• Webcasts covering various topics in workflow development
  • Walkthrough of the Out of the Box Sample Proposal Workflow
  • MSDN Webcast – Workflow Deep Dive
• A catch-all blog post (updated in June) of content on Demand Management and workflows

• Second lesson: These are NOT your typical SharePoint workflows

There’s no GUI, no SharePoint Designer, nothing like that, in the out of the box tool. If you want to modify the workflow or create custom workflows, you are going the Visual Studio route, UNLESS you spring for a third party workflow tool. We wound up with the Nintex Workflow for Project Server 2010 tool.

Now, I don’t want to turn this into an unpaid plug for Nintex, but we did have a good experience with their product. You do have to buy and install the base Nintex Workflow for SharePoint tool before you can buy and install the Project Server component, and this stuff isn’t cheap (although “cheap” is, of course, entirely relative, esp when measured against development time).

While workflows are, by definition, pretty complex, and you should not underestimate either the topic or the tool, our experience is that a competent PMO process wonk can handle assembling fairly complex workflows in the Nintex tool with a little ramp-up time. This is obviously good news to PMO process wonks, as it makes process design and tool configuration sort of the same step.

• Some other notes on workflows:

We really liked the flexibility of Project Detail Pages (PDPs) and Workflow Stages. PDPs, while a little clunky to design and build, really are great for gathering the type of information most organizations currently find trapped in spreadsheets, Word docs, PowerPoint slides, etc.

The design of the Project Server workflow “engine” leaves a lot of room for what Microsoft likes to call “Partner Opportunities”. I think that’s the right decision, especially in these early stages of the product. Nintex, and the other tool vendors, bring a ton of background with SharePoint and workflow to the table. Their tools have been field tested extensively. And while the price tag for these tools is what it is, you do get bang for the buck.

Our overall impression of demand management is there is a ton of power here, and ton of organizational appeal. PMOs everywhere can use this functionality. If your organization has a project initiation and selection process today, and you find yourself being the middleware that turns Word docs and spreadsheets into Project Server information, look into demand management. If you’re just now getting a process sorted out, you can automate a great deal of it using Project Server 2010.

Welcome to 2011! With the new year comes some changes here at the Catapult Systems EPM Team blog.

As you may have surmised from Andrew's most recent post, blogging responsibilities have shifted to little old me. My name is Peter Elkin. I have been with Catapult Systems for a little over four years, and have been helping clients implement Microsoft Project Server for nearly eight years (yep, that takes me back to the Project Server 2002 days).

My background and training are in project management. I spent most of my early career as a PM with one of the big multi-national financial service organizations (the names have been changed to protect the innocent). It was my frustration with managing resources, reporting progress, dealing with seemingly arbitrary reprioritization at the drop of a hat - all the usual big-company project management pitfalls – at said unnamed institution which led to my interest, and eventually my career, in Project Server.

I think you’ll see a shift in the focus of posts here over the next few months. Andrew’s deep delving into, and deep understanding of, the theory behind and practice of the optimization engine, resource analysis, reporting, and some of the other feature areas of Project Server 2010 have been, IMHO, of huge benefit to the EPM community. It’s not for nothing the guy’s an MVP.

My own take is going to focus a little less on the possibilities of Project Server 2010, and more on the solving of real-world business problems using the tool set. I’m an implementer, and we’ve got implementations stacked up in our pipeline, so we’ll have lots of opportunities to focus on client challenges and discuss how we resolve those challenges using Project Server 2010 and it’s ecosystem of related tools and techniques.

I hope to continue the dialog Andrew has established with many of you. Please feel free to hit the comments section with any sort of feedback or question which comes to mind.

I’m looking forward to becoming a member of the EPM blogocracy! Thanks for reading!

The New Year is fast approaching, and with it all of the cultural baggage associated with transitions, ringing out the old, bringing in the new, and all those other tired memes.  Usually, the New Year is a non-event for me…an opportunity to freeze in the open air, an evening of quality family time perhaps but rarely anything exceedingly memorable.

This year though, the event is more salient as it marks a significant professional transition of my own.  As I look forward to next year, I am reminded of an experience I had a while back, in a previous life, when I was teaching English in a small rural middle school located in the rolling white khangai, smack dab in the middle of Mongolia, which in turn is sandwiched between China and Siberia.

We were celebrating New Year’s Eve in a school gymnasium (i.e. the biggest enclosed space in town), and I guess it was sometime before midnight when my buddy comes up to me, and tells me (in Mongol), “You think this is fun now?  Wait till the clones come!”  …or at least it sounded like the English word for “clones.”  Needless to say, I was mildly confused. 

So there I sat, for about a half hour or so, sipping vodka and wondering with a mix of trepidation and anticipation what would imminently walk through the gym door.  As I plan my professional activities in 2011 and beyond, that’s kind of how I feel right now, like I am sitting in that cold gym, listening to the Siberian wind outside and waiting for the “clones”…(which eventually turned out to be harmless and mildly entertaining “clowns.”). 

It’s been a little over a year and half since I started actively contributing to this blog, and it’s definitely been a positive experience all around.  This little ol’ blog has driven me to explore the world of EPM tools and related deployment issues in all sorts of ways that I might not have otherwise done.  Posting here has prompted some great conversations both on and offline, and has resulted in a mountain of content that I am sure will provide much value in the future.  This corner of the Internet will always have a special place in my heart.

To those of you who read this blog regularly, I extend my appreciation, and invite you to continue the discussion.  I will not be monitoring the comments any longer, but me being me, I don’t think I’ll stay away from the blogosphere too long.  Stay tuned via LinkedIn, Twitter, or the Project newsgroups to see where I may pop up next.

To those of you who’ve worked with and supported me over the last couple of years, I thank you very kindly.  As I tell my family each day, I still don’t know how you managed to put up with me for so long.

I just wanted to post this as follow up to an interesting thread that started a while back on one of the Project Server newsgroups.  The thread, originally started by Rambunctious was asking how to get the name of the parent task for each child task out of the Project Server database for use in an Excel Report.

Barbara Henhapl provided an excellent response, which I am reposting for posterity with her gracious permission.  (Thanks also to Rambunctious for posting the original question.)

1) Modify the ODC file used by the Excel report to generate the appropriate data set.  For more information on modifying the ODC file, please refer to this post.

2) Specifically, the change you would make is to pull the TaskParentUID field for each task in the MSP_EPMTask_UserView table, and then tie it back to the TaskName field using the following syntax:

SELECT     SummaryTask.TaskName AS SummaryTaskName, Tasklist.TaskName
FROM         dbo.MSP_EpmTask_UserView AS Tasklist INNER JOIN
                      dbo.MSP_EpmTask_UserView AS SummaryTask ON Tasklist.TaskParentUID = SummaryTask.TaskUID

3) To make that easy, Barbara went ahead and pulled the ODC file from the Projects and Tasks demo report in the BI Center templates folder, and modified that to include the key fields.  The result should look something like this text file.

What does that get you?

…which I bet would work with the technique I described in this post to make a dynamic WBS based view of the project for reporting purposes.  (Not that you couldn’t do so with Visual Reports, but I wonder if there might be an advantage to doing it this way.)

Thanks again to Barbara and Rambunctious for prompting the thoughts…..any mistakes in this posting are definitely mine.

I realized that I still had a couple of these Resource Analysis posts sitting half written in my queue and figured it was about time to put some finishing touches on them and kick them out the door.  That being said, welcome to the latest posting in my Resource Analysis Under the Hood series – where I attempt to explain away some of the mysteries of the Portfolio Analysis module.  This post represents my breakdown of the Scenario Commitment functionality. 

For previous postings in this vein:

1) Introducing the Resource Analysis Worksheet

2) Configuring the Resource Pool

3) Configuring the Resource Analysis Parameters

4) Organizational Capacity Planning

5) The Baseline Calculation (Part 1)

6) The Baseline Calculation (Part 2)

7) Performing What-If Analyses

8) The Requirements Details View

9) Incrementally Adding New Resources and Cost (Part 1)

10) Incrementally Adding New Resources and Cost (Part 2)

12) Comparing Project Selection Scenarios

11) Enforcing Project Dependencies

…and probably a couple more that I can’t recall at this point.

The Basics

The observant user may note the existence of the Commit button within the Portfolio Analysis module.

The Commit button triggers the population of a total of 6 project level fields.  Those 6 fields are:

1. Committed Planned End Date
2. Committed Planned Start Date
3. Committed Portfolio Selection Decision (Cost)
4. Committed Portfolio Selection Decision (Schedule)
5. Committed Portfolio Selection Decision Date (Cost)
6. Committed Portfolio Selection Decision Date (Schedule)

The Help screens helpfully describe what the fields do:

These fields are all available from the Project Center view field picklist (although given the length of the names, it’s kind of hard to tell which field is which in the dialog box).  Below, I’ve created a custom Project Center view to display all of the key Committed fields.  I’ll use this to illustrate the action of the Commit button.

Note that these fields appear to be populated directly to the Published version of the schedule.  After clicking Commit, there is no need to republish the projects to update these fields in PWA.

Committing Cost Analyses

When committing analyses, it’s important to commit in the proper order, i.e. Cost and then Resource.  This is because the outputs of the Cost Analysis drive the inputs to the Resource Analysis.  If the Resource Analysis is committed first, the Cost Analysis may overwrite the results.  Given the fact that the Resource Analysis portfolio of projects is the subset of projects that were selected in Cost Analysis, this progression would seem to make sense.

In the below example, I committed the Resource Analysis first….

…and then the Cost Analysis.  You’ll see that the Resource Analysis figures were wiped out.

The Cost Analysis does not commit the schedule data, such as the Planned End Date and Planned Start Dates.  Those are populated from the Resource (i.e. Schedule) Analysis.

Committing Resource Analyses

The Resource Analysis commits both the Cost and Resource Analysis – as you’ll note both sets of fields are populated when the Resource Analysis is committed.

Other Notes

• The Commit button is intended not only to populate these 6 fields, but also to serve as the trigger for custom workflows.  In fact, one can argue that the Commit button is most importantly intended to kick off some sort of approval workflow in the portfolio analysis process.  You could also tie a workflow to the Forced Out projects prompting a review procedure at a later date.
• The Commit functionality complements nicely the new command in Project Professional 2010 that allows you to shift the entire project forward or backward in time.  Thus, once the scenario has been committed and a Planned Start Date has been defined, the Project Manager could open the file in Microsoft Project, plug in the new Planned Start Date, and have the entire project shift accordingly.
• If the project is selected in multiple analyses – which I imagine would be a mistake, as I can’t see a valid use case where that would logically occur, the most final analysis commitment will override the fields.
• In the category of wish list items, I’d like to see the actual name of the Analysis used to support committing the project as an available field.  I’ll have to look into the database schema to see if I can generate up a list of projects and the associated scenario.

Thanks to Larry C. for reading my posts on the Portfolio Analysis module of Project Server 2010.  He’s been after me for some time now to address the role of project dependencies in portfolio analysis – to which I keep responding that I’ll get around to it in December.  Well, the last time I checked, the calendar appears to display December.  Hence, Larry, this post is for you & thanks for the peanut butter ball recipe.

This post also represents my first blog foray into the domain of portfolio dependencies.  Therefore, please consider this post to be a quick introductory post, to be followed at some point in the future with some more nuanced investigations of the specific behaviors of each of the dependency types.  Hopefully, the anticipation of that content will not be too much to bear….

The Basics

Conceptually, dependencies imply relationships between specific projects within a given portfolio.  The challenge is really in understanding the types of dependencies, and their respective impact on the analysis calculations.  Note that Project Server 2010 allows the use of four distinct kinds of dependencies – but more on that later.

Dependencies are implemented on a project level in the main Portfolio Analysis page (i.e. http://servername/pwa/_layouts/pwa/portfoliostrategy/analyses.aspx).  Simply click on the Portfolio Analyses link in the main site.

In the Portfolio Analysis view, the option to implement Project Dependencies is in the Analyses tab at the top of the page.

When clicking on the button, you get to the Project Dependencies screen, which allows you to define the four types of project dependencies:

Dependency Types

The four types of dependencies available are:

1. Dependency
2. Mutual Inclusion
3. Mutual Exclusion
4. Finish to Start

Here’s a quick rundown of each of the four types…

Dependency – the primary project will not be selected unless all of the dependent projects have been selected.  No sequence is implied, simply an all or nothing selection mechanism.

As far as I can tell, this does not imply the primary project will be selected if the dependent projects are selected – but the primary project will not be selected if all of the dependent projects have not been.

Mutual Inclusion – This dependency is similar to the Dependency dependency (if that sentence makes sense).  In this case, it really is all or nothing.  Either all projects are included, or all projects are excluded.  Consider using this dependency in the scenario of a program, where each of the projects must be implemented to garner the benefits of the program.

Here’s what the help screen says on the Mutual Inclusion dependency: Select the projects that are ALL dependent on each other. If one project from the set is executed, all other projects from the set must also be executed.

Mutual Exclusion – On the converse side, the Mutual Exclusion Dependency means that we may have multiple competing projects.  Our goal is to pick the project that generates the maximum strategic value, but once selected, negates the need for any of the other projects.  Think about using this if you have multiple competing avenues to achieve the same goal – but only one is required.

Here’s what the help screen says on this dependency: Select the projects that are ALL exclusive to each other. If one project from the set is executed, all other projects from the set must NOT be executed.

Finish to Start – with Finish to Start dependencies, the user selects a primary project that must complete prior to the start of successor projects.  This dependency does not imply the successor projects will be selected, but only sets the stage for the sequence in which they may be selected.  I could see this dependency being used in conjunction with the Mutual Inclusion dependency to ensure that all projects in a given sequence are a) selected, and b) selected in the appropriate sequence.

Here’s what the help screen says on this dependency: Select the projects that must start after the primary project finishes. 

Put it all together, and all of the dependencies are displayed as shown:

Enforcing Dependencies

So far so good.  A little bit complicated, but all in all fairly straightforward.  Here’s where things get a little bit more interesting.  First off, a quick review….here’re the four dependency types again:

1. Dependency
2. Mutual Inclusion
3. Mutual Exclusion
4. Finish to Start

By default, even though these dependencies may have been defined, they are not enforced unless the user specifically indicates to enforce them in the Cost and Resource Analysis screens.

In the Cost Analysis screen, you will find the option to enforce Project dependencies in the Options tab.

What’s mildly confusing perhaps is that in the Resource Analysis screen, you have the option to enforce two kinds of dependencies: Project and Finish to Start.  Huh?

As near as I can tell, enforcing Project dependencies enforces the top three in the list of dependencies:

1. Dependency
2. Mutual Inclusion
3. Mutual Exclusion

While enforcing Finish to Start enforces Finish to Start dependencies (which I guess is a bit self-evident.) 

Finish to Start Dependencies

Since this dependency gets its own control, let’s examine it a little bit further.  In the following example, I set a Finish to Start dependency on TD Resource Projects 1 and 2. 

This implies that Project 2 must follow Project 1. 

When I enforce the dependency in the above scenario, and select Recalculate, I get the following screen.

I then have to manually modify the Start Dates until the projects fall into alignment – as defined by the Finish to Start dependency.  A quick recalculate yields an acceptable portfolio:

The trick here is that the error message doesn’t necessarily identify specifically which project is causing the calculation issue.  I’ll need to play with this functionality a bit more, but my recommendation for now would be to carefully note all of the dependencies configured in the system in a separate worksheet – and then map that worksheet back to any portfolio potentially impacted by dependencies.

With the holidays fast approaching, and my family travel schedule starting to blend into my work travel schedule, it’s been a bit hard to maintain momentum with my blog posts.  Hence, with all due respect to my loyal readers, I am forgoing the brilliant, creative insights you’re used to, and instead mining some of my older 2007 posts to see what needs updating for the new 2010 environment.

This article is based off of a post I did in November 2009 which I am now updating in 2010. The general gist is to present a model for planning and, perhaps more importantly, documenting the Project Server security structure.  Seeing as I spent a couple of years preaching the gospel of ITIL, I am hesitant to call this a “best practice,” but I would go so far out on a limb to call it a “pretty good practice that seems to work for me, and that other folks have actually used with few objections.”

As usual, I welcome any and all recommendations for improvement.  In fact, I am sure that I will be revisiting these ideas at a later date after I’ve got a couple more 2010 installs under my belt.

Here’s the link to the worksheet that I am using.  Note that this was developed in Excel 2010, and as far as I can tell, data validation and lookup tables get a bit squirrely when moving from Excel 2010 to Excel 2007.

***

MOPS 2010 security can be broken out into two major chunks: functional requirements and configuration specifications:

Functional Security Requirements

Functional MOPS 2010 requirements must be broken out into language that the Business users (and approvers) will understand.  Typically, what that means to me is a simple matrix with the resource roles on the left, and then the key elements of the MOPS/SharePoint interface along the top.

Additional detail and elements can be added as needed, but generally speaking this may be sufficient to provide adequate documentation of the functional requirements in a single, easy to review format.

Configuration Specifications

Configuration specifications require a lot more time and forethought to develop.  Typically, I’ll use a virtual environment to configure, and in the process develop a security workbook in Excel (see example here).  Once I’ve done that, I’ll use the Playbooks tool to transfer the settings over to the target environment.  (Here’s a post I did a while back on Playbooks in 2007, that I’ll also need to update for 2010.)  That’s a formula that has worked pretty well for me in the past.

2010 adds some security details, but doesn’t significantly change the model from 2007.  To me, the most significant security configuration changes reside in managing security delegation, controlling access to the PDP pages, and the BI Center.  I am still working out my best practices for documenting the first two, but have included the BI Center in the revised workbook.

Here’re a couple of key principles in managing and documenting Project Server security..

1) PWA Settings - To create a workbook for future use, either download the example I have posted, or simply go into the PWA Permissions and right click on the permission list.  You should get an “Export to Excel” option which will allow you to pull all of the security settings into a single Excel worksheet.  Make this your first worksheet in the Security Workbook, and configure appropriately.

2) Security Templates - The main challenge with documenting Project Server security is that each Group:Category correlation may have its own security settings.  This quickly becomes very difficult to document.  The easiest way to attack this challenge is to create a series of security templates.  Then, as security is assigned to each Group:Category correlation, the appropriate template can be used to define security.  In essence, that reduces the documentation burden to documenting a single table of all security templates, and then a second table of Group:Category correlations.

Note that I used the following abbreviations for security settings:

For those of you not familiar with these terms, here’s the rundown:

By using only security templates as the basis of your security planning, you can avoid much of the difficulty of documenting the Group:Category security settings.  Typically, I will create a number of security templates, document those in a single worksheet, and then create another worksheet to map the Group:Category correlations, and to identify which security template I use to apply security to that correlation.

Here’s an example:

Since some categories are RBS bounded, it helps me to note which correlations are filtered by the RBS. I can refer back to my Category Settings worksheet to identify those categories configured to filter projects or resources by RBS settings.

3) User Groups - As a general rule, I like to create new groups, and not use any of the default groups – which seems to work better, especially when using the Playbooks tool.  If you’re using the RBS, identify to which level each of the groups needs to be set.  That provides a useful reference for you later on when you go create the new resources and wish to validate that you did it correctly.

4) RBS – If the implementation is using an RBS, I will go ahead and document that in my next worksheet.  Depending on how ambitious I am feeling, when I create the Resource Worksheet, I map it back to this worksheet and create a formulaic check to make sure that each resource, when assigned to a security group, is also assigned to the right RBS level.  This is done by looking up the security group they’re in, and then counting the number of periods in their associated RBS field, to ensure they all match up.  Note that one of the design principles I typically follow is to put each resource into a single security group (if possible).  That may not happen in every implementation, but it makes the administrative burden a lot easier.

5) Categories - Make a list of all of your Security Categories, and include sufficient description.

6) Category Settings - Make a table of all of your Category configurations.

7) Group:Category Mapping – Define the security correlations as discussed in item #2.

8) PWA Security - Typically the default PWA security settings are way to open for most companies.  I like to ratchet them down.  (Note that I haven’t played with this too much in 2010, but am basing this observation off of 2007 where Project Managers by default had permissions to change the theme of the main PWA page for everybody.)

Note for those new to the Project Server game that the SharePoint security model doesn’t necessarily map to specific user groups in Project Server.  What happens is that SharePoint identifies users based on specific Project Server permissions, and then slots them into specific SharePoint security groups.  So, for instance, anyone with Save Project permissions within Project Server for any project will be slotted into the Project Manager group.

SharePoint by default then uses four groups for synchronized Project Server users:

For more information on how the security is mapped, and what specific permissions drive this mapping, see this Technet article.

9) BI Center – Since the BI Center is a separate site from the main PWA site, it is governed by its own security settings.  Configure those appropriately, and consider adding library or item level security.  That will have to be the subject of another post.

The BI Center works much like PWA in the fact that it maps specific Project Server security to SharePoint groups.  More specifically, it maps Project Server Security to PWA SharePoint groups to BI Center SharePoint groups.  For more information on this mapping, please refer to this Technet article.  Note that I do not address SQL permissions in this post, but probably will have to at some point in the future.

10) And that’s about it.  As I develop the security model, I may identify a selection of Administrative Security Procedures which may eventually be required: Phase Gate Review and Baseline Save, Creating New User, Transferring Project Ownership.  Typically, I may drop those into a final worksheet called Administrative Procedures.

So, in the end, at a minimum, to fully capture the configuration of MOPS 07 security settings, I have a total of 8-9 worksheets in a single workbook that should include all required data to recreate the security configuration in a brand new environment:

1. PWA Settings
2. Security Templates
3. Security Groups
4. RBS (if used)
5. Security Categories
6. Security Category Settings
7. Group:Category Correlations
8. PWA Security Settings
9. BI Center Security Settings
10. Administrative Procedures (if required)

Note that this doesn’t include the security configurations on the Project Workspaces, but that may be a topic for another post.

Sample security planning/documentation workbook posted here.  The document is provided “as is” with no guarantees, warranty, etc.