Inventory the Assets You Already Built

Task

Inventory reusable assets from consulting delivery.

Summary

Identify the templates, workflows, scripts, data, intellectual property, and reusable components hidden inside delivery.

Turn Consulting Work Into Reusable Assets

Task ID: S1-09

Consulting experience becomes a business asset only when another qualified person can find it, understand it, adapt it, and use it safely. This article explains how to inventory the templates, scripts, workflows, datasets, methods, and components hidden inside completed client work—and how to distinguish a promising file collection from a genuinely reusable delivery system.

Executive summary

Two consultants can solve nearly the same customer problem six months apart and still begin both engagements from a blank page. The first project’s interview guide is buried in email. Its analysis workbook contains confidential customer data. The final presentation shows the answer but not the reasoning. The senior consultant remembers why several exceptions were made, but nobody recorded them.

The company has experience, but it does not yet have reusable assets.

The operating principle is simple:

Do not inventory files. Inventory useful units of work that another person can apply to a future engagement without reconstructing the original consultant’s reasoning.

A credible inventory should identify the reusable core of past consulting work, separate it from customer-specific material, record ownership and restrictions, and test whether somebody other than the original creator can use it. It should cover at least the major forms of reusable material: templates, scripts, workflows, datasets, intellectual property, and components.

The working target of at least ten identified assets is a useful discovery target for this stage, not a universal benchmark. Ten weak, duplicated, inaccessible, or legally unusable files do not constitute ten reusable assets. The more useful measures are the number of candidates identified, the number prepared for controlled reuse, and the number successfully reused in a later engagement.

This inventory matters because it reveals which parts of delivery are already repeatable. Those parts may later support a clearer offer, faster onboarding, more consistent quality, lower dependence on the founder, better margins, or a standalone software product. It does not, by itself, prove that the entire consulting service should be standardized or automated.

The problem is hidden work, not missing documents

Most consulting businesses already produce a large volume of material:

• proposals and statements of work;
• discovery questionnaires and interview guides;
• workshop agendas and facilitation scripts;
• data-request lists and analysis workbooks;
• research notes, taxonomies, benchmarks, and scoring models;
• project plans, review gates, and escalation procedures;
• presentations, reports, dashboards, calculators, and implementation guides;
• code, queries, automations, configuration files, and test data;
• onboarding, handoff, support, and follow-up material.

The difficulty is that these materials were usually created to complete a specific project. They were not necessarily designed for a different employee, customer, industry, or date.

Research into service-knowledge reuse has found that companies can accumulate extensive documentation while still struggling to reuse it. Common barriers include fragmented information, missing context, uncertain reliability, poor indexing, and reports written for the original case rather than a future user. In one open case study, past service documentation was rarely reused even though it existed; employees continued to depend on senior colleagues because the available information was hard to assess and adapt.

That distinction is central:

A completed deliverable is evidence that work occurred. It is not automatically a reusable asset.

A file becomes reusable when it preserves enough of the following:

• the problem it addresses;
• the circumstances in which it applies;
• the required inputs;
• the steps or decision rules;
• the expected output;
• the places where judgment is still required;
• known exceptions and failure conditions;
• the ownership, confidentiality, and data restrictions;
• a current owner and version;
• evidence that it works beyond its original project.

The first move is therefore to identify and classify what already exists before deciding what should be created, updated, combined, or retired.

This work belongs early in a company’s development because the evidence is already present in customer delivery. The company does not need a fully packaged offer, a software platform, or a new sales channel before it begins. It does, however, need access to completed engagements and the people who performed them. “No dependency” should not be interpreted as “no evidence required.”

The inventory should answer a practical question:

Which parts of our customer work are valuable and repeated enough that the company should preserve, improve, and reuse them?

What should count as a reusable asset

A reusable asset is a discrete piece of delivery capability that can be applied to more than one appropriate engagement with less work or less risk than recreating it from scratch.

That definition excludes several things that often inflate an inventory:

• copies of the same file in several project folders;
• a customer’s completed deliverable with no reusable base template;
• a blank document that contains headings but no useful guidance;
• raw customer data that cannot legally or practically be reused;
• an undocumented spreadsheet that only its author understands;
• a process description that does not match how delivery is actually performed;
• an old asset whose underlying assumptions are no longer valid;
• a named “framework” that has never been applied consistently.

The inventory should distinguish six broad forms of asset.

Templates define a repeatable structure. Examples include a statement-of-work base, kickoff agenda, interview guide, data-request form, assessment workbook, findings report, implementation plan, or executive presentation.

Scripts prescribe or assist an action. They may be sales-discovery questions, workshop prompts, interview sequences, customer communications, database queries, code, command-line tools, automations, or support-response patterns.

Workflows describe how several tasks and roles fit together. Examples include customer qualification, project handoff, onboarding, data validation, quality review, change control, escalation, approval, and closeout.

Datasets supply structured inputs or comparison material. They may include an anonymized case library, taxonomy, benchmark table, test dataset, rules catalogue, industry classification, or configuration library. A folder of unidentified spreadsheets is not a dataset asset until its fields, origin, permitted uses, quality, and update process are understood.

Intellectual property includes proprietary methods, models, scoring logic, architectures, decision rules, and organized know-how. “Intellectual property” should not become a vague category for anything the company likes. A workflow, dataset, or script may itself be protected intellectual property; the inventory should specify what the company believes it owns, what remains confidential, and what contractual or legal basis supports that conclusion.

Reusable components are smaller building blocks that can be assembled into a larger deliverable. Examples include presentation modules, report sections, visualizations, calculator functions, code libraries, dashboard components, standard clauses, checklists, diagnostic questions, and implementation patterns.

Service-productization research supports treating professional services as combinations of clearer, repeatable elements rather than forcing an all-or-nothing choice between total customization and total standardization. Standardized modules can form a stable base while customer-specific requirements are handled through controlled configuration. The appropriate balance depends on how similar customer needs are and how much value comes from specialist judgment.

That balance creates four useful inventory decisions:

A document is also not the same thing as the routine it describes. Research on organizational routines emphasizes that routines contain both recognizable patterns and variation in how people perform them. They can support stability while continuing to change through use. A consulting inventory should therefore preserve decision boundaries and exceptions rather than pretending that every expert action can be reduced to a fixed checklist.

How to build the inventory from completed engagements

The most reliable approach is to work backward from actual delivery rather than asking people to brainstorm what the company “must have.”

flowchart LR
    A[Completed engagements] --> B[Collect files and interview delivery staff]
    B --> C[Split projects into reusable units]
    C --> D{Can another person use it safely?}
    D -->|Not yet| E[Clean, explain, separate, or reject]
    D -->|Yes| F[Test on another engagement or realistic case]
    E --> F
    F --> G[Ready and proven asset inventory]
    G --> H[Standardize, modularize, automate, or retain]

Text description: inspect completed work, identify smaller reusable units, remove customer-specific or unsafe content, test whether another person can use each unit, and then decide how much further investment it deserves.

Select a useful sample of engagements

Start with a purposeful sample, not only the neatest project folder.

Include recent successful engagements, at least one difficult engagement, work led by different people, and projects that appear to address the same customer problem. Where possible, include both repeat customers and first-time customers. The purpose is to expose variation: what the company repeats, what it changes, and what goes wrong.

For a small firm, five to ten engagements may be sufficient to begin seeing patterns. A larger or more varied consultancy may need a broader sample. This is a practical sampling choice, not an industry benchmark.

For each engagement, gather material from the full delivery path:

1. initial customer problem and scope;
2. proposal, estimate, and contract;
3. sales-to-delivery handoff;
4. onboarding and data collection;
5. discovery, analysis, or configuration;
6. internal reviews and customer decisions;
7. final delivery and implementation;
8. support, follow-up, and lessons learned.

This prevents the inventory from becoming a list of polished final reports while overlooking the less visible assets that make those reports possible.

Interview the people who did the work

Files rarely reveal the whole method. Ask the delivery lead, project manager, analyst, technical contributor, and—where appropriate—the person who inherited or reviewed the work:

• Which parts did you reuse from an earlier engagement?
• Which parts did you rebuild even though they felt familiar?
• Which file saved the most time?
• Which document looked reusable but caused problems?
• Where did you need a senior person’s judgment?
• Which customer-specific sections could be removed from the common core?
• What did you wish had existed before the project began?
• What should the next team never copy without checking?
• What changed during the engagement, and why?
• Which asset would be most damaging if it disappeared with an employee?

Research in a professional-services setting found that the value of knowledge tools depended on factors such as content quality, accessibility, awareness, and relevance—not merely on whether a repository existed. The researchers also found support for completing project records before closeout and applying quality and confidentiality checks.

Do not postpone all capture until weeks after the project. Record candidates during delivery and confirm them at closeout, while decisions and exceptions remain fresh.

Decompose files into useful units

One file may contain several assets, and one asset may span several files.

A fifty-slide final presentation, for example, may contain:

• a reusable diagnostic model;
• a customer-specific data analysis;
• a standard findings narrative;
• three repeatable charts;
• a recommendation decision tree;
• an implementation roadmap template.

Conversely, a complete workshop workflow may consist of an invitation email, preparation checklist, facilitation script, digital board, scoring workbook, and follow-up template. These should be connected under one workflow record rather than counted as unrelated assets unless each component has independent value.

The service-knowledge case study noted that reuse improved when cases were indexed and divided into a clear structure such as problem description, troubleshooting, root cause, and solution. It also warned that information overload makes retrieval and review costly. For consulting work, the equivalent is to organize assets around the user’s problem and stage of work, not merely around file format or the customer that originally paid for them.

Separate the reusable core from the customer layer

Make a working copy before editing the project record. Then label each part as one of the following:

• common core: expected to remain substantially the same;
• configurable field: changes within known limits;
• customer-specific content: must be replaced;
• confidential or restricted content: must be removed or access-controlled;
• expert judgment point: requires a qualified decision;
• obsolete content: should not be reused;
• unverified assumption: requires research or testing.

The result should not be a “genericized” document stripped of everything useful. It should preserve the reasoning and instructions while removing details that belong only to the original customer.

Record enough metadata to make the asset usable

A practical inventory can begin in a spreadsheet or database. The tool matters less than the consistency of the records.

Consistent naming, versioning, ownership, and location rules are operational controls, not clerical details. Without them, teams return to personal folders, duplicate files, and private messages.

How to test and prioritize the assets

Discovery should produce candidates, not immediate declarations that everything is reusable.

Use three maturity states.

Identified candidate: The item has been found, separated from its original project, classified, and assigned an owner. Its value is plausible but not yet confirmed.

Ready asset: The item has been cleaned, documented, reviewed for legal and confidentiality concerns, placed in a controlled location, and prepared for use by an appropriate employee.

Proven asset: Somebody other than the original creator has used it on another eligible engagement or realistic test case and achieved an acceptable result without excessive explanation or rework.

This distinction protects the primary measure from becoming a vanity count. A company might report:

• 24 candidates identified;
• 13 assets ready for controlled reuse;
• 6 assets proven in a second engagement.

That is more informative than claiming to have “24 reusable assets.”

Test each high-priority candidate with a person who did not create it. Give that person the asset, its stated inputs, and a realistic task. Observe:

• how long it takes to find and understand;
• how many questions the person asks;
• whether required inputs are clear;
• whether the person can identify what must be customized;
• whether the output meets the normal quality standard;
• where incorrect or unsafe reuse is possible;
• how much expert intervention remains necessary.

A failed reuse test is valuable. It may reveal that the asset needs instructions, examples, a decision tree, a data dictionary, an exception guide, or a named expert escalation point.

NASA’s current knowledge-management approach provides a useful public example. It treats critical knowledge as context-dependent knowledge gained through experience and maintains systems and practitioner roles for its capture, storage, reuse, and sharing. It also emphasizes actionable methodologies and the active use of lessons learned, rather than treating storage as the end result.

GitLab provides a different example. Its public operating handbook is maintained as a controlled source of truth, with proposed changes, review history, named responsibility, and version control. Its published professional-services engagement process also exposes several distinct reusable assets around one customer engagement: a services calculator, statement of work, cost estimate, approval process, and delivery handoff. The lesson is not that every consultancy should copy GitLab’s tools. It is that reusable delivery capability usually spans several connected artifacts and decisions rather than one master template.

Prioritization should consider more than frequency. A useful asset-priority review asks:

• How often is the underlying task performed?
• How much employee or founder time could it save?
• Does it reduce quality variation or delivery risk?
• Does it help a less experienced employee perform safely?
• Is it relevant to the customer problem the company may build around?
• How much cleaning and adaptation does it require?
• How quickly will it become stale?
• Does it contain confidential, personal, licensed, or disputed material?
• Can it be used without removing the judgment customers are paying for?

A frequently repeated but high-risk decision may deserve a checklist and review gate rather than full automation. A rarely used proprietary model may still be strategically important. A common administrative task may be easy to automate but irrelevant to the company’s offer differentiation.

What credible evidence and measurement look like

The expected evidence is a controlled list of templates, scripts, workflows, datasets, intellectual property, and reusable components. That list should be inspectable. Each entry should have a working location, owner, status, permitted use, and evidence record.

The primary measure—reusable asset count—should therefore be reported by maturity:

The target of ten identified assets is a reasonable initial forcing function when the purpose is to make a small operating team look beyond its most obvious document. It is not evidence that ten is the right number for every firm.

The appropriate count will vary with:

• the number and age of completed engagements;
• how similar customer problems are;
• the length and complexity of delivery;
• the amount of regulated, confidential, or customer-owned material;
• the degree of customization;
• the number of employees and disciplines involved;
• whether the company sells advice, implementation, managed services, or a combination;
• the quality of the historical project records.

A specialist consultancy with three large, highly regulated projects might find eight valuable modules and hundreds of unusable documents. A mature implementation firm may identify dozens of scripts, workflows, and configuration components. The count is useful only when the unit of counting is defined consistently.

A practical completion threshold for this task is:

1. The company has inspected a representative sample of actual engagements.
2. At least ten distinct candidates have been identified, or the team has documented why the available evidence supports fewer.
3. Candidates span more than polished customer-facing deliverables.
4. Each candidate has an owner, location, intended use, and status.
5. Customer-specific and restricted material has been marked.
6. Duplicate versions have been consolidated.
7. The strongest candidates have been tested by someone other than their creator.
8. Ready and proven assets are reported separately from candidates.
9. The team can identify which repeated delivery activities still depend on undocumented senior judgment.
10. The inventory supports a clear next decision: standardize, modularize, automate, retain for reference, or leave bespoke.

At that point, the company knows more than how many files it owns. It knows which parts of its delivery capability can travel from one project and one employee to another.

Legal, ethical, and operating limits

Reusable does not mean unrestricted.

Client agreements may define who owns deliverables, background materials, custom code, data transformations, inventions, and derivative work. Employee-created and contractor-created materials may be treated differently. In the United States, for example, the Copyright Office describes “work made for hire” as work created by an employee within the scope of employment or certain specially commissioned work covered by a qualifying written agreement. The phrase should not be used as a casual assumption that all outsourced work belongs to the commissioning company. Other jurisdictions have different rules, so contracts and local legal advice matter.

Confidential know-how may qualify for trade-secret protection only when it has commercial value from being secret and the holder takes reasonable steps to keep it secret. Those measures can include restricted access and confidentiality agreements. An inventory that labels something “secret” while placing it in an unrestricted shared folder may undermine its own claim.

Customer information should also be minimized. The United Kingdom Information Commissioner’s Office summarizes the data-minimization principle as keeping personal data adequate, relevant, and limited to what is necessary, with periodic review and deletion of information no longer required. Even where that specific law does not apply, the operating practice is sound: reusable templates and test datasets should not retain names, email addresses, interview transcripts, credentials, sensitive attributes, or identifiable customer records merely because removing them is inconvenient.

Before an asset is marked ready, check:

• contractual ownership and reuse rights;
• customer confidentiality obligations;
• personal and sensitive data;
• third-party licenses;
• unattributed research, graphics, code, and benchmark data;
• employee or contractor authorship;
• security classifications and credentials;
• export, sector, or professional restrictions where relevant;
• retention and deletion requirements;
• whether generative artificial intelligence tools may process the material under company and customer policy.

Common failure modes make an inventory appear complete when it is not.

The file-dump inventory. The company lists everything in a shared drive without identifying what problem each item solves.

The duplicate count. Five customer versions of one questionnaire are counted as five assets rather than one core asset with variations.

The polished-output bias. Final presentations are inventoried while the data-validation script, review checklist, and decision rules that produced them remain hidden.

The founder-memory asset. A framework receives a name, but its decision logic still resides only in the founder’s head.

The confidentiality scrub that removes the method. The team deletes customer details but also removes examples, conditions, and explanations needed to use the asset correctly.

The false standard. A process is documented from one engagement and labelled “best practice” before its variations and exceptions have been studied.

The shelf asset. The material is well written but difficult to find, inaccessible to its intended users, or unknown outside its original team.

The orphan. Nobody owns updates, so data, references, product details, prices, and legal language become stale.

The automation leap. The company automates a repeated task before it understands when the task should not be performed or when expert review is essential.

The count-only result. The target is met, but no asset has been reused by another person.

The result of this work should be a clear view of what the consulting business already knows how to repeat. The inventory should reveal the stable core of delivery, the parts that require controlled variation, and the areas where judgment still carries the value.

Only then can the company decide what deserves further investment. Some assets should become standard internal tools. Some should become configurable modules in a repeatable offer. Some may support software. Some should remain confidential reference material. Others should be retired.

The immediate decision is narrower and more important: does the company possess enough reusable, legally usable, and tested delivery capability to stop rebuilding the same work for every customer?

Sources

Open research

• Ahmed-Kristensen, S., and Vianello, G. “A Model for Reusing Service Knowledge Based on an Empirical Case.” Research in Engineering Design, 2015.
• Govender, L., Mearns, M., and Du Plessis, T. “Knowledge Management Toolkit Enhancement for a Professional Services Firm.” South African Journal of Information Management, 2022.
• Pentland, B. T., and Feldman, M. S. “Organizational Routines as a Unit of Analysis.” Industrial and Corporate Change, 2005.
• Shamsuzzoha, A., Blomqvist, H., and Takala, J. “Service Productisation Through Standardisation and Modularisation: An Exploratory Case Study.” International Journal of Sustainable Engineering, 2023.

Primary and official sources

• NASA, “Knowledge Management.”
• GitLab, “The Importance of a Handbook-First Approach to Communication” and “GitLab Handbook Usage.”
• GitLab, “Professional Services Engagement Management.”
• U.S. Copyright Office, “Work Made for Hire” and Title 17, Chapter 2.
• World Intellectual Property Organization, “Trade Secrets” and Guide to Trade Secrets and Innovation.
• United Kingdom Information Commissioner’s Office, “Principle (c): Data Minimisation.”