Context-aware translation drafts. Original English remains available.
Russian celebrates Daria and Adémidé’s family heritage; Igbo celebrates Lékan’s maternal roots.
Translation notes & sourcesSuggest a correction ↗SELECTED WORK / BA CAPABILITY / DATA ASSETS
A substantial inventory of operational records and reusable knowledge helped make demand, delivery, skills and feedback more visible. Here is what each asset could support—and where an analytical idea still needed validation.
The inventory uses “datasets” broadly. Resource and activity trackers captured operational information; the feedback bank and skills assessment carried sensitive people data; the persona playbook, community log and service catalogue were structured knowledge assets. They should not all be treated as interchangeable training data.
Together, they gave the Business Analysis Capability a way to ask better questions: where demand was rising, which work consumed capacity, what skills needed support, what service patterns kept recurring and which measures could guide a decision. The source document also proposed dashboards, data links and machine learning use cases. Those proposals require clean definitions, permission, fairness checks and real-world evaluation before any operational claim.
Publication boundary: I hold the inventory document privately. The underlying workplace spreadsheets, raw records and staff-level data are not part of this website or offered for download.
01 / THE INVENTORY
Eight connected assets are described at category level. Each had a different decision role and a different limit.
A resource planner brought together formal requests, informal demand, assignments, availability and future projects. Its tabs supported a view of workload, capacity and timing across the portfolio.
Decision: Prioritise work and discuss capacity with context. Automated demand forecasts and analyst matching were proposed opportunities, not verified production systems.
A KPI and metrics tracker described activities, techniques and contributions across delivery stages, alongside selected stakeholder feedback. It offered a basis for understanding the service mix and improving reporting.
Decision: Review where analysis effort went and what evidence accompanied it. A dashboard or predictive measure would need consistent capture and a defensible definition of value.
An assessment recorded levels of experience across analysis techniques and highlighted areas for coaching or training. This was a developmental source, with individual results belonging in a restricted setting.
Decision: Plan learning with the analyst, not automate judgments about a person. The inventory’s personalised training and role-suitability ideas remained proposals.
A shared log captured discussion topics, methods, resources and lessons from recurring analyst sessions. It helped learning survive beyond one meeting or project.
Decision: Find reusable patterns and choose the next learning topic. Automated classification of the knowledge base was a possible enhancement, not a measured outcome.
A feedback bank recorded appreciation from stakeholders and examples of work valued by them. The source is real but selective: praise is not a complete or fair measure of individual performance.
Decision: Identify themes for learning and recognition with human review. See the bounded feedback analysis ↗
The playbook organised user groups, needs, touchpoints and service pain points so analysts could test assumptions about a journey. Its value was in maintaining a shared, reviewable picture of experience.
Decision: Focus service discovery and check who may be overlooked. It is not evidence that individual behaviour was predicted or that a personal-data model was deployed.
Collaborative-platform support records, usage and licence information raised questions about access, assistance and renewal. Operational exports also informed a separate, restricted analysis of software use.
Decision: Investigate underuse and offer support before changing access. See the software licence case ↗
Analysis activities were mapped to delivery stages, with techniques, outputs, effort and complexity cues. This is a structured reference and scoping tool, not a log of measured project outcomes.
Decision: Agree the right level of analysis for a project. Linking catalogue activities to historical effort and outcomes was an analytical possibility that needed dependable records.
The August 2024 requirements draft introduced data owners, source and destination mapping, quality, migration, privacy and test cases into BA discovery. The July 2025 delivery strategy applied this to four service contexts; the portfolio-tool requirements described how manually maintained requests, allocations, activities and feedback might one day be reconciled in a common view. These were design and governance milestones, with project-level techniques used where appropriate; the proposed consolidation was not a live predictive platform.
A defensible analysis starts with a question such as “Where is demand outstripping capacity?” It then checks whether requests and allocations share dates, definitions and permissions. Only after that could an aggregate trend or forecast support a manager’s decision, with the people affected able to explain exceptions. See how the consultancy developed ↗
A responsible next step would first reconcile identifiers, time periods, definitions and access rights, then use a small set of questions to test whether a joined view improves a real decision. Dashboards or predictive methods can follow only when the data is reliable enough and the people affected understand the purpose and can challenge an interpretation.
That matters most for allocation, skills and feedback: a high utilisation figure may conceal overload; a positive-feedback log misses unrecorded work; a skills score cannot stand alone as a staffing verdict. I treat the inventory as a foundation for decision intelligence, with proposals and delivered analyses labelled separately.
My supporting Python code and notebooks for selected applied studies are privately stored and maintained by me. I’m happy to answer questions about the methods, safeguards and evidence limits.
DEMAND / CAPABILITY / CONTEXT
A useful request record captures the problem, affected service, stage, expected effort, timing, required skills, dependencies and allocation rationale. I used this kind of structure to support resourcing conversations across a varied change portfolio.
A workload total cannot explain whether the right expertise is available at the right moment. Review project context, analyst support needs and changing demand with the people involved. Skill development is a coaching conversation, not an automatic score or a public performance ranking. Individual allocations and capability assessments remain private.
Explore Business Analysis & Consultancy Foundations · Try the Evidence Chain Studio
EXTERNAL RESOURCES / GLOBAL BA STANDARDS
Use these references to connect data requirements and analytical techniques with stakeholder needs and measurable business value.
IIBA · BABOK® Guide, Version 3 — a globally recognized professional standard for business analysis, covering knowledge areas, tasks, competencies and techniques.
IIBA · The Business Analysis Standard offers a concise foundation and a free PDF through IIBA. It is a separate, updated resource—not a new numbered edition of BABOK.
BABOK v3 corrections and errata · IIBA KnowledgeHub
Edition check: 9 October 2026. IIBA’s current resources continue to identify BABOK v3. Access the full guide through IIBA’s membership or purchase options. These links support independent learning; they do not imply IIBA endorsement or certification of this site or its tools.
These public workbenches organise inputs through authored rules, templates and calculations. A generated worksheet is a draft to review, not an autonomous consultant.
Number of concepts in this guide, not performance or usage measures.
11 concepts shown
On small screens, scroll the table sideways. “Learning context” explains a related idea; it does not mean that method runs on this page. Deep learning is the standard term for “deep ML”.
| Technical term | Technical description / definition | In plain English | How this page uses it |
|---|---|---|---|
| Rule-based logicAlgorithm | Explicit authored conditions map inputs to outputs without fitting parameters from training examples.Primary reference ↗ | A transparent set of if-this-then-that instructions. | Running here Browser controls select authored methods and structure the visitor’s inputs; they do not train a model. |
| Data science pipelineData Science Pipeline | An ordered, reproducible sequence for acquiring, validating, preparing, analysing and evaluating data.Primary reference ↗ | A chain from a question and source to an answer someone can check. | Method guide The workflow connects evidence, analysis, a proposed action and an accountable reviewer. |
| Visual encodingVisualisation | Mapping values or categories to marks, position, length, colour and labels.Primary reference ↗ | Make the comparison visible, with a scale and a clear label. | Running here Diagrams and summaries represent entered information or labelled illustrative examples. |
| Data quality checksData Science Pipeline | Validation of completeness, allowed values, uniqueness, types and consistency with expected constraints.Primary reference ↗ | Check missing, repeated and impossible entries before trusting a chart. | Method guide Completeness and review prompts help expose gaps; they cannot certify the underlying evidence. |
| Explanation versus causal proofEvaluation & XAI | A model explanation describes selected behaviour or contributions; it does not establish causal effects or full reliability.Primary reference ↗ | A reason for this output is useful, but it is not proof that the model is right. | Responsible use A structured output shows its method, but the visitor must check the claims and context. |
| Human oversight and consentResponsible AI | People retain appropriate review authority, permission controls and correction routes for data use and outputs.Primary reference ↗ | Keep someone able to question, correct or stop the result. | Responsible use People review and adapt drafts before any operational use. |
| Large language model (LLM)AI Capability | A language model trained on substantial data to estimate and generate token sequences from context.Primary reference ↗ | A fluent drafting partner whose statements still need checking. | Learning context An LLM can assist drafting in an approved environment; these public rule-based workbenches do not silently call one. |
| Machine learning (ML)AI Capability | Methods that estimate patterns or parameters from examples to support inference on other inputs.Primary reference ↗ | Learn a pattern from examples, then check whether it helps with new ones. | Learning context ML learns from examples. Read the page-specific methods below to see whether any model runs here. |
| Deep learningAI Capability | Machine learning using neural networks with multiple representation-learning layers.Primary reference ↗ | A layered model learns useful representations; more layers do not guarantee a better answer. | Learning context Deep learning is an AI capability, not a label for every chart. No deep model is implied by this explanation panel. |
| Natural language processing (NLP)AI Capability | Computational methods for representing, analysing or generating human language.Primary reference ↗ | Help a computer work with words, while remembering that context matters. | Learning context Text search, translation, thematic classification and generation are different language tasks; their implementation is identified separately. |
| Sentiment analysisAI Capability | A language-analysis task that estimates an expressed attitude, often as polarity or sentiment categories.Primary reference ↗ | Estimate the tone of words—not the private feelings or personality of their author. | Learning context Sentiment estimates expressed tone. It must not be confused with topic classification or a diagnosis of a person. |
No matching concepts. Choose another category or clear the search.
Olukotun Studios Ltd · Registered in England and Wales · No. 17537910
Registered office: 5 Brayford Square, London, E1 0SG, England.