question Best practice of structure in PPM? in SPM forum

Best practice of structure in PPM?

Henrik Jutterst — Fri, 01 Dec 2017 13:50:37 GMT

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

Re: Best practice of structure in PPM?

Uncle Rob — Fri, 01 Dec 2017 14:05:16 GMT

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.

Re: Best practice of structure in PPM?

richelle_pivec — Fri, 01 Dec 2017 14:09:01 GMT

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

Re: Best practice of structure in PPM?

Henrik Jutterst — Fri, 01 Dec 2017 14:43:26 GMT

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?

Re: Best practice of structure in PPM?

Uncle Rob — Fri, 01 Dec 2017 14:48:39 GMT

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".

Re: Best practice of structure in PPM?

Henrik Jutterst — Fri, 01 Dec 2017 14:56:45 GMT

Thank you Richelle!

This is just what I was hoping for in terms of feedback! Basically we're looking for what previous users have learned from their experience on the implementation.

What is your best do and don't regarding this and what did it take you to implement and start working in ServiceNow with projects?

Re: Best practice of structure in PPM?

sachin_namjoshi — Fri, 01 Dec 2017 14:59:49 GMT

I implemented PPM for various kind of customers.

I find below things common in those implementations for portfolio implementation.

- Portfolio is based generally on type ( client, corporate, IT)

- OR portfolio is categorized on category of portfolio ( business function)

Regards,

Sachin

Re: Best practice of structure in PPM?

Uncle Rob — Fri, 01 Dec 2017 15:03:55 GMT

If you're going to dare defining this absent a PMO discipline at your org, keep in mind that SN now allows definition of both Portfolio AND Program. Whatever you do... make sure the distinction between Portfolio & Program is clear and sacrosanct.

Both Portfolio and Program are abstractions of projects though... so you *REALLY* need to have PMO insight into their definition, otherwise you're fixing the success of the deployment to a guess.

Re: Best practice of structure in PPM?

Sean Hamilton — Sun, 03 Dec 2017 13:23:14 GMT

Hi. My very simple advice is "follow the money!" Which usually (but not always) means a business unit, then cascades down to departments, etc. (which include Programs and projects. That should simplify everything! You should build your portfolio around whoever has the final authority to approve budgets for their BU / Dept.

I completely agree with Richelle Pivec'sDec 1, 2017 6:09 AM reply!

Re: Best practice of structure in PPM?

Henrik Jutterst — Mon, 04 Dec 2017 07:41:32 GMT

Hi Sean and thanks for the post!

Even though I fully understand and in some ways do agree with you I have to ask; what if you live in an ever changing structure change of the organisation? I guess that will create extra work in terms of structure?

What if we focus on Type of project instead?

Re: Best practice of structure in PPM?

Sean Hamilton — Mon, 04 Dec 2017 14:25:25 GMT

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!

Re: Best practice of structure in PPM?

Sean Witt — Mon, 04 Dec 2017 21:24:01 GMT

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

Re: Best practice of structure in PPM?

robhprojility — Fri, 29 Dec 2017 18:38:53 GMT

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

Re: Best practice of structure in PPM?

Ricky Singh — Mon, 27 Jul 2020 21:24:51 GMT

Portfolio management defines the following steps that are needed

Set targeted Budget in terms of Capex & Opex for a Financial year
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