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

[Uncle Rob]

My suggestion is that if your Org's PMO hasn't got its own model for Portfolio, don't use this functionality in SN.

Its probably the most common design miss-step I see in the ServiceNow space with respect to PPM.   You don't self-define Portfolio, so you define it on the spot.   By the time your PMO comes up with one, the paradigm has already been established and then its time for industrial scale dental surgery to refactor everything.

Other food for thought.   The portfolio only really exists for the benefit of upper echelon decision makers.   Its a reporting unit for a family of projects where reporting on individual projects isn't practical.   Having that designed in a bubble by the tool engineering resources is ineffective at best.

[Henrik Jutterst]

Thanks for the advice Robert!

We are looking to go Out Of the Box functionality as much as possible. At least in the beginning of the transformation into ServiceNow. But with this, we haven't been using the ServiceNow concept of Portfolio/Program/Demand earlier.

The thing is that we want all our business units that work with project in some way to work in the same way or at least with the same basic concept of setting up projects and delivering them.

What do you say, is this something that we need to set before continue with our implementation or do you think this can wait? I still really don't know how to get my head around this.. or if I should let it go?

[Uncle Rob]

Going "OOB as possible" is an awesome strategy... for configuration, but *not* in terms of data.   If PPM indeed comes packaged with Portfolios, its demo data, *not* a suggested best practice.  

Totally with you on "everyone should use it the same way", but your problem right now is that there isn't pre-defined "way" in the context of Portfolio Management.   You need a PMO authority to make that decision.   Its not a decision the tool config discipline should concern itself with.   If it were my ship, I'd deploy Project capability void of Portfolio.   People will naturally want to start rolling the Projects up... and that's where you'll point to your Process Flow docs with the big empty Portfolio process and say "then help me understand how the business does this".

[richelle_pivec]

We're about to go to Prod with our PPM build, so I can tell you where we landed.

For Portfolios we went with Business Units. We did this primarily because that is how are organization is segmented and because we have specific Business Relationship Managers (BRMs) who handle each unit. Plus it would be easier to report to the heads of those units by the projects under the units if we could tie them together in the portfolios.

For now, we skipped Programs and Resources as they were layers we didn't really need.

We are using Project (of course) and Demand. Our BRMs will be inputting their gathered requirements (from SBARs/meetings) into Demand and then those will be transformed into Projects for our Project Managers once they are approved. (Out of the gate our Project Managers will do the Demand input during the hand-off meeting with the BRMs, but the eventually plan is for the BRMs to add the Demand data.)

The Projects are going to be categorized into types (Categories): Strategic Initiatives, Dept Initiatives, Regulatory & Compliance, and Maintain/Upgrade/Replace. We also added a Project Governance field to tell which level of governance the project needed to go through.

I hope that's helpful.

Richelle