If functionality isn’t a clear yes then make it a clear no #HoskWisdom

User want everything that will make their work easier, but what do they really need. If you can remove those unnecessary requirements, you increase the probability of delivering the project on time and reduce the complexity.

Wish lists

When gathering requirements and creating a solution, particularly when replacing a legacy system, requirements gathering can turn out into a wish list creating exercise.

Users creating a huge of list of things they would like the new system to do or things that would be nice if the system did. It’s often a waste of time because when you estimate those items the users decides they are not worth the money.

Every item you add can bloat the system and slow it down. It might seem trivial to add a field here or a field there but consider these fields need a value when someones creates that record.

Most systems start lean and slowly bloat, adding more features until you end up with a word editor like Word, which has hundreds of features most people don’t understand and never use.

I worked on a project where the users refused to use the system, 10 extra fields added to a form for reporting took 10 minutes to fill. A form the business expected to be a populated in 5 minutes.

What’s the goal

Distinguish between what the users want but do not necessarily need.

What’s the goal of the system, what data is mandatory.

It’s better to create basic functionality and see if it works, many nice to have features used by the users. Without unnecessary features the system is simpler to use and maintain.

Focusing on the business goal helps move away from recreating the existing system and doing it that way because it has always done it that way.

If functionality isn’t a clear yes then make it a clear no

Ask these questions

• What do you do with this information
• What people/teams use the information and what do they do it with it
• What decisions are made with this information

Be strong

If you can keep the system simple and use out of the box functionality, you will create a system quicker and with fewer bugs.

Once users use the system you can see if they can do their jobs, where the bottlenecks are and what really needs improving. Taking away the developing, testing and bug fixing of nice to have features can give a project momentum.

Some functionality is vital and can make a huge difference, particularly when you can automate manual tasks, transform data, integrate separate systems and help teams collaborate.

Conclusion

Sometimes not creating customisations can improve the system and keep the project on track. Ask questions and filter out the unimportant requirements and focus on delivering the important.

Remove as many trivial requirements from the solution as possible because what you don’t do will leave more time to focus on the items you will do.

Many problems on projects can be traced to saying yes to requirements to quickly and not saying no soon enough. Successful projects push back and remove unnecessary requirements and this helps them deliver on time and on budget.