I wrote about this recently elsewhere, and I'll revise and extend my remarks for this answer.
First, let's define project-based software: It is software that is meant to be defined, planned, developed, and delivered, and then the project is considered 'done'. A common metaphor used is relating it to building a building.
Scrum is an agile methodology, and if you read the agile manifesto, one of the values that jumps out is responding to change over following a plan, that is, if the organization practicing Scrum responds to change but they ditch the plan in the process, that's OK -- in fact, that's celebrated as being agile to change.
There are (at least) three parties involved in project-based software:
- The people using the software
- The people approving the budget for the software
- The people building the software
Scrum as a methodology is centered around ensuring the people who use the software and the people who build the software work as close together as possible, and in some way the only role that is both the 'customer' and the 'business' is the product owner role.
Already we can see that Scrum is perhaps not the best methodology for project based work. It does not align well with the roles 'needed' for project-based work (Asking a product owner to choose between the two masters of the customer and the people approving the budget and the customer will lose 9 times out of 10).
If you're deadline driven -- that is, if following that project schedule is the most important artifact to your business and culture (and that's OK if it is!), then you will inevitably feel like scrum is 'getting in your way'.
To determine whether Scrum is an acceptable methodology to your business for project-based work, culturally you need to understand the business' appetite for change. Are they OK if the team does not make commitments outside of two-weeks/four-weeks in advance ? (whatever the sprint length is)? If the team says, "We don't know when this will be done, but we have a relative degree of certainty what we can get done this sprint?"
I am even hesitant to write the above because in the 2011 iteration of the Scrum Guide they changed commitment to forecast, underscoring the idea that the Development team isn't really able to commit to work, they can however make a forecast, with about the same accuracy as a weather forecast two weeks in advance.
Does this unsettle you or your business? If it does, scrum may not be for you, as its process is not tuned to the schedule being the most important thing.
When there is a deadline and a scope, one must always choose one or the other when they are not aligned. Scrum chooses to cut down the question to What can we do next? instead of what will we get in the end? Scrum can't answer what the 'end' will look like, but Scrum can help you iteratively get to wherever/whenever that end is.