Check out my new blog at

Monday, June 04, 2012

EVMS forProject–Project Synchronization

It is funny having such a big title “Chief Architect” in such a small team with so many top-notch guys.  I think the title is appropriate because I got hired first and then went out and found the kernel of the team that subsequently delivered the product, but ultimately the team is “chief”.
My real title is “Captain Sync”.  I have spent the last 1,000 days working on technology that provides synchronization services between Microsoft Project Server and EVMS forProject.  From the get-go, we wanted to build a system that was more than just a bolt-on to Project Server—we wanted the two systems to prop each other up and provide a complete EV system.  This was not without challenges.
The Project Server Interface (PSI) is the primary interface for companies aiming to build on the Project Server platform.  I have been working with Microsoft Project since the mid ‘90s but it wasn’t until the PSI was introduced with Project Server 2007 that I really got interested in building a framework for creating companion products for Project Server.  The core of that effort is what we call “mpFx”, which has been around since 2007.  The framework  encapsulates the web services used to interoperate with Project Server. In a future post I will describe the technology in depth but here I am going to start with our requirements for EVMS forProject and the options for Project Server synchronization.
(The screenshots and features in this post are part of the announced product but subject to change until general availability)

Project Server Synchronization

First and foremost we needed to be able to integrate schedule information from Project Server into EVMS, including:
  • Activities –Tasks in Microsoft Project are marked with an “element type” via a custom field so that EVMS knows what kind of element to create in our system (or, optionally, the element types can be maintained wholly in EVMS):
    • WBSE – A Work Breakdown Structure Element,  which is essentially the superstructure of the program or project
    • CA – A Control Account  is management control point at which budgets (resource plans) and actual costs are accumulated and compared to earned value for management control purposes. A control account is a natural management point for planning and control since it represents the work assigned to one responsible organizational element (or integrated work team) for a single program Work Breakdown Structure element
    • WP – A Work Package is a natural subdivision of Control Accounts. A Work Package  is simply a task/activity or grouping of work. A WP is the point at which work is planned, progress is measured, and earned value is computed. It can be translated into different terms in different companies and functions. It can be a design job, a tool design package, a build-to-package, a shop order, a part number, a purchase order or any other definable task/activity at whatever level control is normal for program management with in the company
    • SLPP - Summary Level Planning Package is an aggregation of work for far-term efforts, not able to be identified at the control account level, which can be assigned to reporting level Work Breakdown Structure (WBS) elements (and is therefore not “Undistributed Budget”)
    • PP -- A Planning Package is a holding account (within a control account) for budget for future work that is not yet practicable to plan at the work package level. The planning package budget is time-phased in accordance with known schedule requirements (due dates) for resource planning and the plans are refined as detail requirements become clearer and the time to begin work draws nearer. A company may elect to break the work assigned to a control account into smaller groupings of tasks/activities, i.e., multiple planning packages, for internal planning and control reasons
    • Tasks and Milestones – Both are lower level planning constructs that allow the program manager, project manager, or control account manager the option of defining intermediate program structures or temporal points in the schedule signifying an important milestone.  These are not schedule milestones, but milestones upon which earned value may be earned.
  • Resources –  If a resource found in Project Server does not exist in EVMS it can be optionally configured to automatically be created in EVMS.  Resource custom fields may also be configured to be synchronized
  • Resource Assignments – Again optional, resource assignments detected in Project Server that do not exist in EVMS can be automatically created.  Resource assignment custom fields can be synchronized with EVMS as well
  • Project-level custom fields – Custom fields at the project-level can be mapped and optionally synchronized into EVMS
  • Custom field definitions --  New custom fields added to Project Server can be optionally configured to synchronize their definitions into EVMS, as is the case with lookup tables.
When synchronization is initially setup for an EVMS project, the user is provided a series of options to choose from.  First, the user specifies the template that the EVMS project will use and whether or not it will be synchronized with a single Project Server project or multiple projects:
Synchronization templates (sync templates) are configured at the enterprise level and depending on policy and permissions, the user may or may not be able to create or modify a sync template.
In the example above, I have chosen the enterprise default sync template and specified that I intend to sync more than one Project Server project into a single EVMS project, as one would do in  a program.
Next, I specify how the WBS is going to be maintained in the system:
There are three options:
  1. Maintain WBS in EVMS – This means that tasks synchronized from Project Server will land in an “Unassigned” bucket and the project manager will use EVMS forProject Professional to establish the structure manually
  2. Use Microsoft Project structure – The structure of the project in Project Server will be mirrored in EVMS.  I am given the option of using the ID field or a custom field as the “key” field that ties an activity in Project Server to an element in EVMS
  3. Use Project Server custom field or Microsoft Project outline field – This option allows the user to specify either an enterprise custom field backed by a lookup table or a local Microsoft Project lookup field to drive the association between tasks in Project Server and the WBS in EVMS.  Each activity is coded using custom field values, which in turn have a counterpart in EVMS that is located using the values in Microsoft Project
Next, I configure the system to indicate what kind of entity will be created in EVMS based on the information in Project Server
There are five options:
  1. Maintain in EVMS – This simply means that tasks are synced from Project Server and the project manager will manually specify what kind of element type type they are (WBSE, CA, SLPP, WP, PP, TASK, or EVMSTN).
  2. Using a single Project Server custom field – This is the default and indicates to the system that a single Project Server custom field will be used by the project manager to “code” the task to a specific element type
  3. Use Project Server flag fields – Using this options means that a flag fields will be created in Project Server so the project manager can check the element type (IsWBSE, IsCA, etc.)
  4. Use a single Microsoft Project (local) custom field – This option is similar to (2) except that the source of the coding is in a local custom field rather than  an enterprise custom field
  5. Use Microsoft Project (local) flag fields – This is similar to (3) but the source of the flags are local custom fields rather than enterprise custom fields.
You notice below the radio group control that there is a mapping control that allows you to map the value of the custom field to our internal system types for element type designation.   This allows the organization to use different names for the various element types to fit their process and culture.
Next, the user can map Project Server fields, both system and custom, to EVMS fields, again both system and custom.  This technology goes beyond simple mapping of field values.  At the project-level, a project custom field could be set to a value that indicates the earned value set being used in EVMS.  Once that is set, individual task EV method can be set and automatically synced to EVMS:
And you can see here in the field mapping facility that I have mapped the Project Server custom fields “EV Method Set” and “EV Method” to the project and the various EVMS elements:
And here you can see it set at the task-level in Microsoft Project:
After synchronizing, you can see that the EV Method Set has been synchronized from Project Server to EVMS:
And the EV method on the individual elements has also been synced:
Next, the user can specify options regarding resource synchronization.  A single enterprise resource set (EVMS) can be created that is synchronized with the Project Server resource pool.   Each EVMS project that chooses that resource set will have resource information synchronized from Project Server whenever anything changes, including resource custom fields.
Next, the user can map time phased data from Project Server into an EVMS “result unit” such as hours, quantity, or cost:
These values are then available to the user in EVMS forProject Professional and our reporting suite:
Next, the user can configure how status information is brought from Project Server into EVMS:
And finally, the user can configure some advanced options, including an option that tells the system how to roll up task information and not bring detailed tasks over.  This feature will be detailed by itself in a future post:
Okay, I am out of time.  Next post we will look at how synchronization works from a developer perspective (without spilling too many beans of course).


Content on this site is provided "AS IS" with no warranties and confers no rights. Additionally, all content on this site is my own personal opinion and does not represent my employer's view in any way.