Organisational Process Assets: What They Actually Include
Ask what an organisation's process assets are and you will be shown a template library. It is the visible part, it is easy to point at, and it is the least valuable thing in the category. What an organisation actually holds, if anybody has kept it, is evidence about itself: how long its own work takes, what its own suppliers do under pressure, which of its own assumptions keep turning out to be wrong.
Section 2.2.2 of The Standard for Project Management gathers these under organisational process assets, and the useful way to read the category is as a cupboard with three shelves in it, only two of which most projects ever open.
What is actually in the cupboard
How things are done here. Processes, procedures, templates, checklists, standards, the governance framework, the approval thresholds. This is the shelf everybody knows about. It is genuinely useful for a new project manager finding their footing, and it carries a specific hazard: a template completed carefully can stand in for a decision that was never taken, and the document will look correct.
What happened before. Actual costs and durations from completed work, estimating records, risk material with outcomes attached, lessons, supplier performance history, the measured yield of the last three similar jobs. This is the shelf that improves decisions, and in most organisations it is either missing, scattered, or held informally by three people who have been there a long time.
Corporate records. Contract templates and precedent, configuration and version records, the financial coding structures, retained project files. This shelf matters mainly when something goes wrong, and it is invisible until then.
The two that earn their keep
Historical actuals. An organisation that can say what its last eight comparable projects actually cost, against what they estimated, has an estimating capability that no amount of technique can substitute for. The barrier is rarely collection, because the data exists in finance systems; it is that nobody has ever put it into a form an estimator can use, so every new project starts from opinion.
Lessons that can be found. A lessons repository is worth exactly as much as its searchability at the moment somebody needs it. Lessons written as narrative at the end of a project, filed by project name, are unfindable by a person who does not know which project had the problem. Lessons written against a topic, in a sentence that states the situation and the consequence, are found by the person who is about to repeat them.
Ten years of evidence on a shelf nobody opened
A government department was estimating a programme to replace a case-handling system across several regional offices. The estimate was being built the way they usually were, from supplier indications and the judgement of two senior people, and the range was uncomfortably wide.
During assurance, a reviewer asked whether the department had done anything comparable before. It had: eleven system replacements over about ten years, each with a full financial record, each with a closure report. The reports were filed by programme name in a shared drive, the financial records sat in the finance system under codes that had changed twice, and no one had ever connected the two.
Pulling them together took a junior analyst about three weeks. What came out of it was not a magic number; it was a pattern. Across eleven programmes, the median overrun against the original estimate was thirty-one per cent, and almost all of it sat in two places: the data migration from legacy systems, which had been underestimated in nine cases out of eleven, and the time between technical completion and operational acceptance, which averaged four months against a planned six weeks in every single one.
The new programme's estimate changed accordingly, and so did its plan: the migration was scoped as its own workstream with its own assurance, and the acceptance period was planned at four months with the operational teams involved from the start. The programme completed within nine per cent of its estimate, which in that department was unprecedented.
The three weeks of analysis is now repeated annually and the pattern is maintained. The lever-arch files on the shelves still hold the old closure reports, and the bottom two shelves are still bare, because the department stopped printing them some years ago and nobody ever noticed that the record had moved.
Putting something back
Record the actuals at closure, in a form the next estimator can use. Not a narrative, but the numbers: what it cost, what it took, against what was estimated, with the two or three reasons for the difference. Twenty minutes of work, and it is the single most valuable thing a closing project can leave behind.
Write one lesson to be found. Choose the thing you most wish somebody had told you at the start, write it as a situation and a consequence, and file it against the topic rather than the project. One findable lesson outperforms a forty-page closure report by a wide margin.
Fix the template that misled you. Where a process asset caused a problem, because it asked the wrong question or omitted a step, correcting it takes an email to whoever owns it. Projects almost never do this, which is why the same template quietly misleads the next four.
For a PMP® candidate, it helps to recognise that an organisation's own history is an input to planning, so a scenario where a team is estimating from scratch inside an experienced organisation is describing an asset that exists and is not being used. A response that improves the estimating technique leaves the evidence on the shelf. Situations where the answer is already in the organisation get a thorough airing in a structured PMP exam preparation course.
There is one question worth putting to the organisation this week. What did the last three comparable projects in this organisation actually cost and how long did they actually take? If nobody can answer, the answer probably exists in the finance system, and the few days it takes to assemble it will change your estimate more than any technique you apply to it.
Interested in going further?
Most organisations are better informed than their projects behave, because the evidence is held in places that were never designed to be read. Omega's PMP® Exam Preparation works through organisational knowledge as a planning input.
Organisational process assets are described in The Standard, published with the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A083: The Four-Step Tailoring Process Explained
A019: Why Organisational Knowledge Repositories Matter
A026: How Project Managers Provide Organisational Insight
A020: Matrix, Functional or Projectised? How Structure Changes the PM’s Job
A005: PMBOK 8 Focus Areas vs Process Groups: What Changed?
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
