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.
I am FI Consultant currently working in Asia Pacific Region with an implementation project. I am agreeing with Doreen's view. To add more to share my view:
1. SCOPE is more and more important for an implementation project's success. It is because, whenever there is an impact in scope, it will affect the 2nd and 3rd reasons automatically.
2.If the SCOPE is not freezed at a point of time( exceptions for any minor changes), the impact will affect the success percentage of the project.
3. Though , always Client satisfaction is our motto, politely to emphasis the point on freezing the scope during Blue print stage is always a wise decision.
Thank you. Your answers have been very helpful.
Scope does help all involved control activities, expectations and performance outcomes. It is a critical aspect. You all probably have examples where a scope issue can come from the project team--where the scope was managed informally, and the project team thought about trying something new that caused the scope to creep--or scope issues from the customer side, where the enthusiasm for the program and the possibilities translated into additional requests of the deployment team.
Once I was on a non-SAP project in the Automotive Industry where one of the sub-teams on the deployment decided to try an unproven technology for which they had no training, guidelines, or skills. They convinced the project manager that it would be no budget increase--and would take 1 week to configure, integrate and test. After the go-ahead, the deployment team encountered bugs. It took 4X longer to deliver, which would have impacted schedule, but the project manager used creative project management to prevent schedule slip. Not every project manager can lean on creativity to deliver on a promise.
Schedule provides additional criteria that determines a project success and the customer expectation. It is tightly connected with cost, since projects that go beyond schedule often go beyond the project estimates. Without a fixed price agreement, the project management can run the risk of budget overruns in some instances where the deployment misses the target date. As the old saying goes: time is money.
I was on a non-SAP project in the Higher Education Industry where they had an enterprise-wide overhaul. My project team had one part of the deployment, and managed it as a sub project. another project team had another part of the deployment, with separate budget, schedule, scope, etc. Our team finished ahead of schedule and budget. The other team was so far over schedule and budget that they "borrowed" from our budget, and went into an overtime situation to meet the schedule. Because the client is driven by schedule--imagine students registering for classes, payments, financial aid, etc., they had to be deadline driven.
That example brings up the next topic: costs. In the above example, the client had budget that was available--by luck. Management by luck is a risky proposition. Project overruns in scope, schedule and costs can move the project into the "red zone," and make it difficult for any skilled project manager to meet the organization's goals.
With the fixed price, fixed schedule and fixed scope of SAP Rapid-Deployment solutions, it would seem that many of the IT project manager's challenges are improved. In considering all three topics, it is difficult to distinguish which is more valuable: control around price, schedule or scope.