Resrouce Management Implementation

[KhoendibG]

I was wondering if anyone has recently implemented the Resource Management application in SPM and would be interested in sharing some of the their learning?  

We have recently implemented Demand Management, Project Management, and Portfolio Planning. Our learning from these implementations is that the change impact (particularly on process) was quite significant. We are look at implementing Resource Management and Capacity planning bits of SPM next, but a quick glance at the documentation shows quite a complext involved in Resource Management. 

So I wanted to ask the community, what advise would you give to yourself before your Resource Management deployment journey? What are some of the lessons you learnt when operationalising Resource Management? What would you do differently or what worked really well? 

Any insights would be really appreciated! 
Thanks in advance! 

[Uncle Rob]

So first I'd bookmark the Quickstart Guide for Resource Management.
That thread is kept up to date by the product team so its the closes thing to state-of-the-art that you can find.

Some unsorted thoughts on 3 RM deployments.
- Its very difficult to do in "pilot".  RM has to be sold to all teams doing project labor, and they have to move on as one.  Reason:  What good is resource management when only a fraction of the teams are represented?   Minimum participation has to VERY HIGH.

- RM is laborious, so everyone has to know what they're buying with that labor.  Since groups will now spend significant hours negotiating / formalizing labor, they need to know what's in it for them.  My narrative wedge there was two fold:  the use of operational resource plans (planning to do non project work), and "better than trust me" data on real capacity.

- You can never have enough training material.  Booklets, videos, live training classes will need to be a PERMANENT fixture.

- Remember: The point is not to micromanage hours.  Real life is going to happen, and you don't need to be adjusting resource plans for missed days etc.  The metaphor I liked is "plan your highway for the amount of 18 wheelers it can support at once.  The Toyota Camrys will take care of themselves".
- Success is not "features delivered", its "features adopted" - to that end your training needs to be PLAY BOOK focused.  Don't just describe the interface, give them indexed actions:  "This is what you do when you want resources.  This is what you do when you need to extend.  This is what you do when you want to cancel.  This is how resources are negotiated.  Here is what reports you run and when you run them"

[Uncle Rob]

Just want to dive deeper on one thing.

EMOTIONAL LOAD > LOGICAL EXPLANATION

The better you are at connecting features with emotion, the better your engagement & adoption will be.
Roleplay this over and over.  Why do your groups want to do Resource Plan negotiations?
Answer:  They don't really.  Its bureaucratic work.
You know what they DO want though?   They want to be rid of the capricious winds of corporate preference and the giant DUMB resource squeeze.  "We know you're already busy... just find a way to make this work".

We've all been there right?  A week jam packed with deliverables and someone just doubles your work load.  
You're just going to have to work harder.  Maybe engage in some unpaid over time.  "Rob Peter to pay Paul"
Team leads hate that crap.  It makes them feel unheard and untrusted.  It makes them feel like a wage slave.  "Doing more than you have time for is just how things are done here"

But its not because management is malicious.  Its because until now the idea of commitments and capacity have been INVISIBLE.  So the question is it "why won't you use this feature thats part of the process".  Its now "Why aren't you shielding your team from being overworked?"

TL;DR.  To drive feature adoption:
- Make bad feels go away.
- Make good feels happen more often.

[Chris Cannella]

Hello, 

In addition to the Quickstart Guide for Resource Management there are also on demand classes and documentation you can leverage to get started and learn more. 

I'm one of the product managers working with resource management.  I'm sorry to see that you are hitting challenges with the new experience.  Our goal is to reduce complexity and provide an experience that can  be configured to your processes so that adoption is easier.    

My recommendation would be to think about how you would want to work, not how you think the system will make you work, then see where the system fits.  By way of example, there are multiple ways you can assign a resource to a task - The lower tray of PW, the upper tray of PW, the list view, from RMW, etc.  If you were to say "at our company, we are low maturity and just looking for something that is directionally correct.  We don't want profiled demand curves and people are assigned for the duration of a phase", I would probably recommend you leverage the top tray and create assignments at the phase level - regardless of how deep your schedule goes.  If you preferred profiled demand curves have a highly centralized process, I would recommend you use the bottom tray of Project Workspace.  Restated, the answer as to the best way will be contextual.  Think about how your project managers want to manage projects and how they want to staff their projects (the depth and the method).  Leverage those parts.    

We will be working on 'bite sized videos' to help address nuanced usage based on maturity and level of specific processes we've been hearing about.  Until then, I'd recommend you work with your implementation partner or ask in this forum.  I hope this helps, and feel free to reach out with questions. 

-Chris

[KhoendibG]

@Uncle Rob, @Chris Cannella thank you both for the really valuable insights! Im eager to start reading the resources you've shared with me!