So you’re about to implement a new contingent workforce management programme. How do you get started? What drives your design principles? And when do you think about reporting requirements?

Too often, I’ve seen companies leave reporting to last (or not all) when working through their business and technical requirements. I would like to assert that defining your reporting requirements should be the very first thing you should do. Reporting should drive your processes, system requirements, and operating model design.

Understanding what story you are trying to tell to executives, what information is required by key stakeholders, and what the key data points are with respect to your contingent workforce is fundamental to any mature contingent workforce programme. This starts by understanding your target audience. Map out all of the stakeholders that need information from executive sponsors to business unit leaders, functional stakeholders, and individual managers. Each report recipient has a different primary concern, and may require different ways of slicing or presenting the data.

Once you know the audience, you need to define the requirements for the reports themselves. The types of reports that you will need to consider include:

• Dashboards: Both inside and outside of your VMS system, what stakeholders need a high level view of activities and performance?
• Quarterly Business Reviews: How can you easily show the key information to have important strategic discussions with executives, key stakeholders, and supply chain partners?
• Programme Performance: What are the SLAs, KPIs, and other key metrics that will indicate performance of the overall programme, including individual elements like processes, suppliers, and workers?
• Cost Savings: Even if cost savings is not the key driver behind your programme, it’s always important to demonstrate financial value when it comes to the management of the contingent workforce.
• Activity Analysis: On the more tactical side, how are you able to track the activities of specific actors such as sourcing consultants, suppliers, and managers in order to ensure that resources are being allocated appropriately, processes are being de-bottlenecked, and the business is getting the service they want?
• Supplier Performance: When you have supplier reviews, can you use data-driven analysis rather than relying just on anecdotes?
• Compliance: How can you demonstrate the risk avoidance that a CWM programme affords you in an automated way?
• Financial Controls: You can be a hero to your controllers, business leaders, and finance community by providing budget vs actuals, accruals, and detailed financial reports that provide far more insight than invoices or purchase orders.

Each of these reporting requirements will drive the data elements you need to capture at each stage of the process. It will also define elements of the process, such as approvals, onboarding, and invoicing. As it turns out, this is actually a much more efficient way to define the overall solution than the traditional process design, integration design, and operating model design coming first and reporting coming last. More importantly, you won’t need to go back and rework your system, integrations, and process just to capture important data points. You’ll also be able to focus immediately on demonstrating the value of the programme which will help with change adoption… ultimately, making your programme a success.