Structuring your Services and Subservices

How to think about the elements you need to build out projects.

In ScopeStack, there are two elements that can carry effort or price/cost in a project: Service and Subservices. We built Services and Subservices with a lot of flexibility intentionally; we realize our clients frequently need flexible options in how they think about the work they do.

Key Concepts

  • The primary portion of a service and its subordinative Subservices can independently carry effort and be associated with various resources. If you don't assign a resource to a subservice in Settings, it will inherit its parent service's resource when you add it to a project.

  • The Service and its Subservices scale independently, meaning the Service's quantity has no impact on its Subservices' quantities. For example, you may complete one (1) Service of a server rack installation that has ten (10) individual blade server installations into the track. Changing the number of server rack installations to two (2) does not necessarily mean you will install twenty (20) blade servers.

Three primary ways you can build your Services

  1. All the effort/price/cost on the Subservices: You can create a Service with no effort and add Subservices that contain all the effort to complete the top-level Service. This method gives you the most granular view of your effort

  2. All the effort/price/cost on a Service: You can assign effort to the Service with no effort on any Subservices. You can develop Subservices and use them to enumerate information into your Statement of Work. This method is helpful for the fundamental Services that an engineer can't further break down.

  3. The effort on Both Services and Subservices: This method is practical when you have a Service that requires a base amount of time regardless of the situation. That base amount of effort can be assigned to the Service, while the Subservices carry the more granular amounts of effort that may vary based on quantity.

Service Descriptions and Language Fields

Another consideration in building your services is how you need your language to appear in your document. All service-level language and all subservice-level language will be treated consistently, so if you need items to appear consistently at a certain level of hierarchy in your documents, they must be in appropriate levels of service or subservice hierarchy.

Developing your Services and Subservices

Here are some questions to think through as you determine how to build your Services and Subservices and organize them into Lines of Business and Service Types:

  • What is the minimum unit of effort in your project that scales linearly (2 elements take twice as much time as 1 of the same element)?

  • What is the most discrete element you need to describe in your Statement of Work?