Why do I need to manage Business Requirements?
And why should you...
Being an ERP integrator, it is always a challenge to gather and coordinate the business requirements of my customers during the gap analysis and then of course control them during the implementation.
Those business requirements might be overlapping, irrelevant, off-scope or they might need to be reviewed, discussed and approved by multiple stakeholders. Being able to gather them in one central environment and manage them between the different collaborators, project users and customer key users quickly becomes a necessity.
There are multiple tools to perform Project management, Document management or Requirement management. Nevertheless I was not comfortable with the idea to use one of those, as most of my business (CRM, PM, contacts, Timesheets, professional emailing) is currently managed inside Odoo. I did not want to have to build a connector or obviously have to manually duplicate information between systems.
Back in 2012, OpenERP provided an Excel table with complex links and calculations where you could actually gather all the information (customer story and functional/technical assessment) and somehow calculate the estimation for the project. This Excel sheet gave me the structure I needed for estimation management but did not solve the problem I had on knowledge management...
A first genesis
Based on this Excel example though, I wrote a first version of the concept years ago, back in version 6 with the initial idea (still true) to be able to perform within Odoo the following:
-
Collect and gather in one place the relevant Customer Stories.
-
Be able to validate the requirements.
-
Be able to link them one to each other.
-
Be able to estimate them.
-
Link the output with the project creation.
The modules ("gap_analysis"), developed in version 6 and later ported to version 7, were achieving pretty well these tasks and we used them for a while until we had to rethink the project.
The company growing up, we were facing new challenges with bigger projects and the idea of improving the original concept naturally resurfaced.
Retrospectively, the original idea aimed at the right direction but felt short in the extent of the possibilities. When I retook the project few months ago I started to think about what exactly did I want to improve with these modules:
-
The original idea of gathering customer information/approving/estimating was still the main idea.
-
Being able to quote the customer based on the BR was important.
-
Last but not least, the new underlying idea was to be able to have one object with all information to serve as a link to all purposes (quote, project timeline, project control).
Reborn!
End of 2015, I decided to bring my project to the OCA hoping I could leverage some community effort and create some positive feedback and this is how the Business Requirement repository is born.
Many contributors expressed their interest such as Jordi, Daniel or Pedro and we started the design of the new set of modules first with a rebranding ("Gap Analysis" had a too narrow definition compared to "Business Requirements") and the objective to fit a broader audience.
The first order of business was to define a clear and generic data model. Multiple discussion in github took place (for example here) in order to draft them so that over time we were sure we could cleanly extend them.
But... What is a Business Requirement?
A Business requirement is the expression of a business need by a customer or internal project user.
It might contain multiple sections or details depending on the project needs and complexity.
For the first phase of the modules, we have simplified the scope to the following:
- Customer Story: this is the requirement as expressed by the customer/stakeholder.
- Scenario: how/where the current solution can provide a suitable scenario to answer the customer story.
- Gap: For the uncovered part of the scenario, elaborate the gap/need for specific developments/setup.
- Deliverables to be provided to the customer/user.
- Resources necessary to achieve the deliverables.
- Additional information (approval, cost control, etc.).
A generic design to fit multiple industries
These modules were originally design for the service/IT industry but the requirement management process has been kept as generic as possible and can apply to many cases/industries (customer or internal projects) for which a requirement gathering and analysis is previously necessary:
- IT development or web design.
- Business Consultancy (strategy definition, advertisement, etc.)
- Construction of new building
- Trading (New product development)
- R&D Projects (Internal stakeholders needs definition)
- etc.
Full integration with current Odoo workflow
A flexible universe
The modules have been developed trying to keep them as flexible as possible so that the end users can select features based on their needs:
- Business requirements: main objects and views.
- Business Requirements Deliverables: all business requirement lines (deliverables and resources).
- Business Requirements Deliverables Cost: all prices and cost fields in order to calculate and control the gross profit of the BR along with user access control.
- Business Requirements Project: a wizard to automatically create the projects based on the resources lines.
- Business Requirements CRM: another wizard to automatically create the Sales Quotations based on the deliverable lines.
- Business Requirements Reports: several printouts for Business Requirements Documents.
So, what's next?
Looking for contributions!
We plan to improve the current set with the following features:
- Support for online quotations with a CRM wizard.
- Support for complex parenting relationship in the BR.
- Improved BI tools for BR/Deliverable/Resource.
- Integration with Earned Value report module.
