You have to have an acceptable budget for a project before you can start managing the budget for a project.

Over the decades, I have seen many methods and tools for managing things you create, but don’t offer any help in actually creating them. In the BA/requirements world, the key example is Requirements Management Tools; useful once you have requirements, but defining clear and complete requirements is the difficult part. Anyone who has read my past posts knows that doing requirements definition/discovery is, well, what I do.

But there other such things, and some of which having good requirements can help. For example, do you need to budget for your projects before you start them? You have an annual or quarterly process about submitting budgets and getting approved, and then a separate process for changing the budget during the projects. However, do these processes and supporting tools actually help you come up with a budget number you are comfortable with? No, so you need something else to help with that and, no surprise, requirements can be that something.

What can clear  requirements help you get? Estimates, for design, development, and testing. But, you ask, are you saying to do all the requirements for your upcoming projects long before they start, to get budget amounts? Yes and no. Requirements can be defined at different levels of detail, you just have to balance the level of detail to the granularity of the estimates needed for budgets.

When you actually start to elicit requirements for a project, the first thing you have to do is scope the requirements analysis work. This scoping will take a half-day to a day to complete. What I am suggesting is to do this scoping work-only for all your planned projects. This scoping will provide the main business activities and information  to be addressed in the project. That is enough detail for t-shirt sizing of each project,  small/medium/large; align this sizing to previous projects  of similar sizes, get the costs of those projects (not always easy but it should be somewhere) and you have numbers that are based on something real. The percentage amount of variations might still be high, 20 to 40% for example, but the numbers are based on something real, not just SWAG or other “best guesses”.

Is a day per project for requirements scoping during budgeting too much to ask to get some real numbers? I think not.