Calculating Demand with the New Resource Engagements Feature

Looks like when I wrote that post on how to incorporate Resource Engagements into the portfolio analysis module of Project Online / Project Server 2016, I left out one critical step.

For resource engagements to show up in the calculated portfolio demand, you’ll need to open the Project Information dialog box within Microsoft Project Professional and toggle the calculation settings – then republish the project.

image

 

Note that the option only appears after the project has been saved to Project Server.

Advertisements
Calculating Demand with the New Resource Engagements Feature

The Cloud Means Never Being on the Cusp Again

The cusp of a new platform is a dangerous place to be in.  In my world, it usually it means that we’re looking to upgrade or replace our EPM platform and therefore are scaling down our investment in it until we can make the great leap forward.  The problem is, of course, that our processes don’t stop evolving.  They keep changing and moving.

Once an organization determines it’s on the cusp, it’s more likely to have a process/tool mismatch, where the two get out of synch.  That then results in a drop of user adoption, a lack of process controls, and a gradual descent into the same chaos the organization started from.  Being on the cusp hurts organizational performance.

Enter the cloud.  Being in the cloud means that the organization will never really have to worry about big bang upgrades again.  Instead, the focus can move from the technical to ensuring the evolving processes are supported by the tools.  This tends to change the long term support discussion.  Instead of planning every several years to reset the tools to match the processes, organizations in the cloud move to a more constant, steady stream of tool changes that ensure compliance.

This, I suspect, will be one of the bigger changes of moving to the cloud….the change in thinking towards IT that comes from not having that periodic opportunity to remove the old and start with the new, that opportunity to get rid of the old architecture and move towards a brand new one.

The Cloud Means Never Being on the Cusp Again

Architecting a PMIS for the Cloud

Let’s face it.  On premises system architectures have long been an enabler for both lazy and amateur enterprise architects.  Need to move some data around?  Simply add a couple of fields to store it.  Need to add some integration just so we can see all of the data in a single place?  Build some batch jobs to push data hither and yon – and replicate it in multiple places just to make it easy to get at.

Nowhere is this more evident than in a Project Management Information System (PMIS) that has grown organically to the needs of the enterprise.  Invariably, a PMIS has grown as a collection of disparate systems and silos, all oriented to the needs of a specific functional group that may be involved in the execution of a project.

image

The integration eventually evolves into a veritable spaghetti diagram of lines moving data from one system to another.  Often, the data schema for the scheduling tool is expanded or repurposed to collect all of the data into a single, convenient data repository.  Generally speaking, this sort of works for many organizations.  They still manage to get their work done, albeit with a fair bit of grumbling around project managers having to access multiple tools to get their jobs done.

The main challenge with this tool architecture is that it doesn’t support a nimble process framework.  As PM processes mature (pro-tip: they will) or adopt to the changing organization, the organization needs to maintain a strict focus on a capabilities infrastructure.  As the capabilities develop in maturity, the underlying tools must also adopt, and this is where the traditional organic PMIS fails…..to a large extent due to the technical debt incurred in the evolution of the overall system.

Traditionally, with on-premises systems, this tendency towards entropy is addressed every couple of years in the form of an upgrade.  The vendor releases new versions of the software, and as part of the inevitable upgrade process, the organization performs a subbotnik to reassess and simplify the overall system.  This cycle naturally prevents the overall system from getting too complex.

Today’s subbotnik is not your father’s subbotnik however.  Today, most of the discussions we have around upgrades involve a consideration of moving to the cloud.  Often times, this is driven by the desire to take advantage of the cost savings that enterprise cloud offerings now bring to the table.  Twice in a week, I’ve been in conversations with clients about how they could save significant infrastructure overhead costs through moving to the cloud – but have been prevented from doing so by the architecture of their existing PMIS.  This means that they’ve been stuck with expensive on-premises environments with feature sets that grow increasingly outdated with each day.

Furthermore, additional care must be taken when moving to the cloud as we will lose that convenient safety valve of reassessing the entire thing from the ground up as part of an upgrade within the next several years.  Whatever we design today, we will have to live with tomorrow – and the day after tomorrow.

Over the course of multiple discussions, the architecture I see evolving around the PMIS looks a lot like this:

image

Instead of pulling data backwards and forwards, we are consolidating it.  The data is either consolidated in real time with any number of reporting tools such as Microsoft Excel, PowerBI, Tableau or Spotfire…..or it’s being pulled into a data warehouse such as SQL or HANA using an ETL tool.  Doing so greatly reduces the complexity of the overall system and allows each part to feed data in such a way that the company can rapidly mature in a specific capability as needed.

Hence, for those organizations with a significant existing investment in on-premises PMIS and the associated integration that this usually entails, a cloud discussion almost always needs to start from the process discussion.  What is your process?  How do the tools you currently have enable this process?  How do the tools we currently have block the process?  Does the process truly support the project management needs of the enterprise?  It’s only after having this discussion, that a new system architecture may be designed…..one which enables the nimble enterprise.

Here, we run into some of the typical challenges of a cloud discussion.  Typically, the cloud agenda is part of the IT agenda – as a means of reducing operational costs associated with maintaining rooms full of big iron.  The processes we are supporting are owned almost always by a PMO or PMOs.  To have this discussion effectively, i.e. of how to move to the cloud, the PMOs must be engaged by IT to reassess process and ensure that the results can be moved to the cloud effectively and efficiently.

Prior postings on architecting a PMIS (here and here)…..and a couple of posts on mapping EPM tools to process architecture (here and here)

Architecting a PMIS for the Cloud

Portfolio Analysis in Project Online: Engagements Edition

I started writing about the mechanics of the portfolio analysis module of Microsoft Project Server back in 2010-2011 with Microsoft Project Server 2010.  That resulted in this somewhat comprehensive (at the time) white paper that’s probably due for a couple of minor updates.

Over the last several years, I’ve made a couple of attempts to correct some of the errata and omissions in the paper as well as bring it into line with Project Server 2013 and the Project Online cloud based release.  That has resulted in the following posts (organized in chronological order):

  1. Original white paper (See errata in the comments)
  2. Generic Resources and Portfolio Analysis
  3. Resource Plans and Portfolio Analysis (Note: As of writing, Resource Plans are effectively retired in the Online version of the product)
  4. Prioritization with Custom Fields

And now this.  In this episode, I want to get you caught up on how Resource Engagements impact the resource analysis functionality in the Portfolio Analysis module.  Turns out, this is quite easy.  You’ll note in tenants with the features activated, you will now see this option in the setup screen:

image

So as you can see, you have the option of selecting whether resource engagements decrement from available capacity.  One important thing to note is that if I have assignments that don’t map to an approved engagement – those assignments may not be part of the portfolio analysis if the second option is not selected.

Hence, if you want portfolio analysis to work the way it “used to” work, you would probably want to select the second option, i.e. don’t require resource managers to approve work before it shows up in the resource analysis calculations.

Portfolio Analysis in Project Online: Engagements Edition

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

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, we looked at the technical options for integration in the last post.  Now that we have that out of the way, let’s look at specific scenarios that we see come up most often in this post.  (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.

Scenario 1: Portfolio Management

Portfolio management is probably the biggest aspect of using Project Online and an Agile tool.  The project is proposed and selected within the boundaries of the Microsoft platform.  Once the project has been chartered, a high level schedule is generated within Project Online, and the development efforts are pushed to the Agile tool.

image

In this example, the integration scenario is that once a project has been chartered, the same project must be created within the Agile tool (presumably with the help of a project identification number).  This allows us to ensure that all work has been properly authorized and prioritized against other work.

The reality in this case is that the Agile work is bookended by the portfolio management processes of the organization as well as the high level project execution activities…the user adoption, training, initial planning, etc.

Scenario 2: Resource Modeling

In this scenario, which is probably the most common scenario, the organization is seeking to develop a comprehensive view of resource capacity and demand.  Projects are chartered and work is managed within the framework of the Agile tool.  How does the organization gain an overall view of resource commitments?

In theory, this is quite simple.  To perform true Agile, your development staff is dedicated to the project, i.e. no more of that nasty task switching that causes delays in a traditional waterfall model.  Hence, you follow the same process as above, and when it comes time to allocate resources, you simply calculate the duration from the beginning of the first sprint to the end of the last sprint, and assign your development staff full time.

The details are then managed in your Agile tool of choice, and “integration” simply consists of comparing the finish date for the last sprint with the finish date estimated in the schedule tool.  There may be some reporting requirements, but these are easily handled by aggregating the data from the two systems into the same data model within Power BI.

Scenario 3: Task Scheduling

The final scenario usually involves scheduling of the specific sprints in the Agile tool.  As Microsoft Project is the preferred scheduling engine for many organizations, the overall schedule is modeled in the Project Online tool, and then specific dates are pushed into the Agile tool.

image

This gets a bit more vague, as the trick here is to identify specifically which data is being pushed into the Agile tool.  If really we’re managing the development activities in that tool, then the only dates I really need are the dates when I kick off my first sprint…..and when my final sprint completes.  Potentially, I may use this to schedule around release windows, i.e. to model release windows and blackout dates in my schedule, and then use that to assess impact on the sprint schedules.

Those are my scenarios.  Did I miss any?  If so, let me know in the comments below.

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

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)

Reporting in Project Online…..or…..How to Make a Technical Presentation Fun and Interesting

Apparently, it takes lots of salty Danish licorice.  Take a look at this presentation from Microsoft Ignite last week where Allan Rocha and Mike McLean do all the heavy lifting, and I sit in the back and make snide comments.

http://channel9.msdn.com/Events/Ignite/2015/BRK3137

Maybe that’s the path forward for technical presentations.  One person to present, and the other person to make fun of the presenter.  Not sure all of the jokes worked (for instance, the joke about the Danish band fell a bit flat to the audience), but in the spirit of continual improvement, let us know what you think.

Reporting in Project Online…..or…..How to Make a Technical Presentation Fun and Interesting