A Focus on Resource Management is Value Deferred

A PMO’s job is fundamentally to operate as an investment advisor to the business.  A PMO should recommend to the business how to best structure projects and the project portfolio to reduce risk and enhance value.  All too often however, while the PMO may be able to perform this function for projects that belong to other groups, it tends to have a blind spot when it comes to the PMO’s own improvement initiatives. (see Chris Argyris’ Overcoming Organizational Defences for more on why this may be the case.)

Nowhere is this more evident than in the resource management discussion.  The PMO is usually in a perfect place within the organization to provide resource analytics.  The PMO has visibility into all projects in execution.  The PMO has some control over each of the PMs managing these projects.  The PMO typically owns some form of a PM Information System (PMIS) that has functionality designed to capture all of this data and regurgitate it in the form of colorful, clickable reports.

Hence, once the PMO realizes that one of the fundamental issues impacting project execution is resource contention, it begins a review of enterprise project management systems designed to support data collection and presentation.  This endeavor is typically phrased in the context of mapping resource demand (the project pipeline) and resource capacity (the resource pool).   Somewhere in this discussion, the consultant (me) will invariably ask, “Why?  What’s the goal of collecting all of this data?”

The answer is almost always along the lines of, “We need to show the impact of adding new projects on our resource pool.  We need to provide the metrics to justify asking for additional head count to address the sheer number of projects in the pipeline.”

Let’s take a look at the implications of this statement.  The PMO is basically saying that the organization is allowing too many projects into the pipeline – or that we don’t have the resources to support this level of project execution, which is essentially the same thing.

The roadmap then for a “traditional” resource management deployment of an EPM system is to implement all sorts of metrics to capture the current resource load, to capture where resources are spending their time, and create all sorts of reporting functionality.  Fast forward 6-12 months down the road and assuming we didn’t fail in the all important user adoption, we have beautiful reports; we have resources all captured in a fantastic online database.  What do we do with the information?

We take it back to the business and present them with prioritization decisions.  This is the point where we might realize that the business is not willing to change how projects are selected – that the business is not willing to converge on a single prioritization scheme.  Remember, the entire resource management endeavor was predicated on the idea that eventually we would get to that point where all of the data could shape behavior.

There’s a lot of risk inherent in this approach:

  1. The risk that user adoption will not happen and resource data will be flawed.  This is pretty much guaranteed in the majority of implementations of a certain size.
  2. The risk that once we collect the data, the business will not be interested in coming together to find new ways to select projects.

Wouldn’t it have made sense to have overcome this hurdle first – then go through the effort of collecting all of the resource data?  Wouldn’t it have made sense to assess organizational willingness to even touch this issue – then focus on what the PMO could actually do to generate value?

An Alternate Approach

If we start the improvement process with project selection and attaching estimates to new projects, we mitigate these risks:

  1. By focusing only on the projects in the approval pipeline, we greatly reduce the number of moving parts associated with resource management in the enterprise.  We reduce the complexity and enhance the opportunity to drive user adoption within the constituency that counts.
  2. We cut to the chase.  We identify that the organization is willing to address the fundamental problem – not the availability of resources, but the inability to prioritize the projects.  We put the prioritization mechanism in place, then build the reports and data structures to support it.  This is important because it lends credibility to the resource management effort.  We’re not simply collecting data to collect data, a common gripe.  We’re collecting data to support a clear strategy.
  3. We begin generating value immediately – and don’t invest in 12 months of effort with an uncertain delayed return.

At the end of the day, resource management roadmaps always end up at the feet of the business and the prioritization process.  Why take on all of the risk and investment before realizing we’ll fail there?  Instead start with the single point of failure, address that, and then move on to the complicated stuff.  Fundamentally, that reduces the risk that the organization will invest heavily in a resource management process – only to kick it to the curb when it comes to the actual behavioral change that matters.

Advertisements
A Focus on Resource Management is Value Deferred

TFS and Project Online Integration

Pulling the development and the project management worlds together into a single view has long been regarded as the killer feature of the Microsoft IT work management world.  For evidence of this, check out this link to the 2007 Project Conference keynote where Steve Ballmer himself was on stage helping demo the new (at the time) connector with Project Server.

Needless to say, Microsoft has made great strides since 2007.  The version of the connector released for 2010, well, just worked.  It was a bit of an effort to install (usually due to security configurations), but once you got it working, it could plug along happily.  That is still the case with Project Server 2013 on-premises…..but once you start talking about the cloud based world, it becomes a bit murky.

At the time of this writing, Microsoft offers Project Online, a hosted Project Server service and  Visual Studio Online, a hosted Team Foundation service.  This means that we regularly run into customers that have Project Server, Visual Studio, or both online.  The question inevitably comes up about whether any of the online options can be integrated with each other – or with on-premises installations.

This post is intended to run through the various options and provide recommendations:

Out of the Box Server – Server Integration

Currently, the downloadable integration pack only works to link Project Server on-premises with TFS on-premises.  Note this pack is downloadable from MSDN Ultimate. I’m pretty sure it’s the same pack for both Project Server 2010 and 2013, but let me know if you find out otherwise.

This option is definitely the recommended option if both TFS and Project Server are on premises.

SNAGHTML622e308

Project Desktop Integration with Team Explorer

This works reasonably well, although it assumes your project managers are scheduling within the Microsoft Project desktop application and not using the Web based scheduling feature.  Essentially, you download the free Team Explorer add in, which then adds a tab to your Project installation.

image

When updating tasks in Project, click the option to Publish, and the tasks appear in your TFS (online or on-premises) instance.

image

I was able to create a Visual Studio Online tenant and link it to my project in a couple minutes.  Admittedly, this is not a seamless integration:

  • It requires use of desktop scheduling (which – to me – is not a major issue.  I live in the desktop scheduling tool).
  • It requires a couple extra steps to push the data from the desktop to TFS – well actually, one button push.
  • It requires an extra step to download the data from TFS into the project schedule.

Also in the past, I’ve heard of issues where TFS will overwrite key data in the project schedule, like durations, etc.  In testing out the Team Explorer add in, I didn’t experience these issues, but feel free to report back in the comments below.

Until there is direct out of the box integration with cloud based implementations, I’d definitely recommend going this route for connecting Project Online with Visual Studio Online, Project on-premises with Visual Studio Online, and Visual Studio on-premises with Project Online.

Custom Development with CSOM to Project Online

For those of you running TFS on-premises and Project Online – which is the most common scenario we see these days, there is always the option of writing custom code to push or pull data from Project Online into TFS.  To assess whether or not the Project Online Client Server Object Model will support custom scenarios, I would encourage you to look at this link:

http://msdn.microsoft.com/en-us/library/office/jj163082(v=office.15).aspx

…then take a look at this link that Ionut wrote about remote event handlers for Project Online:

http://www.umtsoftware.com/blog/2013/08/01/project-server-2013-remote-event-handlers/

Visual Studio Online is also extensible.  See the link below for more information on integration with other services:

http://www.visualstudio.com/get-started/integrating-with-service-hooks-vs

I would stress that the effort to develop your own integration package probably outweighs the incremental benefits that may be earned over using the desktop integration method.  Customization scenarios typically only work when there is a significant need for automation and your processes are very well defined.

3rd Party Tools

Last but not least, take a look at third party tools that may be out there to assist you in the integration.  More and more offerings are coming out each day, and stay tuned on the Project Server or Visual Studio application store to see if anything has popped up to support this scenario.

As more and more organizations move to the cloud, it will be refreshing to see Microsoft add extensibility options to allow improved integration and customization.  That’s definitely the direction I see happening with the cloud based offerings – and it will only drive the development of ever more applications that fill in the current gaps in functionality.

For some additional blog posts about connecting integrating Project Server and TFS….

TFS and Project Online Integration

Unpacking Project Schedule Concepts

As many PMP trainers will tell you, one of the advantages of enterprise wide PMP certification is that all of the PMs within the organization start using the same terminology.  Everyone suddenly is able to speak in the same language.  That’s a significant part of what we do when we work with clients.  We often need to unpack the terminology that’s in use within the organization – and often we need to evaluate the actual practices being performed and map them to an EPM framework.

In this vein, it’s always impressive how much organizations attempt to pack into a project schedule.  Often times, there are very disparate concepts that get thrown into a project schedule – which don’t make too much sense, and may present an obstacle to the organization actually managing projects effectively.

Phases and Lifecycles

Take the example of the word “phase.”  The PMBOK defines a phase as a collection of tasks, usually culminating in the creation of a major deliverable. In the software world though, and I’m talking specifically about the world of Microsoft Project Server and SharePoint workflow, a phase implies that the project (or entity) is in a specific state, i.e. “Pending Authorization, Active, On Hold, Completed.”  In effect, a lifecycle phase is a label that we apply to the project that is then inherited by all of the various entities that comprise a project: resource work, allocated cost.

In this way, we have cost that is associated with projects that are still pending approval, and we have cost that has been allocated to projects that are currently active.  The phase label presents a convenient way of classifying this cost.  If we use this mechanism, by default, a project may only exist in a single phase.  For a project to exist in multiple phases at the same time typically requires that we model the project differently, i.e. as a program – where we have a program lifecycle that is comprised of multiple projects – and each project is in a distinct phase of the project lifecycle.  In fact, I typically use that as a test to see if we’ve defined the phases correctly.  If it’s possible to be in multiple phases at the same time, we didn’t get the lifecycle definitions correct.

Schedules

So that’s how the term “phase” is now used in the world of PMIS system design.  Now let’s talk “schedule.”  On this, I tend to go with the PMI definitions, which state that the schedule is a static representation of a schedule model – with a schedule model being the accumulated logic and information related to a project combined to provide a predictive forecast of time, cost and effort.  Each week, you input the latest developments into the model and generate a revised schedule.

This is where things may get confusing.  Schedules often include a logical grouping of tasks – often called a phase.  Note, however, that this is generally not the recommended way to structure a project schedule, as the general consensus in the scheduling world (at least within the circles I run in) is that schedules should tie directly back to the WBS, and a WBS should always be product oriented, not phase oriented.

Hence while a schedule model may be structured to map to a specific phase structure, that’s not necessarily required or even desirable.  In fact, one could argue that a phase structure supersedes the actual schedule of a project – as it’s very rare to actually incorporate the preauthorization, business case development steps in the schedule – which doesn’t typically get developed until a bit later in the lifecycle.  The same applies for post-project benefits analysis – which needs to occur, but is rarely incorporated into a project schedule.

On the other hand, it’s quite common to leverage the schedule model to forecast when a project will transition from one phase to another, i.e. to include milestones within the schedule that provide some prediction of when the project will progress to the next phase.

So we now have two terms which are often conflated:

  1. Phases – a specific definition of the status that a project is in within the project lifecycle – that definition being inherited downward to apply to all of the relevant component of the schedule model.
  2. Schedule Model – a simplified representation of the project schedule used to forecast time, cost and effort.

Checklists

And the last item that often gets confused with these two, surprisingly enough, a checklist.   What is a checklist?  It’s a collection of tasks or conditions that must be met for a specific item to be declared completed.  Sound familiar?  Sounds kind of like a phase, i.e. we have a collection of things that must be completed before the project may move from preauthorized to authorized. Similarly, it sounds a lot like a schedule, which contains a series of tasks that must be completed for the project to be completed.

The difference is that a checklist defines either conditions that must be met – or tasks that must be completed, but those tasks are so small and granular that they are not worth including in the schedule model.  We simply summarize the checklist process as a single task within the schedule, and capture the verification procedures that drive the checklist outside of the schedule.  At least, that’s how it should work – too often we see clients incorporate the checklist into the schedule model and try to model overly granular tasks in the schedule.

Once we’ve unpacked these terms, we can focus on improving each one.  Until that is done however, what we have is an unwieldy procedural mess.

Unpacking Project Schedule Concepts