Does Microsoft Project Online Integrate with [Blank]? (Part 1)

This question comes up increasingly in our discussions with clients:  “Does Microsoft Project Online integrate with [fill in the blank with whatever Agile tool your organization happens to be using….TFS, Jira, Rally, VersionOne, Excel, etc.]?”  The answer is invariably “Yes, and….”

Given that it came up again this week, I figured it was probably worth a blog post to review the options available.  First, let’s look at the technical options for integration in this post.  Once we get that out of the way, let’s look at specific scenarios that we see come up most often.  (Yes, I realize I should be doing it the other way around, but to be honest many organizations haven’t identified the specific scenarios they’re trying to support yet, and are really just looking to keep their future options open when standardizing on an overall PPM platform.)

For prior postings on how to integrate Agile processes with an overall portfolio management mindset, please take a look at some of our old blog posts here.  Note these are a bit more process oriented.  The blog below is designed to be a bit more tactical in nature.

Project Online

Rest assured, Project Online has all of the “hooks” required for integration with your tool of choice in the CSOM interface.  (For more on CSOM, click here).  Yes, you do probably require a developer to create these links to your tool – but most partners (such as, ahem, ahem, ourselves) have plenty of those on staff.  In fact, as we like to say, with our UMT360 add in – which integrates with Project Online, we are responsible for the most complex integrations performed to date on the Microsoft Project Online platform.

image

One caveat we would typically throw out is that the easiest way to prototype an integration and validate the processes underlying it is through rapid development of VBA macros within the Microsoft Project desktop tool.  Once the process has been vetted, and the underlying fields defined, that may then be coded up into the CSOM interface.  (See here if you want to tie an event handler into the mix, i.e. to trigger an integration action based on an activity in Project Online).

Project Online not only allows folks to push data into it, but obviously it also supports extracting the data.  To get data that may need to be pushed into another tool – or simply integrated into a common report (see below), the OData interface is generally sufficient.  This functions like a reporting database that may be accessed from the cloud – or via reporting tools that your organization may happen to have lying around.

The OData store may also be replicated on premises in the form of a standard SQL database.  This allows for slightly more ease of use in terms of keeping your Project Online data in sync with your Agile tool of choice.

Agile Tool of Choice

As for your Agile tool of choice?  Well, that’s a different question.  If you’re using TFS, there’re definitely hooks to push data into the system.  If you’re using another tool, we can probably assume there is an interface by which data may be imported – either manually or through a coded interface.  I can’t really speak to that – other than to say that it has never been an issue in our experience to push data into another Agile tool – or even any other kind of ancillary industry specific scheduling tool (WellView, RigView, etc.).

image

At the same time, the question then becomes….what data?  That’s something we’ll take a look at in the next post.

Finally, in our experience, any Agile tool worth its salt will have the required data available in an easy to use format, whether it be cloud based, an on-premises database, or some other data extract method.  This data may then be consumed and pushed back into Project Online via the CSOM interface or Microsoft Project desktop through good ol’ VBA macros.

Integrated Reporting Platforms

Most of the time, when we hear of a need for integration, after we do some discovery, we realize the need is really for shared reporting.  “I need to have one report that shows the overall project schedule as well as sprint progress,” the client says.  This greatly simplifies things – because at this point, we really don’t need to integrate.  We can simply extract data from the Agile tool, extract data from Project Online, and then integrate them into a single data model.

image

This is where Microsoft’s Power BI shines as a cloud based reporting tool.  It can easily pull multiple data sources from both the cloud and on-premises repositories to generate a seamless reporting interface.

And that’s it for the overview of the integration options.  In the next post, I’ll talk about why you might want to integrate and we’ll examine specific scenarios that might require integration.

Does Microsoft Project Online Integrate with [Blank]? (Part 1)

Balancing Speed and Efficiency: Effectively Segmenting the Portfolio (Part 1)

(Catching up on some thoughts after getting through a couple of recent client interactions, conferences, and books.)  In the portfolio management space, we seem to live on a continuum.

image

On one side of the continuum, we have this vision of the perfectly optimized portfolio.  In this vision, every project has a business case and can be prioritized against every other project – perhaps in the form of an evolving backlog that gets released into execution on a quarterly basis.

On the other side of the continuum, each stakeholder group is allowed to manage its own funding, i.e. the siloed funding approach.  Prioritization occurs within the silo, and little if any lip service is paid to how the project for one group should align with the project in another group.

So the question comes up….when does it make sense to segment and when does it make sense to share?  What are the hybrid scenarios where it makes sense to have both models?  This blog post is my initial attempt to answer that question.

Before we get too far into that discussion, however, let’s take a look at this diagram we came up with recently for an IT PMO.  Essentially, we analyzed the work in a “standard” IT department and segmented it out into three proposed portfolios.  Note that this schematic probably applies outside of IT as well, i.e. oilfield management, facility management, etc.

image

Per our analysis, we had three main portfolios.  In this case, we use the word portfolio to indicate a specific governance process, i.e. a process to capture the request, approve it, pass it into execution, and then manage the benefits realization – the request to fulfillment value chain.

Portfolio #1: Mandatory – these projects are required due to regulatory reasons.  Hence they must be performed.  I am still working through the funding model for regulatory projects, but let’s simply assume these projects are approved from the initial definition stage – and then funded either from a shared funding pool, from a specific business unit, or in some sort of cost allocation against each of the relevant BUs.  (Note that in our experience, the definition of “mandatory” varies significantly from organization to organization.)

Portfolio #2: Discretionary – these projects are what typically fall into the model of shared prioritization.  These are projects that don’t necessarily have to be performed, but do have a valid business case that ties back to the goals of the organization.  This is the portfolio I will primarily be focusing on in the next post, i.e. when and how to break this into separate funding streams.

Portfolio #3: Baseline – Baseline work in this sense is defined as the work required to maintain the asset portfolio.  In IT, we would define the asset portfolio as a series of capabilities or applications.  In energy, we might define an asset portfolio as a series of pipelines, wells and facilities.  Essentially, the concept is that for every asset, I will have performance metrics, and a set of projects required for maintenance and enhancements.  For an application, I will have a project to build it, enhance it every year, and then upgrade or retire it.

The importance of classifying something within the baseline portfolio is that this portfolio typically plays the part of utility services, i.e. providing shared services to support multiple business units.  In this case, we don’t want to have to perform a detailed strategic business case on every project that comes through the pipeline – as typically the projects are too small and too focused on a specific asset to justify spending the time of tying it back to the overall organizational goals.  Instead, we rationalize the portfolio, and identify the capabilities that are shared across multiple business units.  Then we identify the assets that support the capabilities, prioritize the assets, and defer the project approval process to the asset management teams – what in ITIL parlance would be the Application Owner and Manager.

So that’s the overall framework we are going to start with.  The next question (and the next post) is how do we determine when to treat a portfolio as a single entity across the enterprise and when do we decide to break it out and make prioritization (and funding) decisions by the BU?

Balancing Speed and Efficiency: Effectively Segmenting the Portfolio (Part 1)

5 Steps to Application Portfolio Management [Webinar]

Ben Chamberlain will be presenting on one of the hottest topics we see in the IT portfolio management world these days…..Application Portfolio Management.

Ad-hoc, event-driven approaches to Application Portfolio Management (APM) simply aren’t delivering results. Important application data and metrics simply can’t be effectively maintained using spreadsheets and homegrown tools. This makes it a challenge to sustain a continuous APM process that supports annual IT planning and budgeting.

Tune into this webinar to see how APM can help you:

  1. Consolidate applications in one inventory
  2. Derive key assessment metrics (Value, Risk,
    Architectural Fit etc.)
  3. Calculate  Total Cost of Ownership
  4. Collaborate to record lifecycle decisions
  5. Build and execute multi-year transformation roadmaps

For more details, or to register…..

5 Steps to Application Portfolio Management [Webinar]

Strategic Planning as C-Suite Taylorism

I’ve been reading Henry Mintzberg’s The Rise and Fall of Strategic Planning of late.  It’s been a bit of a slog, primarily because I’ve been trying to read it on flights (which puts me to sleep) or at my daughter’s roller derby practice (which causes the other parents to mock me mercilessly*).

There’s an interesting thought presented very early in the book that has caused me to reflect a fair bit as I’ve been delivering presentations on strategic planning over the last couple of weeks.  The basic concept is that strategic planning is really an example of Taylorism as applied to the C-Suite.

A quick sojourn into the world of Taylorism…..otherwise known as Scientific Management: this is the concept that all work can be broken down into a series of manual steps.  This work is performed by the workers at the rubber-meets-the-road tier of the organization.  The workers are then watched by the supervisors, whose job it is to ensure the workers follow the agreed upon procedures.  The supervisors then implement the procedures defined by the manager class who by dint of their intellect and college education are qualified to develop the procedures that trickle down.  The entire thing these days and in some sectors smacks somewhat of the Eloi – Morlock dynamic, but in all fairness brings a fascinating perspective to the operating theories underpinning many modern organizations.  In fact, I might propose that most organizations I’ve worked with ostensibly reject the concept of Taylorism while simultaneously building the structure to support it.

Anyways, in a net-centric, information worker type organization, an alternative model has arisen – that of the empowered worker understanding the primary problem to be solved and then working independently or as part of the self directed group to push the goals of the organization.  (See posts here and here…..and this post on Yammer’s role in enterprise project management.)

The  book points out though that attempts to processize the strategic planning, well, process, have repeated the same structure, but this time pushed it upwards into the C-Suite and removed much of the art of strategic planning by replacing it with a mechanism to review goals from last year, adjust and issue a new plan for this year.

Attempts to implement strategic planning processes have removed some of the artistry of planning, and replaced it with a rote set of processes that must be followed at a specific cadence.  We see that with the emerging prominence of two distinct project portfolios:

Reactive Portfolio Proactive Portfolio
  1. Collect the list of requests for the next annual plan.
  2. Prioritize these requests.
  3. Perform constrained optimization.
  4. Release to execution.
  1. Define the long term goals and investment areas for the organization.
  2. Decompose the goals to develop a project portfolio leveraging the principles of enterprise architecture.
  3. Prioritize the project portfolio.
  4. Perform constrained optimization.
  5. Release to execution.

In the first portfolio, the reactive one, we simply have to collect all of the requests from the organization, run them through an analytical hierarchy that was defined per some other set of formal processes, and we have a portfolio.  In the second portfolio, the proactive one, we swap out the sensing mechanism of order taking with one that is a bit more proactive, i.e. mapping fundamental strategic change to the scope of the projects in the annual plan.  Regardless of which portfolio you support, the general premise however is that if we follow these two approaches to the letter, we will have success in our strategic planning.

So the question now becomes, if Taylorism has been widely rejected in many information worker organizations, and if strategic planning is merely Taylorism writ large, then what would a rejection of Taylorist strategic planning processes look like?  Well, it might look a lot like decentralized program or asset based planning.  Specifically, funds would be allocated flexibly to the asset based off a prioritization matrix that identifies the importance of the asset and how well the asset is meeting its target performance.  (See this post on the program as a benefits management framework.)

Each asset would then be owned by a specific individual, a program manager who would be responsible for allocating funds to best guarantee the asset meets the needs of the organization.  The prerequisite for this to work?  A clear definition of where the organization would like to go – and how each asset supports that definition.  Note how this structure meets a clear need, that of transferring ownership of the project and the defined initiatives to the teams responsible for doing the work.

That is what a strategic planning function would look like if we designed it in a manner consistent with the principles of modern information worker process design.

*****

*…despite my protestations that reading a book like that at roller derby practice reflects the duality of man…you know, the Jungian thing).

Strategic Planning as C-Suite Taylorism

[Utilities] PMO Strategies & Capital Investment Governance Webinar

Excited to announce this upcoming utilities-focused webinar on March 12 (2:00-3:00 EST) with UMT and Frank LaRocca, Director of Business Improvement Services for ConEdison.

  • Learn from ConEd’s experiences and insights on building governance and an enterprise PMO for multi-billion dollar capital investment portfolios.
  • Hear about the latest innovations in agile operating models that deliver and exceed historical performance across electric, gas and steam operations.

For more information, to register and/or to see the case study, please click here.

[Utilities] PMO Strategies & Capital Investment Governance Webinar

Applying Enterprise Architecture to an EPMO Process Framework

Thinking a bit more about last week’s post on scoping the EPMO.  In that post, I asserted that there are certain “stock” capabilities that an organization requires to execute projects.  Some of those capabilities should be best owned by the EPMO, some by the various PMOs supported by the EPMO, and some jointly owned by both.

image

One thing I left out of that post was a suggested framework for how to determine where a specific capability might actually fall, i.e. should it be considered a centralized capability or a decentralized capability?  As I was thinking about this, I realized that the framework proposed by Jeanne Ross, Peter Weill & David Robertson in their page turning EA book, Enterprise Architecture as Strategy, could be brought to bear on the discussion.

As I’ve mentioned before on this blog, they suggest reviewing architecture from the perspective of unified process and/or data.  Every capability should be reviewed by asking two simple questions:

  1. Do we need to centralize and standardize the process that each of the PMOs and EPMO follow?
  2. Do we need to centralize the data that each of the PMOs and EPMO generate and/or use?

Simply put, you can take each of the capabilities in the above chart and map it on the following 2 X 2:

image

After going through that exercise, that should give you a decent foundation upon which to allocate ownership of the various capabilities inherent in a PM system.

Applying Enterprise Architecture to an EPMO Process Framework

Deliverable Dashboards with SharePoint Workflow

A common request in project management is to be able to create a dashboard for each project that shows the status of specific defined deliverables that must be created.  For example, the project manager must be able to see that a SOW or proposal has been posted to the site.  The project manager must also post a status report to the project each week – or get flagged as being out of compliance.

image

In prior versions of SharePoint, this was typically performed through the use of custom code.  For this post, I decided to sit down and see if it could be done with a little SharePoint Designer workflow.  Turns out it wasn’t hard at all.

To create this solution, we’ll need:

  1. A custom SharePoint list for the dashboard
  2. A document library
  3. A couple custom content types
  4. One list workflow on the document library
  5. One site workflow on the dashboard list

Dashboard List

This is a simple list with a couple of fields:

image

Note that Status is a drop down with Red, Yellow, and Green as the available options.  (Red is the default).

I modified this list to add conditional formatting using SharePoint Designer 2010 as in this blog post.  It looks like SharePoint conditional formatting is being deprecated in 2013, so this is a bit of a hack where I had to install SPD2010 to get this to work.  I’d trust smarter folks than I to figure out a better way of sprucing up the dashboard – i.e. adding icons or leveraging some other method to create the conditional formatting.  For today’s post, this will do the job.

image

Add list items to your list for each deliverable you will be tracking.  I used the same names as the content type in the document library to facilitate the workflow finding the correct item to update.

Document Library

For the document library, I added a couple of content types and an Approved field.

image

Dashboard Update Workflow

I then created a simple workflow on the document library.  This is set to trigger whenever a document is created or modified.

image

Adding some additional detail to the picture above:

  1. Line 1 picks up the UID (as a string) of the dashboard item corresponding to the content type of the document in the document library.  This allows some minimal error handling by skipping the items that will throw an error if it can’t find a dashboard entry corresponding to the document content type.
  2. Line 3 establishes the URL of the document in order to populate that in the document dashboard – so the user can click directly from the dashboard to the document.
  3. The if….then clauses flag the dashboard item as green or yellow depending on if the document has actually been approved.

Here’s a shot of the step that updates the dashboard item.  (This is for approved documents.  The other one will flag the item as yellow.)  Note I’m copying the Last Modified date into the dashboard Updated field.

image

That will update our dashboard list per our requirements.  One more quick item, and we’re good.

Status Report Monitoring Workflow

For the final step, I want to add a bit of logic to flag the status update column yellow if no status update has been posted in the last week.  To do this, I’ll create a site workflow that will wake up every 24 hours, check to see if a new status update has been posted, and flag the item as yellow if it’s been a week since the last update.

That workflow looks like this (if anyone can suggest a better way to present SPD workflow in a blog post that’s not too tedious, let me know.)

image

More detail:

  1. Line 1 is pickup up the GUID for the status report item in the dashboard list.
  2. I’m basically picking up the Updated date, adding 7 days, then comparing it to today’s date to determine if the item must be shifted from green to yellow.

And there you have it…one compliance dashboard.  If anyone has suggestions on how to clean up the look and feel of the dashboard itself, feel free to post in the comments section.

image

image

Deliverable Dashboards with SharePoint Workflow