Insights

As stated in a previous blog post, Service Level Agreements (SLAs) with clients are key elements of business process management and must be supported by the project management system.  Another important element of managing field service projects is establishing and tracking appropriate SLAs with Field Service Representatives (FSRs) and/or associated contracting companies.  While the primary field service company responsible for the project carries all the risk in meeting the contracted client’s SLAs, key tools, procedures, best practices, and system capabilities are needed to manage that risk when using a gig-workforce.  Also, key elements of system integration will be needed to track operational effectiveness against the contracted SLAs.

Client SLA Types and Attributes –

The project management system must be able to capture key SLA attributes from the contract with the client.  This implies that the SLA definitions in the contractual agreement must be detailed enough to provide the necessary attributes for tracking, reporting on compliance, and billing.  We define SLA Types as formulations and/or measurements used to evaluate whether contractual objectives are being met.  We define SLA Attributes as the elements, triggers, and constraints used in support of the formulation for the target SLA.  

Example Client SLA Types:

• Turn-Around Time (TAT) – max. time taken to complete a task(s)
• Average Turn-Around Time (ATAT) – average time taken to complete tasks 
• Response Time – max. time required to respond to a work-order request 
• Average Response Time – average time required to respond to work-orders 
• Abandonment Rate – not to exceed percentage of work-orders abandoned while waiting to be completed
• Time to Assignment – time from request received to its assignment 
• Time Service Factor (TSF) – percentage of tasks completed within a definite timeframe
• Task Completion Rate – tasks completed/timeframe, objects built/timeframe, …

Example Client SLA Attributes:

• Location/Time Zone for SLA Time Reference 
• SLA Units of Measure  
• Task Property for SLA Start Trigger
• Task Property for SLA Complete/End Trigger
• Days/Times of Effective Operation (e.g., operating hours of business that effect SLA calculations) – examples: 6am-5pm, Monday-Friday, 8am-12pm Saturday.
• Exceptions to Days/Times of Effective Operation (Periodic and Absolute)
• SLA can be paused during non-operational hours: Yes/No

An integrated project management system to support emerging field services using a gig-workforce should have the capability of capturing a wide range of client SLA types and client SLA attributes and be able to handle the formulations needed to calculate, analyze, report, and bill for SLA performance.

Managing FSR SLAs –

To adhere to the laws defining how a company can engage contractors or field service representatives (FSRs) to maintain their 1099 tax reporting relationship, the level of detail used to assign and manage that contractor’s or FSR’s activities is limited.  Also, the types and number of incentives that can be leveraged to ensure meeting project objectives (e.g., client SLAs) are also limited.  Therefore, the drafting and management of service levels with FSRs or related entities can be a challenge.  In general, a project management company can only contract a project’s start and completion dates/times with an FSR.  The company cannot manage the FSR’s scheduling of their individual activities in support of that assigned project’s completion.  The project management company also must be careful on how they might incent the FSR to complete the project early, increase their productivity, and/or deliver higher levels of quality.  Obviously, after working with FSRs over time the project management company can target those FSRs that deliver the highest productivity, quality of work, and are the most reliable.

There are several approaches a project management company can use to incent an FSR’s productivity, work quality and/or reliability.  The first is to give the FSR the flexibility to select which contracted completion date/time they wish to accept, which would come with a predetermined payment for that project or task.  Typically, the earlier the completion date/time selected by the FSR, the higher the compensation for that work.  The same could be done with contract selection options for productivity and quality measures.  Note that if the project management company can get FSRs to select the higher productivity contract options, their risk in delivery to the Clients SLA is lower.  But there is a trade-off between lowering risk, lower margins, and higher customer satisfaction.

Another approach is to score an FSR’s performance for each contract.  Productivity, quality, responsiveness, and reliability metrics can be leveraged to evaluate an FSR’s long-range performance.  As an incentive, these long-range performance metrics could be made visible to the FSR.  This awareness will provide a clear understanding of how the FSR can improve their performance, receive more job opportunities, and increase their income potential.  For reasons of privacy and to avoid defamation lawsuits, it is advised that no performance scoring is provided on social media or to other companies.  But the project management company could validate a performance score that is provided by an FSR to another company as a reference to their work history.

Given the variations of state and federal laws, care must be taken when implementing any system that contracts with FSRs and attempts to incent their performance.  But project management companies that leverage the gig-workforce must find ways to reduce their risk, maximize their performance, and optimize their business results in the face of delivering to complex and varied client SLAs.

Service Level Agreements (SLAs) and Key Performance Indicators (KPIs) are key elements of business process management (BPM). While SLAs and KPIs are closely related and provide insights into specific performance measures of a business, they have clearly different scope and intent. Also, SLAs and KPIs can be difficult to define, measure, and achieve when using a gig-workforce to deliver field services. The laws and regulations used to define how a business engages a gig-worker (1099-NEC tax reporting status) and the type of work involved in the delivery of field services can make establishing and accurately tracking SLAs and KPIs difficult.

Service Level Agreements (SLAs) – 

Wikipedia defines SLA as “a commitment between a service provider and a client…(where) aspects of the service – quality, availability, responsibilities – are agreed” (https://en.wikipedia.org/wiki/Service-level_agreement).  In other words, an SLA is a written agreement that qualitatively and quantitatively specifies a service commitment between a business and its client. SLAs usually define units of performance measure and penalties for failure to meet those measures. SLAs are set to measure, evaluate, and compensate for future service performance. SLAs can include standards for timelines, quality levels, and/or the amount of service a client expects from the field service provider. In addition, SLA metrics allow clients to track real-world needs of their businesses and are usually set by the client for the field service business to meet.

Key Performance Indicators (KPIs) – 

KPIs are measures that define the progress with respect to a strategic goal or objective. KPIs are used to measure past performance and whether the business is meeting expectations relative to growth, revenue, ROI, profit margin, or other decision-making criteria. KPIs are usually set to evaluate whether a business is meeting its strategic goals and what areas need to be addressed to improve its performance. 

Using SLAs and KPIs – 

As mentioned, SLAs and KPIs are closely related, but clearly different. An SLA is forward-looking, while KPIs focus on past performance. SLAs set benchmarks for you to measure performance in the future. KPIs will measure the performance of your business against strategic business benchmarks as time passes. KPIs are set based on strategic goals and objectives, while SLAs are near-term performance metrics that can directly impact a business’s operation or abilities. SLAs are used to establish expectations (usually via a contractual agreement) for service delivery by another vendor, while KPIs are used to self-evaluate success or failure towards specific goals and objectives.

Main Elements of an SLA –

• Business Objectives: objectives to be achieved in the provision of the services.
• Target Services: description of service deliverables.
• Performance Metrics: performance standards expected by the client.
• Reporting Mechanism: mechanism for periodic reporting of performance metrics.
• Compensation Credits and Remediation: compensation formula that incentivizes for exceeding performance metrics and penalizes for failure to achieve performance metrics.
• Change Control and Contract Management: mechanism for periodic review and change to the service levels over the course of the contract.
• Grounds for Termination: conditions that give the right to terminate the contract where performance standards fall consistently below an acceptable level.

Managing SLAs when using a Gig-workforce –

Establishing and tracking SLAs in field services delivery can be challenging. A field service business, and its project management team, cannot manage a group of “1099 contractors” the same way they manage the company’s employees. The differences associated with managing contractors versus employees can present interesting challenges to the project manager, especially in relationship to tracking and achieving certain SLAs. Given a project manager can only provide a gig-worker with start and complete-by dates/times for a given workorder or project, it is difficult to track incremental progress and/or fine-grain elements associated with the work. Therefore, the project manager has a difficult time determining where a project or workorder is against a specific SLA. 

The other challenge is developing a project management system with sufficient flexibility to support a wide variety of SLAs. Common components of an SLA include response time, time to complete service, quantity, completion percentage, quality levels, failure rates, times of operation, exclusion dates, etc. Providing a simple interface to allow project managers the ability to input complex formulas with abstract variables that can be tracked, analyzed, invoiced, and reported back to the client has proven to be difficult.  The variety of projects inherent in field services, and the complex constraints often placed on the time and location of the service, makes it almost impossible to cover all possible SLA descriptions. In most cases either the project management system covers a limited number of project or work-order types, and/or a person must implement a customer specific tool (usually a software application or interface) that implements a formula that matches the SLA description. This “application” pulls relevant project/work-order performance data from the project management system in real-time, and reports to the client, and billing/invoicing system, to what level the performance objectives were met. Therefore, the cost to a field service company to implement, track, and report SLAs can be significant. 

Present State of SLA Implementation in Field Service Project Management Systems –

At present few, if any, project management systems can support the wide variety and complexity of SLAs associated with field service delivery using a gig-workforce. Some project management systems attempt to provide sufficient APIs to allow external applications to retrieve relevant data in support of calculating and reporting on SLA performance metrics. Dashboarding of these performance metrics is important to the project management team and often requires yet another application to be leveraged. Therefore, an integrated system to support project management of a variety of field services and their related SLAs would significantly improve operational efficiency and scale of a field service business that leverages a gig-workforce.

There have always been Gig-workers: actors, artists, musicians, consultants, salesmen, real estate agents, handymen, etc.  There are several reasons why the gig-economy continues to grow. 57 million US workers in 2018, approximately 36% of the US workforce, appear to prefer freelancing over full-time employment, primarily since it provides them with greater flexibility and independence.  Estimates are that 87 million US workers will be participating in the gig-economy by 2027.  Non-traditional employment, particularly through gig economy platforms, enables individuals to pick their own hours, place of employment, and clients.  Firms also can benefit from using a gig-workforce through more efficient management of expenses, increased access to a higher variety of skills, and better management of resources via on-demand staffing.

There are three main factors which are driving the growth of the gig-economy: 1) the need for businesses to better manage resources to match business demands, 2) workers wanting more control of their work schedule for a better pay and work/life balance, and 3) technology which enables real-time remote coordination and management of work.  Even though working in the gig economy offers a lot of freedom and flexibility, workers in the rapidly evolving gig-economy are finding they face new challenges.  To broaden the expansion of the gig-economy into the field service industry, corporations must leverage new technologies, management platforms, and processes to manage projects, as well as offer access to “human services” to support the needs of a gig-workforce. 

Workforce Advantages and Challenges of Gig-Economy

Advantages:

• Flexibility – Research shows that 70% of freelancers say the main reason they do gig-work is to attain better work-life balance, with 60% saying their working conditions are flexible.  This allows the gig-worker to work when they want, how long they wish, where they want, and on the jobs they are most interested and comfortable doing.  This flexibility also provides ability to engage in continued education, certification, and licensing activities.  The Gig-worker can specialize or become multi-functional.
• Independence – Gig-workers have a sense of “working for themselves” versus working under a management system and/or for a company.
• Variety – Gig-work provides the workforce access to a variety of job options, which can help workers avoid boredom and be energized in their ongoing job activities. The Gig-worker can control their own destiny and develop their own interests while taking advantage of incremental opportunities where they live and work.
• Pay – Gig-work often yields a higher pay rate than regular employment status would provide.  The Gig-worker directly benefits from their productivity and skills and are not “held-back” by others.  Also, surveys show that 19% of gig-workers use gig-work as extra income.  Pay can also change more rapidly based on demand and skills availability versus traditional periodic pay raises for regular employment positions.  Finally, gig-workers have the freedom to choose what jobs they wish to work and can select the pay level they see is most competitive.
• Tax Deductions – The Gig-worker is essentially a business and can deduct legitimate business expenses and make investments in tools: vehicles, computer, hand tools, etc.
  

Challenges:

• Benefits – Gig-workers often must identify their own sources for health insurance, retirement plans, 401K, IRAs, life insurance, and matching contributions to a savings plan.  54% of independent contractors have no access to benefits through their employer or group coverage plan like a professional association; 40% can only get medical insurance for themselves if they’re married to someone who has it.
• Taxes – No tax is deducted from the worker’s pay to cover federal or state taxes.  The worker is responsible for paying their taxes quarterly to avoid penalties at the end of the year.
• Isolation – Often limited to no regular contact with other workers.  No sense of community or cultural solidarity, normally provided to employees who meet regularly in an office building, manufacturing, or warehouse environment.
• Potentially Inconsistent Income – Gig-work income is not guaranteed (like a traditional job with hourly wages) and can fluctuate depending on available assignments and the ability of the worker to identify opportunities. 
• Limited Guidance – Most gig-workers are independent contractors and do not have the benefit of a manager, project lead, or peer employee to continually provide advice and/or teach them how to work efficiently.
• Stress, Burnout, Exhaustion – Gig-workers must find their next gig or deal with frequent changes to their present assignments.  Gig-workers are not provided a guarantee of continued work or of new assignments once the present job is completed.  Gig-workers can also face rapid changes in salary.
  

Addressing Challenges Faced by the Gig-Workforce

• Access to Benefits – Companies contracting with a gig-workforce could provide access to health insurance plans, retirement plans, 401K and IRA plans, life insurance plans and membership in group travel discounts (hotels, rental cars, airlines, buses, etc.).  Other benefits include access to therapist, counselors, and coaching.
• Worker-to-Worker Engagement – Provide a specialized social media platform for Gig-workers to engage with each other and discuss common challenges and best practices found to complete and/or support assignments.  This also allows a medium for the workforce to discuss issues of stress, finding jobs, pay, and general work/life challenges.
• Access to Training/Continuing Education – Companies and academic organizations can provide programs and support for gig-workers to gain additional training, certifications, licensing, and other skills development resources, increasing the capacity and capabilities of the gig-workforce.
• Tax Management Tools – Provide the gig-worker access to tools and automated deduction from pay to help estimate and pay their taxes.
• Job Portal – Provide a job portal to expose gig-workers to job opportunities across an industry, a region, and/or an expertise.  
• Transparency in the Project Management Platform – Enable the workforce to see all available projects and their related work activities, both completed and in process.  Allow workers to engage with each other to share best practices, challenges, helpful tools/apps, skills requirement, and other items that would benefit them in their support of a project.  Finally, allow the gig-worker to sustain a record of their skills, experience, accomplishments, and job performance, which can be used to support access to future opportunities.

Note that there are many challenges and opportunities in expanding the use of the gig-workforce in the delivery of field services.  With the development and deployment of the right technologies, tools, programs, platforms, and processes, workers and companies can benefit from enablement of the gig-workforce to deliver field services.

References:

The Gig Economy by Edison Research: http://www.edisonresearch.com/wp-content/uploads/2019/01/Gig-Economy-2018-Marketplace-Edison-Research-Poll-FINAL.pdf

Gig Economy by PYMNTS.com: https://www.pymnts.com/wp-content/uploads/2019/04/Gig-Economy-April-19.pdf

Global Gig Economy by Mastercard: https://newsroom.mastercard.com/wp-content/uploads/2019/05/Gig-Economy-White-Paper-May-2019.pdf

Gig Workers in America by Prudential: https://www.prudential.com/wps/wcm/connect/4c7de648-54fb-4ba7-98de-9f0ce03810e8/gig-workers-in-america.pdf?MOD=AJPERES&CVID=mD-yCXo

State of Independence in America by MBO Partners: https://s29814.pcdn.co/wp-content/uploads/2019/06/MBO-SOI-2019.pdf

Definition: A Workflow is a sequence of tasks, with a set of objectives, to support processing of physical and/or data objects to achieve a set of goals.  Workflows are the flow of actions and decisions describing how something gets done.  Managing a list of unconnected tasks is not a workflow.  Workflows have tasks that are dependent on others in the workflow to achieve a unified goal or objective.  Three types of workflows may be built by workflow management systems, the use of which is dependent upon the needs of the project. These include sequential workflows, state machine workflows, and rules-driven workflows. 

• A sequential workflow is linear and progressive, like a flow chart. This workflow goes from one task or process to another and does not step back in the sequence.  This category of workflows includes “process workflows” where the tasks are predictable and repetitive.  Examples: expense report approval, employee onboarding, invoicing and billing, kitting, simple surveys.
• A state machine workflow is more complex than a sequential workflow and may step back in the sequence if a dependency mandates. These workflows go from one “state” to another “state” via an event-driven set of operations.  Examples: inventory management, software development, equipment or process testing.
• A rules-driven or case workflow is essentially a higher-level sequential workflow.  “Rules” determine the workflow progress. They use conditions to decide if expressions are “true” or “false,” and the rules are modeled with the “if,” “then,” or “else” expressions.  Moving through a rules-driven workflow depends heavily on the constraints and/or conditions associated with the work (who, what, when, where, …) and the choices made throughout the workflow (selection from the available options to proceed).  Examples: break-fix work-orders, support tickets, insurance claims, surveys.

Note that most workflows to support field service activities are either sequential or rules-driven workflows, but state machine workflows must also be supported by the project management system.  Also, the workflow design and management component of an integrated project management system must be able to support the creation of highly efficient and effective workflows of all types.  

Workflows can be human-centric (most tasks are performed by a human) or system-centric (most tasks are performed by a machine).  Most field services require a human-centric workflow.  Human-centric workflows are more difficult to design given the need to avoid errors induced by human judgement, decision making, and mistakes.  System-centric workflows, if designed properly, should be much less error prone, require little to no quality control, and be much more reliable in their operation as long as the data used in support of the workflow is consistent in the bounds and formats expected.

The workflow engine in a project management system should “automate” the transition from one task to another and not require human intervention to continue processing of the workflow.  The project management system, with support from the workflow engine, should automatically handle notifications, reminders, triggers, transitions between representatives/systems, reports and other key transitions between major stakeholders supporting the workflow.

Some best practices in workflow design:

• Get input from all stakeholders (executive management, project management, field service representatives, QC’ers, analytics team, reporting team, client, accounting, etc.) on the key elements, goals, objectives, expected outputs and other key features of the target project.  Also, support workflow design reviews and regular workflow audits with stakeholders (or when recurrent issues are identified).
• Insure the ability to “take action on data”, e.g., data analytics, in support of maximizing productivity, exposing issues, and identifying new business opportunities.  
• Enable “ease of optimization” upon feedback from stakeholders.  Workflows must be easy to manage and change.
• Employ principles that enable a positive user experience including responsiveness, intuitive forms layout, consistency across workflow components, clarity of interface actions, and specificity of what is expected.
• All data entries should be in standard units of measure.  Drop-down menus, picklist, or “spinners” can be used to minimize the number of possible entries.  All data entries should be checked against an expected format, range, or allowable values at the time of entry.  “Free-text fields” should be used on an exception basis only (requires approval by a review committee).
• Workflow forms should be mobile friendly (given most field service data entry is performed with a mobile device).
• Target alignment with database structures, backend dash-boarding, and analysis objectives.
• Support integration and/or data compatibility with target electronic document management system.
• Represent the workflow using a visual aid, flow-chart, or flow diagram.  If the diagram becomes too complicated to understand, the design is probably also too complicated.
• When possible, split workflows into sub-flows or modules. The use of smaller, more digestible modules result in greater efficiency, quicker issue resolution, easier testing, and overall better workflow performance.  Also, a modular design enables addition or removal of new features or processes more efficiently.
• Think of workflows as non-linear processes. Workflows are designed to enable you to return to previous steps seamlessly without causing bottlenecks or lag time. 
• The use of workflow templates designed for specific types of projects and/or work-orders can help minimize the time required to implement a new field service project and allow reuse of a “known good” workflow designs.
• Make sure you can measure productivity using key points in the workflow as indicators of progress.

There are many other best practices in workflow design.  The above are just a few of the key ones identified from many years of experience.  The art of workflow design can be made more systematic by good design practices and clear understanding of a project’s goals and objectives.

Coordination

Field service projects, and their associated work assignments, often require coordination of multiple field service representatives (employees, independent contractors, gig-workers, etc.) performing related and associative tasks in parallel.  The data collected and/or created in support of performing and executing workflows often occurs while the field service representative is working offline from the company’s project management system and databases.  Offline operation is required necessary given poor connectivity in many field service locations and often requires the storage of large datasets on the field service device.  Enabling the workforce to perform work in parallel is key to minimizing the amount of time, cost, materials, and resources required to complete a project.  But this “concurrency of work” with its related transaction processing and data collection may create issues in correctness in the data representing the measurements, status, and resources associated with the project.  The project management system, the workflow engine, and the workflow design must support and take into account concurrency of activities and maintaining accuracy in the information associated with the measurements, status and resources of the project.

Critical vs. Non-Critical Operations

Workflows can be broken up into sections of “critical or dependent” operations and “non-critical or independent” operations.  Critical operations may share data objects and/or resources with other parts of the workflow, have dependencies on other operations before they can complete, and/or affect other operations in the workflow.  Non-critical operations in the workflow imply they can be performed at any time, independent of other actions in the workflow.  To avoid a “race condition” (https://en.wikipedia.org/wiki/Race_condition) and maintain correctness in the data objects and workflow operations, a property of concurrency control called “mutual exclusion” must be used.   Mutual exclusion ensures that if a section of the workflow is already performing an operation on an object (e.g., critical section) no other section of the workflow is allowed to access or modify the same object until the first operation has finished and released the object for other operations to occur.  The requirement of mutual exclusion was first identified and solved by Edsger W. Dijkstra in 1965 “Solution of a problem in concurrent programming control”, Communications of the ACM, Vol. 8, No. 9.  

Workflow Design

Enabling the ability to execute a workflow offline from the main project management or database system and using multiple field service representatives working independently and in parallel on critical sections of the workflow, makes the workflow design challenging and places special functional requirements on the workflow engine.  

• This is especially true if you also wish to minimize the time to completion (e.g., optimize efficiencies) of the project.  Serializing all tasks in a workflow is the simplest way to guarantee correctness of operation, but this may minimize the use of available resources and maximize the time to completion.  
• Another approach is to identify all critical or dependent data objects and resources in a workflow and include “triggers and checks” that make sure all dependencies or “rights of use” are met before the object is accessed or modified.  

Data Coherency

Even with a well-designed workflow, certain best practices must be followed to avoid common issues of a stalled workflow (e.g., deadlock, livelock, starvation, failure in the absence of contention), reliable operation (e.g., the system crashes or the workflow is interrupted in a critical section), and dependency management (e.g., time between syncing of offline workflow processing devices).  

• Firstly, all workflow designs should be subject to a detailed design review by all stakeholders, and made to adhere to a documented set of best practices in workflow design.  
• Other examples include fine-grain locking of critical sections/objects of a workflow should be used to guarantee data coherency in the workflow.   The data collection devices (e.g., smart phones, tablets, laptops, etc.) should be connected to the project management system and/or synced with the main database system as often as possible.  The project management system should notify the associated project manager and field service representatives anytime an assigned and active workflow has not been synced for a pre-subscribed amount of time.  A workflow must be released from a field service representative before it is reassigned, avoiding unauthorized data updates.

There are key functional requirements in the project management system, workflow engine, field service device interface, and database system to enable concurrency of operations in a workflow and ensure correctness in the data collected/created.  Enabling concurrency in a workflow can be key to maximizing efficiencies in the delivery of field services.

A successful project management system must include or integrate with an adaptive and effective quality management system.  ISO (the International Organization for Standardization, 9000:2015, https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-4:v1:en) defines a quality management system (QMS) as a set of well-defined policies, processes and procedures required for planning and execution in design, development, production, and services in business areas that can impact the organization’s ability to meet customer requirements.  Some people generically refer to a group of documents as a QMS.  But specifically, it refers to the entire system – the documents just describe it.  An effective QMS enables the organization to identify, measure, control, and improve the various core business processes that will ultimately lead to improved business performance.  To date there are few, if any, QMS that integrate the tracking and monitoring of physical services activities with advanced analytics to deliver real-time insights and actions in support of optimized field services for infrastructure systems.

Quality assurance (QA) and quality control (QC) are two key aspects of a quality management system. While some quality assurance and quality control activities are interrelated, they are inherently different. Typically, QA activities and responsibilities cover virtually all of the quality system in one fashion or another, while QC is a subset of the QA activities.

QA is defined as “part of QMS focused on providing confidence that quality requirements will be fulfilled” (https://asq.org/quality-resources/quality-assurance-vs-control).  The confidence provided by quality assurance is twofold—internally to management and externally to customers.  As a subset of QA, QC is focused on fulfilling quality requirements.  While quality assurance relates to how a process is performed or how a product is made, quality control is more the inspection or verification aspect of quality management.  Auditing and inspection can be another important part of the quality assurance function, defined as comparing actual conditions with requirements and/or expectations, and reporting those results to management and/or other organizations.

Like manufacturing systems, infrastructure systems and related field services have started to deploy technology enabled capabilities. These can support the effective implementation of advanced quality management functions.  

The first key technology enabler is the Internet of Things (IoT) with integrated sensors and controls, where each major component of an infrastructure system is connected to the internet, monitored and/or controlled, and data is collected.  Unfortunately, IoT deployments produce massive amounts of real-time data, which can be challenging for field service providers to effectively use without some advanced tools.

The second key technology enabler is analytic solutions. These solutions can provide more accurate and faster insights. Initially, raw data from IoT and modern infrastructure systems were not ready for analytics. Unfortunately, analysts must clean, extract, transfer and load (ETL) data, seriously constraining the QMS system’s ability to provide real-time controls and/or predictive services.  To address this constraint, automated data validation or checking technology must be integrated into the system, between the IoT components and analytics engine, to support collection of clean real-time data that can be correlated and effectively used in computer algorithms and analytics to produce accurate insights, responses, and reports.  

One approach to adding analytics to the management and servicing of infrastructure systems is to mash up or stack QMS solutions with analytic solutions.  Note, however, that this approach will produce a loosely coupled platform unable to support real-time controls or service activities. While this mashup may support some level of dashboarding and reporting on operations, it would not deliver the advanced and/or differentiated capabilities expected by today’s customers.

The ultimate goal is to integrate the analytics engine with the QMS so completely that neither the service provider nor the customer will even know they are using advanced analytic techniques and machine learning. This tight integration of QMS and analytic solutions will help users be more productive and accurate in their decision making and service delivery. This integration will also enable automation of reports, guides, and alerts.  Actionable information will appear in context to help make better quality decisions without having to jump to a different analytic user interface. Quality investigations and decisions will ultimately be streamlined to improve the quality of any field service delivery solution.

One of the keys to a successful field services business is the ability to produce highly informative, accurate, and comprehensive reports, guides, invoices, and other documentation that represents the work provided.   The challenges are: 1) automating the production of a varying set of services reports and documents, and 2) producing all the documentation needed for all the associated stakeholders.  Also, the complexity of the documentation can vary from simple weekly progress updates with a few line items, to detailed reports and/or design guides with hundreds of line items, including pictures, drawings, charts and graphs.  The types of documents/reports produced and/or supported by a project management system includes: 

• narratives/project descriptions
• progress reports
• workflow descriptions
• design/installation guides
• performance statistics/graphs/diagrams 
• executive summaries

 and other collections of information gathered or derived from the requested services.  Given each project and associated stakeholder drives differing requirements and points-of-interest, customization of reports and documents is necessary to satisfy a diverse and growing clientele.

There are stakeholders who need information from the project management system.  The stakeholders, and related documentation, commonly associated with field service projects are as follows (Note – most project types have similar stakeholders and related documentation): 

• Project Management Team – Progress reports are needed for tracking of project phases, milestones, spending, representative assignments, work-orders, inventory, inquiries, permits, sub-contractors, etc.  Reports that provide statistics on service delivery performance across work-orders and projects, including pending, active and completed projects will be important as well.

• Executive Team – Reports providing insights on scheduling/milestones actuals-vs-planned, spending actuals-vs-planned, projected activities, workforce allocation, project revenue/profit, and other performance metrics are needed to support decision making at the executive level.  Reports on the performance of the project managers and representatives may also be of interest to the executive team.

• Field Service Representatives – The project management system should provide each representative information into their respective work record and performance.  It also can provide insight into pending and/or future work assignments.

• Clients – Reports and documentation for a field service client often must include work-order completion and findings, design guides, list of repairs, cost of repairs, work-order response/completion time, and statistics showing weekly, quarterly and year-to-date performance.  Potential clients and “Request for Quotes/Proposals” often require data on past performance and present capacities that should be available from the project management system.

• Suppliers/Distributors – Most of the documentation and reports needed for suppliers is in support of tracking inventory changes, deliveries, orders, and future needs. 

• Marketing/Sales – The marketing and sales teams will need information to support interactions for present and potential clients.  This information may include several projects/work orders in process, completed and pending, client list, location of project actives, and project performance in specific areas of service delivery.

The project management system must be able to generate automated reports using an interface that allows the project management team to select the content and format of a report.  This will be key for reports that are periodic, e.g., weekly, monthly, quarterly, etc.  Standardized report frameworks may also be created to support high level insights into operational effectiveness and identify potential issues and/or areas of improvement.  While the project management system may be able to automate creation of most field service reports and documentation, it will need to also provide tools and facilities to create custom reports and/or guides that require the integration of information from outside data sources.  For example, the creation and integration of a CAD drawing to show a floor layout and proposed object placement may need to be completed by a separate application, but the project management system will need to support the file type, placement, and conversion to the target report format.  Finally, the project management system must provide APIs to allow stakeholders to import and export data and documentation from field service work.  

In closing, efficient and user-friendly report and document creation will be necessary in a sustainable and effective project management system.

A major element or capability of the target project management system is to provide a way to establish a viable and supportive working environment for the Field Service Representative.  Enabling a culture of community, inclusion, empowerment, ownership, growth, opportunity, impact and accomplishment will be important to sustain a high performance and highly satisfied gig-workforce.  To date few if any project management systems provide this capability.

Key features and functions of a project management system in support of a field service gig-workforce:

• Open, honest, and constructive feedback and communications among representatives and between project managers and representatives.
• Social recognition and community celebration of impactful ideas, project accomplishments/major milestones, and career milestones.
• Allow representatives to establish a “collective voice” and build a sense of community with their peers.
• Enables due process and input on decisions affecting representatives and employees.
• Clearly defines tasks and any known risk associated with the execution of a work-order.
• Provides details of the amount paid for completion of each task associated with a work-order, and the right for a representative to choose which work-orders and tasks they wish to support.
• Provide access to training and certificate resources to advance the skills of the representatives.

One of the keys to establishing a sustainable, inviting, quality minded, and innovative culture in a gig-workforce is to enable and encourage the sharing of ideas among peers and with management on how best to improve efficiencies, complete a task, reduce cost, and/or make changes in processes, workflows, methodologies, and other company operations.  Establishing a cultural norm can be difficult, especially with a highly distributed and dynamic workforce.  But establishing the right culture and empowering the workforce will be necessary to sustain efficient operation of a field services business using a gig-workforce.

One of the emerging areas important for any interface between a business and its workforce is the provision for corporate social responsibility to the representatives, their families, and the environment.  This capability can also be an important attribute for the client, allowing companies to express how their projects support society and the advancement of the community.

An effective project management system that support a gig-workforce must provide real-time access to job opportunities and allows representatives to express their interest, request they be assigned, and/or accept assignments to a particular project or work-order.  The representative’s profile carried in the system will contain information on their skills, interest, and estimated amount of work they are seeking.  The system should also provide an environment for representatives to document their skills, accomplishments, completed assignments, productivity, and other key measures of their capabilities and interest (often referred to as a ranking and reputation system).  This documentation cannot only be leveraged by the field services company but helps the representative to easily accumulate and share their experiences and skills with other companies.  The system will allow the capability of sharing representative’s information with clients, similar to a LinkedIn platform.

Finally, the project management system must provide a means for the representative to do long-range planning of their work commitments.  It will give the representative access to a public calendar and a private calendar to help them schedule their commitments, 

One goal of the system is to support the concept of the “economics of mutuality” where every entity in the supply chain receives a fair return on their investment of time and money, including clients, distributors, workers, manufacturers, and innovators. (e.g. greater transparency in the production networks).  In support of this, the system must consider support of the five principles of “fair work” in the gig economy (created by the Fairwork Project convening at the International Labour Organization meeting in Geneva): fair pay, fair conditions, fair contracts, fair governance, and fair representation (https://fair.work/en/fw/principles/fairwork-principles-gig-work/ ).  With support of these principles, the project management system will establish a viable and sustainable business environment for everyone involved.

As stated previously, the project management system architecture needed to support associative management of structured and unstructured data gathered in support of infrastructure projects must consist of three main parts: (1) data harvesting subsystem, (2) data storage subsystem, and (3) data analysis subsystem.  There are many approaches one could consider in implementing these three subsystems and how they interface to each other.  From our evaluation of present and future requirements for managing infrastructure projects using a gig-workforce, we have chosen a system architecture and related technologies to support the “data system” for the platform.  The following provides a high-level description of the primary subsystem components to support the platform’s data system.

Key system technologies and/or structures targeted to support managing data and information include:

Open Data Format (ODF – http://www.opengroup.org/iot/odf/ ) – The ODF is specified using XML Schema. It defines a simple and extensible ontology for data storage that allows the creation of information structures that are similar to those of objects and properties in object-oriented programming. It is thereby generic enough for the representation of any object and information needed for information exchange in domains such as physical infrastructure.

Structured Query Language Relational Database (SQL – https://en.wikipedia.org/wiki/SQL ) – Primarily used for management, transaction processing, queries and analysis of structured data with tabular relations.  Most of the data gathered while completing a workflow document or form will be stored in a relational database.  Companies like IBM, Oracle, Microsoft, SAP, Teradata, and many others have SQL database environments.  Often the best database software to use is driven by a company’s existing data and their data system.  We will not make a specific recommendation at this time relative to which SQL database system would be best.

NoSQL (originally referring to “non-SQL” – https://en.wikipedia.org/wiki/NoSQL ) – A database structure which provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases (e.g. SQL).  The data structure options or classifications for NoSQL databases include key–value pair, wide column, graph, or document.  The proposed data structure for unstructured data is a “document” store given its ability to integrate well with SQL databases and associative queries.  A document store assumes that documents encapsulate and encode data (or information) in some standard formats or encodings. Documents are addressed in the database via a unique key that represents that document. Another defining characteristic of a document-oriented database is an API or query language to retrieve documents based on their contents.

An example of a viable NoSQL database is MongoDB (https://www.mongodb.com/), a cross-platform document-oriented NoSQL database program. MongoDB uses JSON-like documents with optional schemas. It provides high performance, high availability, and easy scalability.  MongoDB is developed by MongoDB Inc. and licensed under the Server Side Public License (SSPL).

Hadoop (https://en.wikipedia.org/wiki/Apache_Hadoop) – An open source big data framework from the Apache Software Foundation designed to handle huge amounts of data on clusters of servers. Hadoop is a general-purpose form of distributed processing that has a distributed file system (HDFS), a scheduler that coordinates application runtimes (YARN), and an algorithm that actually processes the data in parallel (e.g. MapReduce and Spark).  

Apache Spark (https://en.wikipedia.org/wiki/Apache_Spark) – A data processing framework that can quickly perform processing tasks (e.g. machine learning) on very large data sets, and can also distribute data processing tasks across multiple computers, either on its own or in tandem with other distributed computing tools.  Spark has become the framework of choice when processing big data, overtaking the old MapReduce paradigm that brought Hadoop to prominence.  The advantages of the Spark framework include speed and its APIs.

Our primary goal in this system architecture is to provide the necessary functionality, flexibility and scale in support of effective use and association across data types needed to support value creation in an infrastructure focused project management system.  We believe the proposed structure will work.