Blog

– “We need a report which groups our sales by product components.”

– “And we need it broken down by cost centers.”

– “And it must show comparison with last month, quarter and year, and with budget and forecast, with indexes and trends. In linear regression.”

– “And it must let you choose if it is by posting date or by document date. Or by shipment date. Maybe some other date as well.”

– “And it must exclude returns, and include only those re-shipments that were linked to original returns in the shown period.”

And it must be a disaster if you agree to half of these.

Requirements are the easiest thing in the world. To paraphrase Archimedes: “Give me a place to stand on, and I’ll give you thousands.” However, there is no artistry in defining requirements. True art lies in focusing on those requirements that add value, and skipping the rest.

How do you know if a requirement adds value? It’s not a simple question, but there is a simple rule that can guide you any day: a requirement adds value if it is aligned with project goals.

Before you jump into defining requirements, you should define clear and measurable project goals. “We want to reduce administrative overhead in accounting by 35%” is fabulous. “We want to replace our old software” is a disaster.

Once your goals are clear, your job is much easier. If a requirement doesn’t contribute to achieving a goal, directly or indirectly, then dump it. This is equally true about both standard features and customizations. You shouldn’t strive to implement a standard feature if it won’t contribute to achieving your goals.

Customizations are especially risky when it is about adding value, because every minute you spend developing a customization actually subtracts value. You must make sure that money invested into developing something will be returned somewhere, directly or indirectly. Again, if a customization will help you achieve your goals, then it is probably legitimate.

However, customizations are often done for wrong reasons, even if they seem aligned with project goals. Processes that are perceived as complex are typical examples where customizations are made to the system, and a lot of money is spent onto a feature that doesn’t have capacity to return the investment.

One of the examples I saw was customizing a complex design-to-order manufacturing system where customer insisted on doing every single step through NAV. It was critical that design calculations were as close to actual costs as possible, so the requirement itself was legit, but there was absolutely no reason to have the design calculation functionality in the system. It’s only purpose was to feed the product cost to sales so that they can prepare a quote. Customization cost a fortune, while a simple Excel worksheet would have done better while costing a tiny fraction of the customization.

Another example I saw was a complex purchases approval scheme for a company which wanted to gain better control of the expenditures. Again a legitimate requirement. This one could have been met with standard feature, but they thought it to be too generic and basic; they needed more complexity. It could have also been handled completely outside the system, there was absolutely no reason why the approvals wouldn’t be handled on paper.

Often I’ve seen complex reporting requirements, as grotesque as the example on top of the page. Instead of developing complex, hard-coded, fixed-layout reports, spend a fraction that time in deploying a decent Business Analytics cube, deliver a half-day training in using it, and while the users are munching on the dimensions and measures understanding far more than with their report, you focus on the next value-adding requirement.

Did you notice a common keyword in these examples? Complex. When you see complex, simplify. “Make things as simple as possible, but not simpler”, said Einstein. “Simplicity—the art of maximizing the amount of work not done—is essential”, says the Agile Manifesto.

Before customizing, think of a better way. Can you achieve the same with a standard feature? If not, how much can be achieved with a standard feature? Does the part that isn’t achieved make it impossible to complete the task; does it cause extra overhead? If it was done outside the system, would other parts of the system suffer? Would it add overhead? Does any overhead caused by not customizing outweigh the cost that would be invested into customization?

Agile is all about value. If you focus on value and how to add it, you will find it much easier to prioritize requirements and to keep those that add value, and scrap those that don’t. When value is consistently added to the project this way, especially by utilizing the principles from previous two posts (vanilla and gradual), any money invested will get returned quickly and surely.

Come back tomorrow for the next topic in the Agile series: customizing it lightly.