Assessing requirements to estimate costs - what order do we assess the property of a requirement?

Question

TLDR

Is there an agreed upon PMBOK (or other) set order to evaluate a requirement's properties to get an estimate of what it will cost?

e.g. if you're creating a project estimate (any methodology, framework or stage of the project), when your review requirement(s), do you evaluate its resourcing impact first, then it's timeframe second, then its complexity third (and so on) in a set order?

My view that there is not.

Summarize the problem

I am a business analyst being asked to describe the properties of a body of project requirements that affect project estimates and the set order in which these properties are assessed in. For example, requirements for a payment gateway with a high number of interfaces could be expensive (this task could be given to many developers and involve 3rd parties, so high complexity is expected), whereas a contact form on a website should be simple (this task could be given to any developer, so low resourcing issues are expected) and inexpensive. Do we assess a requirement's complexity first or it's resourcing impact first?

Properties of the requirements I have put forward are

• Number of requirements​ - the greater number, the more expensive (in general)
• Complexity of requirements ​the more complex, the more expensive (in general)
• Skill mix​ - the more specialised, the more expensive (in general)
• Internal resourcing - ​the more need for using up BAU resources, consultants and partnering, the more expensive (in general)
• Priority of requirements​ - the more Must haves, the more expensive (in general)
• Time frame - the more urgent, the more expensive (always!)​
• Specialised project requirements - the more obscure, the more expensive (in general)​

and so on

Provide details and any research

...

• I have asked other Project managers internal to our organisation
• I have asked friends
• Googled phrases similar to "in what order do we assess a requirement property to provide project estimates?"

Answer 1

TL;DR

No, there is no set order for evaluating a project’s requirements. There isn’t even a universal set of evaluation criteria for product requirements, and certainly no pre-determined set of project priorities.

Analysis and Recommendations

Every project has constraints on schedule, budget, scope, and quality. Within those areas, and in other areas such as business priorities, organizational politics, market considerations, and other ”soft” requirements there are too many variables to have a “one size fits all” requirements filter.

As a pragmatic rule of thumb, it’s more a matter of weighting various criteria than ordering the requirements analysis. In other words, you have to assess the impact of all the requirements, but you’ll give more weight to the things that business leadership (often through the project sponsor) have told you they will evaluate as the key measures of the project’s hoped-for success.

As just one example, Mike Cohn’s web site offers a free relative weighting calculator for comparing desired features against various criteria to determine what should be prioritized. There are certainly other approaches, and the rigor (or lack thereof) is really less important than getting all the stakeholders& dash;especially the project sponsor& dash;to agree on the methodology of your analysis and the resulting project plan you build from it.

Just remember that you’re seeking consensus or alignment rather than 100% agreement, which you are unlikely to ever get. If everyone buys into the approach, then it becomes a collaborative effort. With the stakeholders are active collaborators, you are much less likely to face reproach later on if it turns out that the evaluation or plan were less than perfect, and no reasonable person can hold you solely responsible for the outcome.

That said, people and organizations are rarely entirely reasonable. Therefore, your mileage may vary. Still, consensus-building and collaboration are still your best path forward. Step off that path at your own risk.

Answer 2

Estimation is a big topic that it's difficult to summarise for such a general question.

The first thing I notice is that some of the factors you have mentioned may have little or no relevance to the actual cost and are essentially commercial decisions. Timing and priority for example may not make any difference at all to the real time-and-materials costs, they perhaps just have an opportunity cost impact.

In the software and tech fields costs are best estimated by the technical team actually doing the work. It's almost impossible to draw conclusions from the number and description of stated requirements unless you understand the technical implications. A single word could make an order of magnitude difference to the eventual cost. Allow the subject-matter experts to make the estimates.

Many software development teams use relative estimation techniques (Fibonacci points, Wideband Delphi) and choose to give a composite score based on a variety of factors like size, complexity and risk. It's then possible to convert complexity score to a price (or better yet an estimated price range) based on past performance and judgement. The sequence of estimation is less important than the overall method and who is doing the estimating. Contractual terms are also a major consideration: firm-fixed estimates inevitably tend to be very different to T&M pricing.