Say that on the first day of kick-off the customer hands over a list of 80 requirements. The first one reads: "We want the old system, but better." Everyone in the room nods, the development team writes it all down, and goes off to build.
Three months later, at delivery, the people who do the work say: "That's not it."
Nobody lied and nobody did bad work. The problem was in the requirements from day one, and it happens more often than people think. PMI's 2014 Pulse of the Profession report found that 47% of projects that missed their goals did so because of poor requirements management.
Why a software house sees this differently
Enersys started as a software house in 2012. Our work is building software from customer briefs, not installing a package and walking away. Fourteen years of projects taught us one thing: a good requirement is not measured by how long the document is, but by whether it can be tested.
"The system must be easy to use" cannot be accepted or rejected. "Warehouse staff see stock on hand by warehouse on one screen, and the figure matches the month-end count" tells everyone exactly when the work is done.
That is what we bring to every kick-off, whether the project is custom software or an Odoo implementation.
Start from the work the business cannot stop
A list of 80 requirements usually mixes what matters with what would be nice to have. So we do not start from the list. We start by asking which work would hurt the business if it stopped for a day.
For some companies that is taking orders and shipping. For others it is month-end close, or production against plan. That work has to be designed right first, and everything else is prioritised after it.
Both sides then agree on what must be done in the first round, and what can wait.
Listen to the people who do the work, not only management
Management knows the outcome it wants, but the people on the floor know how work really flows. Documents passed through several hands lose detail: the step where someone phones another team, or the Excel file kept alongside the old system.
At kick-off, our business consultants and systems analysts talk directly with the customer's process owners. They map who the work passes through, which data it uses, and where someone must check or approve. The process owner is the same person who will sign off the tests, so they need to be there from day one.
Turn "we want" into "we can accept"
Every agreed requirement gets acceptance criteria that can be tested, before development starts.
Not testable: "The system must produce a sales report."
Testable: "The sales manager can choose a date range and branch; the report shows sales by salesperson, and the total matches the accounting report for the same month."
The second takes longer to write, but saves far more time at delivery. The customer knows before work starts what they will get, and the team knows how far to go. That is where confidence before work starts comes from.
Be clear about what is standard and what needs development
Mismatched expectations here are the most common cause of scope creep. At kick-off we sort every requirement into two groups, with a reason for each: what the system's standard features already cover, and what needs extra development.
Some items the customer expects to need development can use standard features with a small change in how people work, which is faster and easier to maintain. Others are what sets the business apart from competitors, and those deserve deliberate development.
Use Agile to confirm requirements with working software
However good the kick-off, a document is still a document. Most people only know what they really need once they see a screen and try it.
So we work in Agile rounds: plan, build and review. Customers see working software from the first round and use what they see to adjust the requirements for the next. It follows the Agile Manifesto principle that working software is the primary measure of progress.
Agile does not mean anything can change at any time. New needs that come up along the way are recorded and prioritised against existing work, and the customer decides what to swap in or out. Scope stays flexible without spiralling.
Test with near-real data, and let the process owner sign off
Before go-live we test work paths that cross departments, such as sales order to delivery to invoice, with near-real data. The customer's process owner then signs off against the acceptance criteria agreed at kick-off.
This matches the Definition of Done in the Scrum Guide: work counts as done when it meets the agreed quality measures, not when the development team says so.
The loop closes: the criteria written on day one are the ones checked on delivery day. Confidence at delivery does not come from a promise; it comes from customers checking the work themselves.
Signs your requirements are ready
- Both sides give the same answer about what must be done in the first round.
- The process owner for every core workflow has spoken with the team.
- Every first-round requirement has testable acceptance criteria.
- You know which items use standard features, which need development, and why.
- You have agreed how new needs will be handled along the way.
- You know who signs off the tests.
If you cannot tick them all yet, spend a little more time on kick-off. Time spent here is always cheaper than rework after delivery.
What Enersys does
We use this method for both custom software and Odoo ERP projects. Every project follows the same steps: reviewing the brief, designing the system, building and delivering in rounds, testing before go-live, and then supporting and extending the system. Customers always know where the project stands, who is responsible and what comes next. For more on implementation, see our seven principles for a successful Odoo implementation.
If you are starting a software or ERP project and want kick-off to produce a plan every side can accept, talk to the Enersys team.
Sources
