Outsourcing vs product company: where CMMI actually differs

Two types of company side by side: one table to see where the paths split

Start with the whole picture. The way to use this table is not to memorise it, but to hold it against your own company: whichever column describes you more closely is where the preparation weight belongs. In reality plenty of companies are hybrids — an outsourcing company that later built its own product, or a product company that takes custom work to keep the team fed. A hybrid cannot copy a whole column; it has to judge row by row, especially the row on project boundary: inside one company, the two business lines may mean two different things by "project".

1. Project boundary and estimation: contract scope, or release scope

This section is where the two paths fork. Every difference after it — how requirements are managed, how assets are built, which measures are chosen — is derived from here. Get the boundary wrong and the evidence chain is crooked from the first link.

Outsourcing: the project is a contract

An outsourcing company's "project" usually has a strong external definition: the customer has a tender document, a contract, a statement of work, acceptance criteria, and often its own naming habits for milestones. That brings a convenience — the boundary needs no explaining; and a constraint — the right to interpret the boundary is not entirely yours.

What has to be done:

• Break the contract into a manageable structure. The phases, deliverable list and acceptance conditions in the contract have to map onto the internal project phases and work products. Many outsourcing records break precisely here: the contract is split into "phase one, phase two" while the inside is split into "design, development, test", the two vocabularies do not line up, and a sample finds no correspondence.
• An estimate needs a basis, not a quotation worked backwards. A bid estimate should state at least four things: size (function points, modules, interfaces, in whatever counting convention you use), a judgement of complexity and reuse, the assumptions (what the customer provides, and when), and historical reference (which projects of this kind you have done, and how far off they were). Without the assumptions, the estimate is, at assessment, one sentence: "we quoted from experience".
• A change has to move three sides together. When scope changes, schedule, cost and staffing have to be adjusted with it; adjust one side only and the rest is repaid in overtime or in a reduced delivery. The change order has to show an impact analysis section, not just a customer signature.
• With several customers in parallel, project master data has to be consistent. The same project must carry the same name and number in the contract ledger, the project initiation form, the timesheet system and the acceptance form. This is a common place where cross-checks land at assessment.

One more point is easily overlooked: in a staff-secondment project the process boundary is not in your hands. If the customer supplies the project manager, uses its own process and tools, and deliverables go straight into the customer's repository, then "this process belongs to our organisation" is hard to sustain. Such projects can be run, but they are usually not suitable as assessment samples — not because they are not projects, but because the ownership of their process evidence is unclear.

Product: the project is a release

A product company defines its own "project": what this release does, what it does not, when it ships, and how far it reaches. That sounds free, and is in fact harder — nobody draws the boundary for you, so you have to write it down and hold it.

What has to be done:

• The release scope has to be in writing. One release note stating which requirements are included, which are excluded, which external conditions it depends on, what the acceptance criteria are, and who approved it. Without it, the "project" is scattered across the records: requirements scattered in the pool, tasks scattered in the tool, and the release appearing once, in a launch announcement.
• Estimate by capacity, not by wish. Work out the effective capacity available for this release first, then load requirements into it; if they do not fit, cut scope or move the release, rather than promising features and then improvising. This is the key difference between product and outsourcing estimation: outsourcing is constrained by contract value and delivery date, product by team capacity and the market window.
• Requirements that miss the release need a destination. Back to the pool, into the next release, or explicitly closed. The common product-company pattern is "discussed but not done", neither recorded nor closed, so after a while nobody can say which items were rejected or why.
• Technical debt and stability need their own quota. If all capacity goes to business requirements, the release cadence looks fast and two quarters later the launches start going wrong. At assessment this corresponds to "was process quality built into the plan", not "is your code good".

2. Requirements management: customer change orders, or a pool and priorities

In requirements, the daily moves on the two sides are close to opposite. The outsourcing company's main battlefield is blocking — blocking scope creep, turning every addition into a change with a price; the product company's is choosing — picking what this release will do from a pile of things everyone wants, and carrying the consequence of not doing the rest.

Outsourcing: turn the verbal into a document

Outsourcing projects rarely go wrong because requirements are complex; they go wrong because requirements arrive in a form that is not a document: a sentence in a meeting, a paragraph in a chat app, a phone call from the customer's boss. Finish it and it is not a change; refuse it and someone is offended.

• The change order needs a fixed structure. Raised by, date, content, impact analysis (effort, schedule, cost, effect on what has already been delivered), conclusion (accept / reject / defer), confirmation by both sides. Only with a fixed structure can "every time, this route" be a real claim.
• Impact analysis cannot just say "some extra effort". It has to say which completed modules are affected, which tests must be re-run, and whether a milestone moves. This is the field on the change order that carries the information, and the one that gets pushed on at assessment.
• Requirement traceability has to line up across three layers. Contract clauses and statement-of-work items → requirement items → design, development tasks and test cases. Only when the three layers line up can you answer "where was this contract requirement implemented, and how was it verified".
• Customer reviews must leave an issue record. Having the customer attend the review is a natural advantage for an outsourcing company, but if the review record holds only a sign-in sheet and the word "passed", the advantage is wasted. Keep: what was raised, who owns it, when it was closed.
• Rejections need a trace too. Requirements not done and changes not accepted also need a record and a reason. At assessment, "why was this customer request not done" answered with "we were busy at the time" and answered with "we judged it outside the contract scope and explained that to the customer at a regular meeting" are two completely different states.

Product: turn "we want it" into an order

Product companies do not lack requirement sources; they lack structure. If the pool is just a list, it quickly becomes a suggestion box: anyone drops things in, nobody owns closing them.

• Requirements need a state machine. Collected → assessed → scheduled → in development → verified → closed (or parked). Every state change is recorded: who changed it, on what basis. With a state machine, "what happened to this requirement afterwards" is answerable at any time.
• Priority rules have to be written down. Value (user value, business value), cost, risk, dependencies — say at least which of the four you look at and how you compare them. The rule need not be complex, but it must be consistent: if the same kind of requirement is ranked by different standards in different releases, the data cannot be compared.
• Requirements and releases have to be searchable from both ends. From a release you can list the requirements it contains; from a requirement you can find which release implemented it. This is a link product companies often lack when they take on CMMI, because tools cut it in half by nature: requirements in one system, releases in another.
• Production feedback has to flow back. User feedback, support tickets, monitoring alerts and data anomalies all need a channel into the pool, marked with their source. Whether that channel exists decides whether "continual improvement" is evidenced at assessment or is only a slogan.
• Trade-offs need an owner. Who sets priority, who may jump the queue, and what jumping costs (which requirement is pushed out) — write it down. The more common loss of control in a product company is not "nobody decides" but "decisions have no cost": every urgent request goes in, the release scope quietly inflates, and afterwards nobody admits the scope changed.

3. Process assets: many customers and many processes, or one process across product lines

At Level 3 this section is the watershed. Level 3 requires that the organisation has one standard process, and each project generates its defined process from it through a tailoring guideline, with reasons and approvals for the tailoring. The two types of company fail at this in completely different ways: outsourcing often has no organisation level at all; product has one that nobody tailors against.

Outsourcing: fragmentation is the natural tendency

Every customer an outsourcing company takes on tends to add another set of requirements: customer A wants its own defect tool, B wants a fixed monthly metrics report, C requires its representative to sign every review, D simply sends its R&D process documents and asks you to follow them. These are real contractual obligations and cannot be ignored. So after a few years several processes coexist, and nobody can say what "our company's standard process" is.

What has to be done:

• Treat customer requirements as tailoring inputs, not as new systems. Build a "customer special requirements list", item by item: which customer, what is required, which clause of our standard process it maps to, and how the difference is handled (an added activity, a replaced template, an extra review point). The list is itself part of the organisation's process assets, and very useful explanatory material at assessment.
• The project's defined process must be generated from the tailoring guideline. A project may adjust to customer requirements, but the starting point must be the company standard process and the route must be the tailoring guideline. A project writing its own process document separately breaks the organisation-level chain.
• The common part must be held at organisation level. Estimation method, review rules, configuration management, defect severity levels, project closure conditions — these should not vary by customer. The test is simple: would this practice still hold with a different customer? If yes, it belongs at organisation level; if not, it goes on the customer difference list.
• Where several processes run in parallel, there must be a primary and a secondary. If two or more substantially different processes are genuinely needed (very different delivery forms, for example), state the applicable range and the rule for choosing, rather than letting each project pick whichever suits it.

Outsourcing companies have one further difficulty: projects for different customers run in parallel in the same department, and people are shared. The same developer follows A's process on A's project today and B's process on B's project tomorrow. That sharply raises the difficulty of training and process compliance checks: the checklist needs branches for customer differences and cannot be one form for everything.

Product: one process, easily forced onto everything

Product companies usually do have a process — R&D flow, release flow, coding standards, go-live approval; many companies have these. The problem is that the process grew around the flagship product, so applied to a new business line, to a small team, or to a maintenance release it starts to chafe, teams quietly route around it, and the process exists in name only.

What has to be done:

• Use tailoring levels instead of "each team decides". Define a few levels by delivery form or team size (a new-feature release, a maintenance release, an emergency fix, for example), each stating which activities are mandatory, which may be merged, and who approves. The levels are defined at organisation level, not decided ad hoc by the team.
• Bring release and production into the standard process. If a product company's process assets stop at "tests passed, ready to go live", they omit the segment that is specific to them — canary release, rollback, production incident handling, release comparison. That segment is exactly where a product company differs from an outsourcing company, and where assessment will look hardest.
• Differences between platform, shared services and business lines need a basis. Different product lines using different processes is reasonable, but the reasonableness has to be written down: what the difference is, which activities it shows up in, who approved it. If it cannot be written down, it is only a habit.
• Process assets have to change with the organisation. Product companies reorganise often — teams split, teams merge, stacks change. If the process assets are not updated after each change they drift away from practice, and a year later they are archive files.

4. Measurement and data: hours and acceptance, or releases and production indicators

Measurement shows the industry difference plainly. Outsourcing data is generated around contract performance — hours, schedule, acceptance; product data is generated around the release — launch, defects, availability. Neither side lacks data; what both lack is the layer that turns data into a decision.

Outsourcing: data grows in the project ledger

Outsourcing companies often have a mature measurement system already, because it serves settlement: timesheets, monthly reconciliation, milestone confirmation. The problem with that data is that it serves finance and the customer, not the process. Used directly as process measurement it produces two distortions: hours are booked by contract rather than by activity, and defects are counted by customer rather than by phase.

• The hours convention has to be decomposable. At minimum distinguish requirements, design, development, test, review, rework, pre-sales support and maintenance. With only a total, you cannot answer "how much was rework" or "is review effort related to defect counts".
• Defects have to be counted by phase and severity. Found in requirements, found in developer testing, found in system test, found at customer acceptance, found after go-live — only a phase split carries process meaning. A total only says "there were a lot of problems this quarter".
• Rework has to be recorded separately. Rework is the main leak in an outsourcing company's cost, and a commonly ignored measure. Causes need categories (unclear requirements, design defects, communication problems, customer change, environment) — and only after categorising is there somewhere for improvement to land.
• Schedule variance needs one calculation rule. Milestone-based or completed-quantity based, it must be the same across the company. A project that is "eighty per cent done" in the weekly report and "two weeks late" in the monthly meeting is very hard to explain on site.
• Acceptance and customer feedback have to be structured. First-time acceptance, the number and type of issues raised at acceptance, and satisfaction survey results can all be measured, but with a fixed convention.

Product: data grows in the pipeline and in monitoring

The product company's advantage is that data is generated automatically: commits, builds, deployments, defects, alerts, instrumentation. The advantage brings a false step — assuming that having data means having measurement. Hundreds of charts in a tool that nobody uses to judge a release are a dashboard, not a measurement system.

• Requirement lead time has to be computable. Time from entry into the pool to go-live, computed separately by type (new feature, improvement, defect fix). This is the hard indicator of whether iteration is fast, and more reliable than "we ship every two weeks".
• Release indicators have to be read as a group. Release frequency, failed releases and rollbacks, and defects appearing shortly after a release — the three together are what means something. Frequency alone encourages shipping often and shipping badly.
• Production quality has to be traceable to a release. Classify defects by where they were found (internal test, canary, full rollout, customer report) and trace which release introduced them. The proportion of defects that escape to production is a direct reflection of a product company's process capability.
• Fix the convention and do not change it midway. If the calculation for a measure changes, mark where the old and new conventions divide. Product teams change quickly and a new person with a new calculation is common; the result is that historical data cannot be joined up and no baseline can be built.
• At least one data set has to be used for decisions. The test is plain: when did you last change a plan, cut a requirement, add people or change a process because the data was bad? If you cannot find such an occasion, the data is there for other people to look at.

5. Suppliers and outsourcing management: subcontracting down, or open source and cloud up

Here the shape of the risk differs. An outsourcing company manages the layer it subcontracts downwards — is the subcontractor's work sound, does its process keep up; a product company manages the layer it depends on upwards — when an open source component, a cloud service or a third-party API changes, does the release plan keep up.

Outsourcing: pull the subcontractor's process into this project

Subcontracting is common in outsourcing: when capacity is short work goes to a partner team, a specific stack goes to a specialist, a non-core module is bought whole. The problem is that the subcontractor delivers a result while the assessment looks at a process. If the subcontractor hands over a module that runs, with no review record, no test record and no configuration baseline, that module is a hole in the project's evidence chain.

• Subcontractors need a register and a capability assessment. Who can do what, what they have done, how they were rated — in a ledger; do not go looking from scratch each time for the same kind of subcontract.
• The subcontract agreement has to state process requirements. Deliverable list, how reviews are attended, defect handling and regression requirements, configuration and version delivery format, confidentiality and IP, reporting frequency. These clauses are a nuisance at signature and the main basis when something goes wrong.
• The subcontractor's schedule and quality have to be tracked inside this project. Not just "did it deliver", but its plan, its defects, its changes. If the weekly report says only "the subcontractor is progressing normally", it is not being managed.
• Seconded staff need dual management. They sit at the customer site and work to the customer's process, but the employment relationship, capability assessment and training records are at your company. Their project role appointment has to be clear: what they do on this project, to whom they report, who rates them.
• Customer-nominated subcontractors need a separate note. In some projects the customer nominates the subcontractor and sets the process requirements. Record it: who nominated them, where the process requirements come from, what tracking you did. "It was not our choice" is not a reason for having no record.

Product: a dependency change is a plan change

A product company's external dependencies are not, for the larger part, people but things: open source components, cloud services, third-party SDKs, payment and push channels, app store review rules. Day to day these need no attention; when one fails, the impact is at release level.

• The dependency list needs an owner. Which components, which versions, which licences, who brought them in, where they are used. This list is needed for security compliance and equally for process management — when a vulnerability appears, can you locate the impact immediately?
• Vulnerabilities and upgrades need a decision route. When a component vulnerability is found: who assesses it, within what time a decision is made, which releases an upgrade affects, and whether a patch release is issued. Write the route down, so it does not become a meeting every time.
• Cloud services and third-party APIs need a degradation plan. Four cases — the other side unavailable, rate-limited, changing the interface, raising the price — and how each is handled. The same risk exists in outsourcing projects, but it is more concentrated in product companies, because one service is shared by several product lines.
• Bought-in and custom development has to be managed as a project. Product companies also buy modules or commission custom work. That part needs acceptance criteria and acceptance records; being "an internal product" is not a reason to skip acceptance.
• Changes in distribution channel rules have to enter the plan. App store review requirements, privacy policy requirements and tightening API permissions all affect a release. If such external changes never enter release risk assessment, the reason for a delayed launch can never be explained.

6. People and training: a team that arrives and leaves, or long-lived teams and succession

In people, the management rhythm is completely different. Outsourcing lets the project rhythm carry the people — hire when a project comes, disperse when it ends; product lets the team rhythm carry the project — people are relatively stable and the product line persists. That difference feeds straight into training design, role appointments and the way knowledge is retained.

Outsourcing: the ability to backfill fast

Movement in an outsourcing company has external causes: a contract ends, a customer asks for a replacement, people are redeployed between projects. That means training's goal is not to grow experts but to get a new joiner working to the process within a controlled time.

• Role appointments are issued per project. Each project's project manager, requirements, development, test and configuration management roles need written appointment, consistent with who actually does the work. A mid-project replacement needs a change record, not a message in a group chat.
• The handover checklist has to be fixed. Code, documents, the customer's contact, open issues, items awaiting confirmation, environments and accounts. A rough handover means the next person starts from scratch, and the process record over that period is usually empty.
• Training has three parts. Company level (process, tools, quality requirements), customer level (this customer's special requirements, communication habits, delivery format), project level (this project's business and technology). The customer level is usually the one that gets skipped, and the one that causes trouble.
• Key roles need a backup. Project manager, configuration manager, customer contact — each with a named backup. Not for the assessment's benefit, but because dense project handovers make it a practical necessity.
• Shared staff across projects need boundaries. One person on three projects at once: how hours are split, who sets task priority, who to go to when something goes wrong — all in the plan, or all three projects' tracking records will be distorted.

Product: succession matters more than headcount

A product company's risk is not "people leave and the project breaks" but "people leave and nobody understands this part". If one core module is known to one person, that person's two weeks of leave delays a release; their departure means three months of reading code for the successor.

• Build a capability matrix by product line. Modules or technical domains on one axis, people on the other, marked in three bands: can own independently, can contribute, does not know. The point of the matrix is to expose single points, not to make a handsome table.
• Key modules need a second person who can take over. Not two people doing the same work, but someone besides the owner who can change it, ship it and handle production issues. In the plan that means rotation, pairing and shared code reading.
• Training has three layers. General onboarding (company, process, tools), product-specific (business, architecture, domain knowledge), process and tools (estimation, review, release, defect handling). What product companies usually lack is the second layer — business knowledge passed on by word of mouth, new joiners carried along by whoever is free.
• Technical grades should be tied to process roles. Who may be a reviewer, who may approve a release, who may review an estimate should correspond to capability and experience, rather than whoever is available. Only then does a review carry weight and stop being a formality.
• Knowledge has to settle into documents and code. Design decisions, definitions of conventions, operations manuals, common failure handling — if these are not in documents they exist only in memory. Product companies' process assets are often empty because knowledge was never written down at all.

7. Where an assessment interview tends to push

The logic is the same: follow one chain through scope — plan — execution — measurement — improvement and see whether it runs all the way, and whether the people who did the work can say why they did it that way. But what gets pulled out is completely different between the two types of company.

What outsourcing companies get pushed on

• Was the project sampled one we took on and led the process for, or was it staff secondment with the process defined by the customer?
• Are the contracting party, the executing entity and the employer of the people being interviewed the same entity? How is the cross-entity part explained?
• For a review the customer attended, can you produce the issue list and closure records — or only a sign-in sheet and "passed"?
• Do contract changes line up with project plan changes? After the change, were the test scope and acceptance criteria updated?
• Several customers' processes differ — is there a tailoring statement and approval for the differences? Which document is your own standard process?
• Does the acceptance form carry only a signature? Were the issues raised at acceptance closed out?
• Where are the process records for the subcontracted part? When was the subcontractor rated, and on what basis?
• Do the hours data and the planned effort in the project plan reconcile? How is a large gap explained?

What product companies get pushed on

• Who approved the release scope? Were dropped requirements recorded, and with what reason?
• "We iterate fast" — fast according to what data? When was the convention set, and did it change midway?
• Which activities did this release skip (review, test, canary)? Tailored against which clause, approved by whom?
• How do production issues flow back into the requirement pool and into process improvement? Is there one complete example?
• Do release records line up with the tags in the version repository? Who approved the release, and on what basis?
• Several product lines share one process — where do they differ, and what were the differences tailored against?
• Requirements that have sat in the pool for a long time — who decided not to do them? Is there a periodic clean-up mechanism?
• What is the backup situation for key modules? Are handovers recorded?

The skeleton both types of company share

Having set out the differences, the shared part has to be stated too — it does not need to be rebuilt per industry, and it would not fail because the industry is different. The model asks the same thing of both: that the organisation's way of working has been defined, performed, measured, checked and improved.

The framework is one set: organisational unit and assessment scope definition; process assets (policy, process, templates, checklists, tailoring guideline, role responsibilities, measurement definitions), each with a version, an effective date and a maintainer; the project's defined process and tailoring approval; planning, estimation and execution monitoring; requirements and change control; review and verification; configuration management and baselines; measurement collection and organisation-level aggregation; process compliance checks and nonconformity closure; training and competence; root cause analysis and improvement mechanisms; senior sponsorship and governance. Level names are Level 1 Initial, Level 2 Managed, Level 3 Defined, Level 4 Quantitatively Managed and Level 5 Optimizing, and what each one means is set out in CMMI Levels 1–5, one by one.

Three kinds of content can be shared outright:

• The document skeleton: the four-layer structure of policy — process — work instruction — templates and records, with numbering rules, approval, distribution, version control and retention periods.
• Management actions: internal-audit-style process compliance checks, nonconformity reports and corrective action verification, management review inputs, outputs and minutes, corrective action tracking.
• The generic project loop: estimate — plan — track — variance — correct — close. The loop is word for word the same in both industries; only what "variance" means differs (delivery date and cost in outsourcing, release scope and quality in product).

What cannot be shared is only the professional core: the contract and change structure, the customer process difference list, and subcontracting and secondment management on the outsourcing side; the requirement pool and release structure, release and production data, and dependencies and distribution channels on the product side. In other words, the skeleton is the same; the boundaries, evidence and data filled into it are not.

The level each type of company usually sits at is worth stating too: outsourcing companies often stop at Level 2, because project types vary widely, customers define the process and there is little reuse of the same kind. Product companies tend to assume they are already at Level 3, because "we have one unified R&D process" — but unified is not the same as defined; there still has to be a tailoring guideline, tailoring approvals and measurement that can be aggregated at organisation level. For what Level 3 preparation actually involves, see CMMI Level 3 assessment: what to prepare.

A company also running ISO 27001 or ISO 20000 can run document control, internal audit, management review, training and supplier evaluation jointly, but note: system documents cannot stand in as CMMI process assets, and project process records cannot be shared either — one checks how controls are implemented, the other checks how projects run. There are also comparable models such as CSMM; for how the positioning differs see CSMM's five levels, one by one and the CSMM entry; for how to choose between the systems see ITSS / CMMI / DCMM / CSMM: how to choose.

Common misconceptions: one "assumption" on each side

Outsourcing: assuming that "a process per customer" is flexibility. This is one of the costlier misjudgements in outsourcing projects. Several processes are genuinely flexible in delivery, but on site the first question is usually "which document is your company's standard process", and with no answer, Level 3 is out of reach. The internal trouble is worse: new project managers learn by asking people, process compliance checks have no common basis, measurement conventions differ per customer, and in the end you cannot compare your own projects. The right move is not to abolish customer differences but to turn them into tailoring — one standard process, plus a customer special requirements list, plus a tailoring statement and approval for each project. The flexibility is still there, but it is on the record.

Product: assuming that "fast iteration" equals process maturity. A release every two weeks sounds more advanced than project-based outsourcing, but assessment does not look at cadence; it looks at whether the work is repeatable and verifiable. If the release scope is not written down, requirement trade-offs are not recorded, reviews are a few lines in a group chat, a launch has no baseline and production issues do not flow back, then however fast the cadence, process capability stays at a low level — fast only means well rehearsed, not well controlled. And that kind of fast usually has a price: technical debt piling up, production issues recurring, and disruption the moment a core person leaves. In a genuinely mature product company, fast is a result, not a justification.

A few more misconceptions common to both sides:

• Assuming the tool is the process. Jira, GitLab, pipelines and monitoring platforms all produce data, but a tool does not define a process. Assessment looks at the rules you apply when using the tool, not which tool you bought.
• Substituting ISO documents. ISO 9001 and ISO 27001 system documents can be reused as a skeleton, but the project's defined process, tailoring records and project measurement that CMMI asks for can only grow out of projects.
• Treating the consultant as the person who answers. Interviewees must be the people who actually do the work. A consultant who knows the work better than the staff counts against you, not for you.
• Writing the scope larger than it is. Writing "the whole company" while only one business line runs the process leaves the other line blank when sampled. Draw the scope by organisational unit and project type; smaller and real is better than larger and thin.
• Treating the assessment as the end point. The result has a validity period, and if the process stalls, records break and key people leave within it, re-assessment at expiry is close to starting over. Validity and re-assessment requirements are subject to the rules in force.
• Writing documents first and finding projects afterwards. That reverses the order and produces hard faults such as documents effective after project records, or template version numbers appearing in records as "future versions". The right order is to define the process, let projects actually run, and let records grow naturally.

Action list: do the shared part first, the fork second

The list below is ordered "shared first, fork second". The way to use it: do the items marked [Shared] first, then work through the [Outsourcing] or [Product] block for your own industry. Hybrid companies need both blocks, ordered by the share of business; if the two business lines share the same people, doing the shared items first pays off more.

• ⬜SharedSet the scope: write in one sentence the organisational units, businesses and project types the assessment covers, and confirm for each "there are people, there are records, there are process traces"
• ⬜SharedSet the people: one lead who can move people across departments, plus the actual holders of the process improvement, QA, configuration management and measurement roles
• ⬜SharedSet the level: the target level follows the customer's or the tender document's wording, not industry habit, and not what peers happen to be doing
• ⬜SharedTake stock of projects: list candidate projects and keep only those the company really took on, led the process for, and can evidence completely
• ⬜SharedBuild the assets: standard process, templates, checklists, tailoring guideline and measurement definitions — all five with a version, an effective date and a maintainer
• ⬜SharedRun the records: pick a few real projects and run them on the new process for a stretch, so review, change, baseline and measurement records grow into a chain
• ⬜SharedRun the checks: one round of process compliance checks with nonconformities closed out; a management review with real inputs and conclusions
• ⬜SharedAlign the numbers: project name, start and end dates, participants, size and effort — one version only, across every document
• ⬜OutsourcingScope baseline: for each sampled project, contract scope, statement of work and internal plan reconcile, and a change moves all three sides together
• ⬜OutsourcingChange ledger: all change orders in one ledger, with impact analysis and customer confirmation; rejected changes are registered too
• ⬜OutsourcingCustomer requirements list: per customer, the special requirements, which clause of the standard process each maps to, and how the difference is handled
• ⬜OutsourcingReview quality: customer reviews leave an issue list, owners and closure dates; no "sign-in sheet and passed"
• ⬜OutsourcingSubcontracting and secondment: subcontract agreements carry process requirements, subcontractor schedule and defects are tracked in this project, seconded staff have written role appointments
• ⬜OutsourcingHours convention: decomposable by activity (requirements, design, development, test, review, rework), with rework counted separately and causes categorised
• ⬜ProductRelease scope: each sampled release has a scope statement covering what is in, what is out, the acceptance criteria and the approver
• ⬜ProductPool rules: the state machine runs, priority rules are written down, and requirements not done have a clear destination and a reason
• ⬜ProductRelease and production: release approval, canary, rollback and production incident handling — all four in the standard process, with records
• ⬜ProductMeasurement conventions: lead time, release quality and production defects with fixed conventions; historical data joins up; no changing the calculation midway
• ⬜ProductDependency list: open source components, cloud services and third-party APIs have an owner; vulnerabilities and service withdrawal have a decision route and a degradation plan
• ⬜ProductCapability matrix: key modules have a second person who can take over independently, handovers and mentoring are recorded, and single points are exposed
• ⬜SharedSelf-test: walk three chains for your own industry, using only existing material, with nothing added verbally
• ⬜SharedAsk the appraising party: scope, the basis for the projects in scope, evidence requirements and scheduling are subject to the Lead Appraiser's current requirements

Putting the two types of company side by side, the conclusion is plain: CMMI never checks whether you own a set of R&D process documents, but whether the way you produce work can be taken over by someone else, explained by data, and improved continuously. An outsourcing company answering that question finds the evidence in contracts, change orders and acceptance records; a product company answering the same question finds it in the requirement pool, release records and production data. Work out what the boundary of your own "project" actually is, and the preparation will not start from the wrong sample, and will not be stopped on site by a single "so who defined this scope".

▍Not sure how to draw your project boundary, or which projects suit sampling? Leave a comment noting "industry comparison", send us your main business, delivery form and team structure, and we will send back a project boundary and evidence-shape comparison for your industry.