These are all inter-related in that a large scope generally leads to a longer schedule and more cost. However, I think I know what you are getting at, and the philosophies you set forth look like this:
All of these are overly simplified, but they work as it comes to describe a philosophy for the sake of the discussion.
Believe it or not, I have witnessed all three of these followed in some form or fashion. Option 2 seems the most foolish to me, and the programs I have seen that followed this thinking bear this out. After all, this is a business we are running, not a foot race. We set out to accomplish something new with our business, and if we change it all around just so we can accomplish some new scope within our set timeframe, we are literally trading off what we set out to accomplish in the first place. Plus, the driver here is usually cost anyway; we don't want to exceed the timeline because more time means more spending, and we don't want to exceed budget. I recently saw a program run this way (went live in early 2012), and it was a disaster; CIO fired and the system is not being used. While I feel for the CIO, the fact that it worked out this way makes sense. The company traded off on scope to meet a timeline, so the solution literally could not do what the company wanted it to do.
The other two are a tougher choice. Cost and scope are the two sides of the business case. One the one side, we have the scope of the project, which delivers the value or the benefit to the company, by allowing it to do something new or do it more efficiently. On the other hand we have the cost of the project, which is the price we pay to achieve the benefit. Which one do we want more? Certainty in costs or certainty in benefit?
The marketplace is speaking on this matter (it's too early to say it has spoken), and here is what is happening; companies implementing new technology are opting for "good enough" scope with cost certainty than take on ideal scope with less cost certainty. There are a couple reasons for this; 1. times are tough and everyone is costs conscious 2. customers are more able to leverage packaged software as is. Packaged software is no doubt getting better (pardon the SAP commercial there!). But, customers are also becoming more discerning about how they apply technology. While there may be areas where a company's operations are indeed special, and therefore deserving of a custom or non-best practice solution, these areas are better understood. Companies are investing in these areas, maintaining their special-ness in those differentiating areas. However, in those areas that are non-differentiating, most companies are asking "why not adopt the best practice?'... and usually there is software that can address that best practice pretty much out of the box.
In any event, I think that cost and scope control are equally important. However, I think you can see what side is more important by looking at your initiative. Is it in a differentiating part of your business? If so, scope may be more important. This is because the scope that is delivered is so important to a differentiating part of your business, that overpaying for it (if you HAVE to) makes sense. However, if it's not, I would say cost is important to you. I would try to find a best practices, low risk approach that delivers known functionality.
At SAP, since you are on the Rapid Deployment section, you know that we have these types of solutions. And the good thing about RDS, is that even though it does deliver set best practices functionality, if you find later that you need something "special", RDS does not limit your use however you want it. It just starts you off with a low-risk, quick-to-deploy, short-money win that helps your business.
The question raised is demonstrated quite well in the magic triangle which shows the relationship between three driving factors in a project: time, quality and cost or as discussed in the article: schedule, scope and cost.
All these factors have to be equally balanced – what is most important, indeed, depends on a company’s objectives. Fixing one component, e.g., cost or budget, eventually leads to a trade-off in another. Take, for example the scope that can be realized with the given budget.
The situation gets even more challenging with two components being fixed. And quite often project managers are challenged with the fact that “all of these factors are important,” which eventually leaves them to juggle and master all of these partially conflicting requirements and objectives.
Would it not be supportive for decision makers and projects manager to see what the tradeoff will be upfront to take more profound decisions?
I do believe that the rapid-deployment solution implementation approach can serve as a facilitator here, as well. Take a look at the graphics: Let’s transfer the cost-time-quality dimension of the magic triangle to the concept of rapid-deployment solution: You can expect a predefined functional scope to be implemented in a predefined time at a predefined cost.
I think this graphic nicely demonstrates what makes the rapid-deployment solution approach so predictable. It may be perceived as negative to be “limited” to this fixed offering (therefore, I do prefer “predefined” because that is actually what it is).
The approach is self-understood that you start with a value-added scope which can expand, later, for example with other SAP offerings such as SAP Rapid Deployment solutions (RDS) or engineered services.
Anything you add to the predefined package, before implementation, requires that you re-balance your project time, scope and cost – based on your specific business needs. However, with prepackaged offerings, you can eliminate lengthy decision-making processes, experience results much faster through pre-packaged, best practices content and with predictability, because you know what you get, beforehand.