Operating Model & Business Processes
GreenMethod’s operating model is designed around clarity, predictability, and low cognitive load for clients.
The sales and delivery process follows a structured but adaptable flow, supported end-to-end by Odoo. Each inquiry is treated as a potential project and progresses through a defined lifecycle from initial clarification to formal project initiation.
At a high level, the process includes:
structured inquiry intake
early clarification of scope and context
qualification and alignment
formal offer creation
controlled transition into delivery
Detailed process steps, decision points, and supporting artifacts are documented in the dedicated process reference.
Odoo as the Core Business System
Odoo acts as the system of record for the commercial and operational lifecycle, including CRM activities, project and milestone tracking, client communication touchpoints, and overall status visibility.
Odoo is intentionally not used as the primary documentation repository. Project documentation is stored in a protected external location and linked to Odoo on a per-project basis.
This separation preserves documentation durability, maintains independence from any single platform, and supports continuity even as tools evolve.
Project Structure & Delivery Model
Projects follow a template-based but adaptable structure.
Upon initiation, an appropriate project template is applied, defining documentation groupings and delivery milestones. Templates are type-specific and adjusted as needed to reflect client context, supporting transparency without imposing rigid control.
Each project begins with a structured kickoff to confirm scope, review the plan, and establish communication expectations. Clients are provided with portal access for shared visibility into progress and next steps. Communication follows an agreed cadence, supported by written summaries to maintain clarity and reduce uncertainty.
Documentation & Knowledge Organization
Documentation is stored in a secure external repository and linked logically to Odoo projects.
Documentation is organized around projects rather than tools. Its structure reflects business understanding, with clear ownership defined for each documentation artefact.
Internally, GreenMethod maintains system overviews, process descriptions, project-specific documentation, business analysis artefacts, and decision and clarification records. Odoo maintains references and links to these materials rather than serving as their primary storage location.
Approval & Decision Management
Decisions and approvals are treated as documentation events rather than informal outcomes of conversation.
Key decisions are documented explicitly, approvals are recorded, and changes remain traceable over time. This prevents undocumented scope changes, reduces misaligned expectations, and avoids dependency on individual memory.
Approval logic is intentionally lightweight and applied proportionally to project size and risk.
Security Practices: Password & Access Management
GreenMethod applies structured security practices to protect access credentials, sensitive information, and internal systems. Security controls are designed to be proportionate, enforceable, and auditable.
Credential Storage
All passwords, access keys, and user credentials are stored in a dedicated, protected credential management system.
This system:
is isolated from project documentation
enforces role-based access
is accessible only to explicitly approved employees
is protected by strong authentication controls
Credentials are never stored in documentation, project tools, emails, or informal communication channels.
Multi-Factor Authentication (2FA)
Access to credential storage and critical systems requires multi-factor authentication (2FA).
This ensures that:
possession of a password alone is insufficient for access
compromised credentials do not automatically result in system access
access remains protected even in distributed or remote work scenarios
Access Control & Approval Process
Access to credentials follows a formal approval process.
Access requests must be explicitly approved
Approval is role-based and time-aware
Managers verify access requests before access is granted
To ensure continuity:
a dual-approval principle is in place
if the primary manager is unavailable, a designated secondary manager may approve access
This prevents single points of failure while maintaining accountability.
Governance Principles
Security practices are guided by the following principles:
least-privilege access
separation of documentation and secrets
explicit approval over implicit trust
traceability of access decisions
Security controls are reviewed and adjusted as operational needs evolve.
Scope and Transparency
Public descriptions of security practices are intentionally high-level.
Specific configurations, tooling details, and operational parameters are not disclosed publicly in order to preserve system integrity.
What This Demonstrates
This approach demonstrates that:
security can be structured without being obstructive
access can be controlled without creating operational bottlenecks
governance can coexist with flexibility and continuity
GreenMethod applies the same security discipline internally that it expects in regulated and security-conscious client environments.
Modeling & Executable Specifications (BDD)
GreenMethod uses visual models and diagrams selectively to support shared understanding and structured communication. In certain projects, as was our own implementation, we extend this approach by applying Behavior-Driven Development (BDD) principles to formalize behaviors and expectations in a precise, testable format.
Why BDD Is Used
For complex or behavior-driven systems, we have found that traditional static diagrams alone are insufficient to capture how systems are expected to behave in real scenarios.
In these cases, we apply a software development–inspired documentation approach using the open-source tool Cucumber to express behavior in a structured, human-readable form.
How This Is Applied
BDD artifacts are used to:
describe system behavior from a business perspective
align stakeholders on expected outcomes
complement UML and process diagrams
reduce ambiguity in requirements and acceptance criteria
Behavior descriptions are written in clear, structured language and can be understood by both technical and non-technical stakeholders.
Role of Cucumber
Cucumber is used as a documentation and specification tool, not as a mandate for automated testing.
Its purpose in this context is to:
structure behavior consistently
make assumptions explicit
provide executable-grade clarity where needed
Whether scenarios are later automated or remain as living documentation depends on the nature of the engagement.
Relationship to UML and Diagrams
UML diagrams explain structure and relationships
Process diagrams explain flow
BDD scenarios explain behavior and outcomes
Used together, they provide:
conceptual understanding
behavioral clarity
traceability between intent and implementation
No single artifact is treated as sufficient on its own.
Scope and Restraint
BDD and executable specifications are applied only when they add value.
They are not:
mandatory for every project
used to over-formalize simple systems
introduced without stakeholder alignment
This ensures that documentation remains proportionate, usable, and maintainable.
What This Demonstrates
This approach demonstrates that:
business analysis can be expressed with executable precision
documentation can bridge business intent and system behavior
modern software practices can be adapted responsibly for documentation and governance
GreenMethod applies these techniques internally and selectively in client work where behavioral clarity is critical.