Dynamics 365 Project Service Automation differs between organizations and partners. This includes the reasons behind implementing it, the way it is approached and even the way it is implemented. PSA (and Field Service) are both applications that can be used out-of-the-box by simply going through all the required settings and parameters. Usually a PSA project does include some customization just like any D365 CE project but with PSA one thing is a little different: The logic in which the application works is not to be changed and when customizing or writing code, the functionalities and the “PSA process” of the application should only be extended. Not changed. This way you will have a working application as new functionalities are released.
The hardest app to master
While the Sales and Customer Service applications are straightforward, PSA and Field Service have a lot more to them. I’m not getting into Fields Service in more detail on this blog post because that really is a story of its own. Let’s focus on PSA for now. In reference to Steve Mordue’s fantastic blog post, what is simple for me might be hard for you and vice versa. Steve brought up our mothers but I’m not going that way – let’s say we focus on millennials. No matter how we quantify simple, I still want to argue PSA still is the hardest application to master in the D365 CE stack. I’m black and white in that sense.
What does “the hardest” app really mean? In short it means the “PSA process” from prospect to cash and understanding what bits and pieces we must consider when executing the process. From a business perspective, an additional factor is that you really can’t easily force PSA to your business’ processes as the way we use PSA is fixed – hence the name the “PSA process”. You might be thinking “But we have Business Process Flows in D365 CE…”. That’s a nice thought but that’s not what I mean. I mean the overall high level process of how you go from prospect to cash in PSA and what you must do in the application to get it to function properly. It’s a ready-made app so when you think about it, it should make sense, or…?
Two approaches to implementing PSA
I’m going to boldly state there are two approaches to PSA when we use its core functionalities and don’t extend it. We can take the app to the moon and back by building around it like the awesome Chris Huntingford demonstrated during the D365 UG Virtual Summer Camp on his RAID logs presentation. Extending is not the point of this blog post though. Let’s keep our focus on the app as it is OOTB.
Implementing PSA as whole (as in leveraging all it has) in an organization is a big effort. This is the case especially when an organization is new to D365 CE and has no experience with the product. If the whole “PSA process” is too much, what options do we have? How do we start with what we really need from a business requirements point of view and then pick up the “nice to have” later? For this we have two approaches.
1. The Financial container
One of the two approaches to PSA is the financial aspect. The “financial container” is essentially your Project Contract and everything that happens around it. It’s a container for all your financial data. When approaching PSA from a financial perspective we want to get financial data out of PSA and then push it to an ERP like Finance & Operations or Business Central for invoicing.
With the financial approach, we look more closely at the opportunity to invoice process without putting too much effort on the project management and resourcing side of PSA. Projects will be there because naturally it’s a prerequisite to getting our financial data but the focus is not on projects per se. You’re probably asking for some concrete examples by now so let me try to dive deeper into the financial container.
The financial approach is around the Project Contract and how that is set up. We have our Time & Material and/or Fixed Price Order Lines to define what our contract and the project(s) related to it are like. Our staff submits Time and Expense Entries so that we will get the necessary Actuals that we will then invoice. We focus on the profitability of our contract and its performance. The “financial container” is business critical as it produces our financial data.
The financial side of things is usually taken quite seriously in an organization (gee I wonder why this is…). When it comes to implementing the “financial container” we have a lot of ground to cover in PSA and there is quite a bit to learn. As this approach is something an organization really must master perfectly, there might not be a lot of steam left to cover the other container described in the next paragraph until everyone has had a bit of time to digest what was just implemented.
2. The Project container
The “project container” is essentially a container for work. It holds the concepts of project management, project work breakdown structure and resourcing. With a focus around projects and work, an organization wants to focus on managing and running projects and assigning the right people on the right tasks at the right time. In PSA, we can plan and execute projects without needing to focus on the financial side of things.
When we dive deeper into the project container we look at very granular project planning and granular task specific resourcing. Version 3 of PSA has decreased the overhead in resourcing significantly by separating resource bookings and assignments on tasks. Resourcing is nevertheless a pretty intensive task for an organization and the functionalities around resourcing take quite a bit of learning to really master. If you really want to make resourcing in PSA effective, you need to know it well and be consistent in resourcing your staff.
There are naturally bits and pieces like resource roles and project work breakdowns in this container that we also need to take into consideration on the financial side. The granular resourcing and planning are where the contents of this container get heavy to handle so implementing that granularity and the aspects around project management and work are something that you may want to implement either before or after the “financial container”.
Summary
The approach to PSA doesn’t have to be everything or nothing. Your organization can split a PSA implementation into two containers: A financial container around Project Contracts and a project container around work, projects and resourcing. Your business requirements naturally drive your implementation. In any case I want to say use a partner in your PSA implementation. And not just any partner but one that really knows what PSA is and how it works.
Disclaimer:
All my blog posts reflect my personal opinions and findings unless otherwise stated.