Best practice of structure in PPM?

[Henrik Jutterst]

Hi all!

We're about to implement PPM and start using this instead of previous project management tools (MS Project).

What I'm looking for is some sort of best practice on structure of Portfolio, Program, Project and Demand to an organisation with different business units.

Should a Portfolio be set up based on:

• Business Unit
• Type of project
• Internal / External
• Other structure

Pro/Con

• Business Unit:
  • Pro: Logic structure. Each BU can see and handle their own programs/projects/demands
  • Con: Organisation structure will constantly change.
• Type of project
  • Pro: Types will not change that often just be added.
  • Con: Might be a messy solution over time.
• Internal / External
  • Pro: Very clear structure
  • Con: There might be some projects where it includes both internal and external projects
• Other
  • Pro:
  • Con:

Please if you have any input or can link to related articles for PPM in ServiceNow where the discussion is about these type of architectural decisions.

We are running Jakarta and I've been looking at this documentation up til now.

Portfolio Management

Also looking into this one now: Project Portfolio Management | ServiceNow

[Sean Hamilton]

Nope, sorry I respectfully disagree.   Humans are humans, and until you change the money greed, this will never change.   If the org structure changes (which it always does), the money follows it.   You have to follow the money.   That's all anyone cares about here!

[Sean Witt]

Henrik,

You've already gotten a lot of good feedback, so I won't pour too much more onto the pile...but a couple of things to consider.

You mention wanting to leverage an OOTB approach, and OOTB there is more structure and reporting built at the portfolio level, versus program, department or business unit. All of those reference fields are/can be tied to demands and projects, but the core OOTB parent for both demands and projects is the portfolio. Portfolio dashboards and reports are used to review and rank demands when working on planning for the next budget cycle. OOTB stakeholder groups that can review and score new demands are based at the portfolio level.

So if you want to be able to review potential categories of demands within your organization, and roll-up project financials, portfolio would be the most OOTB approach.

One thing to watch out for is the CIO Roadmap and some of the other visualizations won't allow for viewing more than 8 portfolios side by side. So if you have a larger number of "portfolios" in your organization, you may want to look at a combination of portfolio AND program. OOTB there is NOT a notion of parent and child portfolios, meaning a portfolio can't contain a child portfolio, but programs can be standalone or nested inside of a portfolio as a child.

I think Sean Hamilton made a good point with the "follow the money" piece. There are many different existing OOTB fields on the demand and project forms that you can use for task assignment and reporting (i.e. by department, business unit, assignment group, etc.). That is pretty easy to do from a reporting perspective, but the value add of the portfolio and program options are that they are designed to be used for rolling up some of the financials for the people within the organization that need to be watching the bigger picture. I don't think you would want to pursue custom roll-ups at the department or BU level to recreate or modify things like the Portfolio Workbench, which is why I would lean toward using either just portfolio, or portfolio plus nested programs, depending on the size of your organization.

Sean

[robhprojility]

Also keep in mind that beyond them being objects in ServiceNow, Programs and Portfolios have very different business purposes that should be understood and defined prior to use (Robert did a nice job explaining this above). Programs is not just a rollup of projects but a long term investment an organization makes with a specified business purpose, that may include projects, non project activities, other investments, etc..   Portfolios are groupings of like projects (or assets, or investments, but in PPM they are projects) that can be analyzed, evaluated, tracked and managed as a set of investments.

First thinking about how the organization wants to define and use these at a management level, what those requirements are, will define if/how you use them in your PPM environment.   While they seem like convenient ways to organize projects (they are!), the risk you run is to start using them without having management buy-in and start to confuse use in the system versus use in the organization.    

We have clients today that organize their projects by Departmental Portfolio (here's a list of all the projects Finance is considering in 2018, which makes it the Proposed 2018 Finance Portfolio), Enterprise Portfolio (our Top 10 investments for the year, prioritized), and even by function. Programs should be distinct by definition and may or may not have a relationship with a Portfolio. Like a Digital Transformation program, which may have projects from multiple Portfolios with it (5 from Finance, 10 from IT, etc.) So there's alot to consider organizationally and relationship-wise prior to implementation. Re-do-ing this later can be more painful than spending time up front the first time to get it right (in our experience)...

-Rob

[Ricky Singh]

Portfolio management defines the following steps that are needed

1. Set targeted Budget in terms of Capex & Opex for a Financial year
2. Select the demand s & projects that you plan to execute during the year.

This means Portfolio management provides the missing piece of the puzzle as to how budgeting is to be applied from top-down. Portfolios should be defined at a level where you have a clear budgeting bucket available in your org. For example, let's say if the Security department has a common budgeting bucket then it should become your portfolio, thereby allowing you to set up the budget for the entire portfolio.

If the budgeting is available at enterprise strategy or business unit strategy then it allows more freedom in deciding as to what should be portfolios. take into consideration the reporting element along with clear identification of portfolio managers.

-Ricky