I can't count the number of times a customer has started a brand new program/project request by asking me to implement a solution instead of solve a problem. Usually it comes in the form of, "Would you install XYZ application for us?" or better yet, "Does our environment support Ruby on Rails?"
Evaluating applications or tool sets at this point (before conducting analysis or developing the software architecture) is premature unless it's a temporary solution for an unimportant problem. I say this because it is my experience that it is the software architecture that provides the standard against which applications and tool sets can be evaluated.
To do it the other way round would be to embrace the notion "that if all that mattered was functionality any software architecture would do", including a single script with ten million lines of code. In other words if all that mattered was the ability to create, manage, and publish content via HTML and RSS
than everyone should use Drupal. Drupal is a great solution for the organizations whose quality attribute requirements match what Drupal provides. But if you don't know what your quality attribute requirements are how can you know whether Drupal is right for your environment? You could grab Drupal and take your chances or you could figure out what your quality attribute requirements are and then evaluate different solutions, including Drupal.
That being said, I do understand the need to evaluate what is possible with current technology in order to give appropriate input in the process of developing requirements and the software architecture. However, there is a temptation to jump into the evaluation of solutions before doing the proper up front analysis. When this happens the draw to implement something before fully understanding the impact of the solution becomes great and many organizations lack the discipline to resist. I argue that this is a large reason why these kinds of software solutions fail.