Ages ago I wrote one of the 1st Project apps on ServiceNow. It was just a hierarchy of tasks with a project rollup. After that, & a few attempts at being a PM, I thought I'd never touch that domain again. But as the saying goes: "Want to make God laugh? Tell him you have a plan". Fast fwd a few years, I spent >1 year doing nothing but ITBM consulting.

ITSM usually deal with software savvy people used to swapping platforms every few years. Not so with ITBM. PMOs come from less tech background, & used fewer platforms for much longer periods of time. My first ITBM customer entertained my theory that deployments should start with large scale deep dives. We brought a dozen stakeholders with different PMO roles, & gave a week long demo. Avoiding "workshop" lingo really made a difference. By the end of the week we had cataloged - "Scenarios" that would need mapping (ie. "What happens if a project with allocated resources gets put on hold for a known period"?) - Places that "felt uncomfortable" - Glaring gaps that require customization / configuration - Areas to focus training. - "Oh Wow" moments you can start marketing in advance. Essentially, all the stuff you *might* gain from traditional workshops, but with a definitive bent towards training. Full disclosure, I love the status report concept in ServiceNow, but it has two major complications:

1) It is completely non-configurable. "but Robert we can UI Page quack quack" NO! Not without significant dev experience & future collision risks.

2) It is hard to distribute. To read a status report, you must be able to read Project. That means minimum ITBM licenses for any status report reader. But reality shows us that people interested in status reports is potentially ANYONE. It's just flat out hard getting the status report in front of people who are interested.

Enter VividCharts.

Our ITBM VividPack creates stunning, configurable Project Status pages easily distributed to a wider audience

Today's posture is "OOB as possible", but ITBM is ripe with exceptions. ServiceNow knows this as they continue to create huge meaningful updates every version. - Projects are often classed as "capital or operational" even though their cost plans contain both. In this case "capital" = "mostly capital" - Project tasks are often classed as "capital or operational". A project task for development will be capital expenditure where as training will likely be operational. ServiceNow has no answer for this.

- Until New York, Time Cards couldn't be broken down under 1 week*. HELL for companies that did monthly invoices based on time entry*.

- Customers who love RIDAC the most want to filter which belong on a status report. A PM wants a wider view into RIDACs than the people they report up to. - Resource Plans don't have OOB concept of "requestor", making it annoying to communicate updates to resource plans to the appropriate managers. Where ServiceNow and customer desires overlap, try to stay OOB. But you'll find many new paradigms in ITBM that have no ServiceNow analog. Shout out to the partner who told me "

LoL dOkUmEnTasHuN iZ hArD LoL

", after bragging "this is the most custom deployment we've ever done" as if they were heroes. I know you're reading this. The customer did a hard reset on ITBM *WEEKS* after you left. Losers. ITBM deploys have much higher documentation requirements: WHY? - See the "gaps" section above. There's a wider set of essential things that may need to be developed in. - Less tech savvy users & stakeholders - Way more financially impacting work scenarios. - Two doc necessity: a handoff to the ServiceNow team (what we did), and a PlayBook for the different ITBM roles covering their scenarios. - Classroom training doesn't scale. Coursework is forgotten days later. Some ITBM scenarios are run only a few times a year.

- Lost knowledge = risk. Projects have a higher financial & risk profile than other ITSM task types.

How about this: Want customer to love you year over year? Compare your previous ITBM documentation with new release notes & give them a head's up on critical changes. Customers LOVE that. Oh, you didn't document because "dOkUmEnTasHuN iZ hArD?" LOL! No problem! Stop being a loser.

A difficult political battle. Demand has the potential to be the ultimate "Front Door" to work. It's Four Outputs make it exquisite for teams in & out of the PMO to understand work commitments before committing. But its a near universal that the PMO considers itself the "owner" of Demand, and sees it only in the context of Project. If you can open their worldview, BIG gains can be had here. (reply if you'd like this addressed as a megathread of its own) My most bitter ITBM lesson. If you're migrating projects from anywhere, get them started immediately. ServiceNow's Project Migration tool is excellent*, and getting better all the time.* But gaps still exist. Did you know ServiceNow & MS Project have entirely different ideas on what "Start ASAP" means? ServiceNow: Start ASAP means start when your predecessors are done. MSProject: Start ASAP means start when your predecessors are done OR when you log time. Result? MSProject has free floating Project Tasks meant to start when time is logged. ServiceNow forces them to start at Project Start, throwing off complicated WBS plans by weeks. For same reasons listed above, have PMs groom their WBS. - Prune out unwanted tasks. - Ensure free floating Start ASAP tasks have a predecessor of some sort OR give them a future fixed date. - Re-Assess exotic predecessor / successor relationships Like... really hard. Here are a few tips: - The user/role/group paradigm is good on paper, but I find most PMOs starting on ServiceNow aren't mature enough to *start* with roles. - Requesting "users" resource plans is weird. Pick a specific user and ANY resource manager can approve? Spits in the face of the group management paradigm. - Because of above points, I almost always default resource plans to group resource plans - Customer MUST think of Resource groups as different from Operational groups. Like in case of shift management, some ops groups have the same users in them. You MAY need to build separate groups to facilitate resource modelling that doesnt work the same way as operations. - Everyone assumes group managers will hate resource management. Introduce them to Operational Resource Plans and they'll be your biggest ally."When actually actualizing your actual actuals, which actuals are actually the most actual actuals?"Just because a field says "actual" doesn't mean that's the actual actual the customer is interested in.

Best example is on Resource Management which has an "actual" count for hours and price. The ONLY reason this is handy is to determine if your original estimates are accurate or not. Don't ever confuse this with concepts like Actual Cost on cost plans, or actual start / finish on project tasks.

Consider!

Resource Actuals: Good for seeing if our resource estimates were accurate. Helps us get better (maybe) at resource estimation

Cost Plan Actuals: Helps us understand how far we from our estimated costs. Helps us get better at cost estimation and also identify where we're over budget in flight.

Cost Plan Breakdown Actuals: Helps us understand our burn rate on cost estimates. Are we spending faster than we planned.

Planned Duration vs Actual Duration: Helps us understand if the project task itself is more or less than the time planned. This is a different conversation than the resource actuals, since resource plans are more abstract than project tasks.

Understand your actuals and what they're actually there for!

## (MOST) ACCELERATORS ARE STUPID

There I said it. Had a customer who's ITBM vendor deployed an "Accelerator" update set with over 1200 updates. Wager a guess at how many lines of documentation? NOT ONE!! Customer can't distinguish OOB with all the stuff they didn't ask for: SHAME ON YOU!

For the rest of you, read "the straight dope on accelerators". That will tell you how to properly vet accelerators. Also, don't fall for the stupid "this isn't an accelerator, its a booster!" line. If it deploys pre-developed code, its an accelerator. Taking my content survey helps me navigate what to create. If you'd like to sponsor my content, reply to this message for options & rates.

If you get tremendous value, consider a donation. If not, I still greatly appreciate your readership.

VICTORY through superior design and story telling friends.

I remain yours truly,

Robert "The Duke" Fedoruk